|2021-02||User Story||57668||Customer invoicing||
New validation to prevent duplicate customer invoicing
New validation was added to the customer invoicing process, to avoid (rather hypothetical) cases of duplicate invoicing, which could theoretically happen when several automated customer invoicing periodic tasks were run against the same transport order scope, on several batch servers.
New validation checks whether invoice already exists for transport order (and if so then the duplicate invoicing is not done). The validation is by default active but can be deactivated in main TMS parameters (in section 'Invoice', flag 'Deactivate customer invoicing corrupt data check').
|2021-02||User Story||77456||Customer invoicing||
''Invoice responsible company' is newly a mandatory field, on transport order & part-invoice order, when intercompany is activated
As the field 'Invoice responsible company' is crucial for intercompany invoicing, the field is filled (and updated) on relevant order types automatically by the system, when intercompany configuration key is activated. The issue previously was that the field value could be manually deleted by user in the forms, which caused problems later during invoice posting. Newly, on the applications with intercompany configuration key activated, the 'Invoice responsible company' field is treated as mandatory and cannot be cleared.
|2021-02||User Story||77654||Customer invoicing||
New feature 'Customer self-billing' was added
With this task a support for customer self-billing process is introduced in CAPcargo Transport. This is sometimes also referred to as ‘Recipient Created Tax Invoices (RCTI)' or ‘Gutschriftverfahren’ (in German language).
In this business process it’s the customer who sends the transportation company the billing proposal for a transport invoice instead of the transport company sending the customer the transport invoice. With the help of a data entity the billing proposal can be imported. After that it can be automatically matched against transport orders and the calculated amounts are verified against the billing proposal values. When the billing proposal has been completely matched an invoice is created with only the transport orders that were on the billing proposal.
|2021-02||User Story||65756||Customer order management & pricing||
Rule order collection is newly initialized already in the contract finding process
Previously the initialization of 'Rule order collection' from tariffs to order header happened only during the price calculation process, hence the initial price calculation was a mandatory prerequisite for the order collection. To improve an order collection performance (as such initial price calculation is not effectively needed, it is only needed for 'Rule order collection' initialization), the 'Rule order collection' is newly initialized to order header already during the contract finding process (as one the last steps of the contract finding).
This allows to skip the initial price calculation step in the fully automated collection process, so the following periodic task structure is sufficient:
- Contract finding task (initializes 'Rule order collection' to order header)
- Order collection task (forms the order collection, based on previously initialized 'Rule order collection')
- Price calculation task (calculates the price of the transport order)
|2021-02||User Story||72455||Customer order management & pricing||
New track & trace status: 'Failed pick-up'
As the 'failed delivery' process already had its own track & trace status, the status for 'failed pick-up' (Status312 'Failed pick-up') was also added to the track & trace framework.
|2021-02||User Story||73676||Customer order management & pricing||
Additional/alternative source for order driving distance & time calculation
Previously, on transport order (and on other order types) it was possible to calculate the driving distance & time only from the PTV map component. This was enhanced - now it is possible to determine the driving distance & time either from the map component or from internal distance table or from the combination of both. The parameterization of which method shall be used is done on the transport type, in new section 'Distance and time calculation'.
The functionality can help in the projects where nonstandard addresses are used (ie. that cannot be calculated by the map component), or some custom negotiated driving distances & times are used (ie. that differs to the map component data).
This task also removes the “Default Distance Determination”functionality (which could calculate the driving distance & time from the internal distance table during transport order creation) as depreciated.
The enhancement can be used only for the calculation of driving distance & time on various order types; it cannot be used for the calculation of driving distance & time on the tour between tour stop (there still the map component is the only source, beside the manual entry).
|2021-02||User Story||77511||Customer order management & pricing||
Several GUI enhancements of the 'Re-initializing of existing values' dialog, in the contract finding process
In the contract finding process, when tariffs shall initialize some fields to the order header (but these fields already have a different value in the order header), a 'Re-initializing of existing values' dialog (aka. 'decision making' dialog) is invoked where user has to select which fields shall be initialized/overwritten on transport order and which not. GUI of the dialog was improved, in following way:
- 'Update' flag was moved to the third column
- The record 'hiding' mechanism was improved (ie. when user selects a value from one order line, only other order lines (with the same field) are hidden).
- Whole dialog grid was horizontally expanded, for better grid readability
|2021-02||User Story||78624||Customer order management & pricing||
Change of quantity was not possible on transport order line in certain scenarios
When trying to change quantity on transport order line (where some other transport order line of the same order already had a quantity split on its transport legs) then the change of quantity failed with error 'Action not allowed! Order is already [partially] in a tour which is already released or confirmed.'. The issue was corrected and the error is shown only when the quantity change happens on the transport order line that already has some quantity split on its transport legs.
|2021-02||User Story||78942||Customer order management & pricing||
''Distance and time calculation' can be newly used also for multiple selected orders
Previously it was possible to launch 'Distance and time calculation' only for single selected order. This task enables the multiselect of the orders, allowing users to calculate driving distance and time for multiple orders at once.
Following forms were enhanced:
- All transport orders
- Cross-company transport orders
- Transport pre-orders
- Part-invoice orders
- Intercompany order
|2021-02||User Story||78948||Customer order management & pricing||
Deprecate feature 'Transport order header linked packages'
Feature 'Transport order header linked packages' (which was previously existing in the transport order) was removed as obsolete. Feature had several weaknesses (these packages couldn't be displayed in the transport leg forms when transport order had more lines; also were not respected properly in the quantity split dispatching scenarios; couldn't be used for ULD processing; had certain issues in the package tour confirmation etc.).
As the functionality was not used in the productive TAL applications, it was deprecated and removed.
From now on, it is only possible to handle packages that have a clear reference to some transport order line.
|2021-02||User Story||78992||Customer order management & pricing||
GUI enhancement of the filtering sidebars in 'Checked imported order' & 'Imported transport order' forms
Previously the filtering sidebars in the 'Checked imported order' & 'Imported transport order' forms were slightly distorted (eg. showing too much information, the spacing between orders was suboptimal etc.). This task unifies both filtering sidebars in both EDI forms. Now both filtering sidebars have the same GUI as on transport order form.
|2021-02||User Story||79041||Customer order management & pricing||
Conflict management was enhanced to Conflict analysis, in the Resource assignment form
Previously, on Resource assignment form (that can be launched form transport order form) a menuitem Conflict management just opened the overview of previously detected conflicts. The menuitem was transformed (and renamed) into Conflict analysis, so once clicked it newly also automatically performs the conflict analysis (to detect the new conflicts and to retest previously detected conflicts).
|2021-02||User Story||79100||Customer order management & pricing||
New warning infolog when posting profile is not suitable for the current customer/vendor account
When posting profile is being determined (eg. during price calculation etc.) system newly reports when some posting profile was found (but discarded) because it was not suitable for current customer/vendor account. Newly, the user is informed about such cases via warning 'The found posting profile XYZ has no valid lines for Customer-Vendor-ABC' (where the XYZ shows the exact posting profile and Customer-Vendor-ABC shows the exact customer or vendor account).
|2021-02||User Story||79563||Customer order management & pricing||
Deprecate field 'Order closed with issue' on transport order header
Field 'Order closed with issue' (which was previously existing in the transport order header and in the dialog for manual status message creation) was removed as obsolete. Field was not actively used in the TAL functionality (was only a GUI fragment of some project specific development that was not admitted into TAL).
|2021-02||User Story||79986||Customer order management & pricing||
Removal of unit conversion from the tariff surcharge criteria logic
Via tariff surcharge criteria it is possible to define when the tariff surcharges should be applied during price calculation, eg. when planning quantity is over 10 load meters etc. Previously, system also applied the unit conversion, when testing the surcharge criteria. So if the planning quantity on transport order was for example defined in square meters (and there was a conversion rule defined between square meters and load meters), then such tariff surcharge could get applied.
This caused quite confusion as it was not easily understandable why the tariff surcharge (with certain unit criteria) was applied when the amount of the same unit was not sufficient on the order line (but the tariff surcharge was applied because thru the conversion rule the sufficient amount was converted from some other unit). Hence the conversion logic was supressed when the price calculation checks for tariff surcharge criteria.
|2021-02||User Story||48477||Dispatching & confirmation||
Performance improvement of the transport leg & tour planning engine (when transport legs are planned into tours / removed from tours)
Several performance driven code enhancements were done to the engine that is responsible for planning of transport legs into tour and for removal of transport legs from the tour. The functionality itself should stay the same, just with better performance.
|2021-02||User Story||54299||Dispatching & confirmation||
Performance enhancement of the GPB 'Resources' screen
Several performance related optimizations were done on the GPB 'Resources' screen, to improve the users GUI experience when working with the screen. The optimizations were done in the code structure (and in underlying technology) level, without functionality change of the 'Resources' screen.
|2021-02||User Story||64611||Dispatching & confirmation||
Small visual enhancement in GPB, when tours (which are overlapping for individual resource) are delayed
In GPB 'Resource Dispatching' screen, when the tours are delayed, a 'red bar' visualization is shown in the gantt. But in case when more tours (which were overlapping for individual resource) were delayed, the 'red bar' visualization was hardly visible/readable, due to the visualization of the overlapping tours. This was enhanced and the delay of the overlapping tours is newly highlighted by an additional red line.
|2021-02||User Story||67715||Dispatching & confirmation||
Enhancement of the customer wish 'early/late' visualization in GPB gantt screens (respect address business opening hours)
The visualization of customer wish 'early/delay' in level 1 tour gantt bars, (aka. the red/green bars) could previously give only a rough overview when no customer wished timeslot was specified on the transport order header (ie. customer wish was specified only on the 'date' level, but not on the 'hours:minutes' level), as no exact 'wished' time was known.
The visualization (and the 'early/delay' determination) was enhanced in this task, newly the system takes into account also the business opening hours of the unload address, but only when no exact customer wish timeslot is specified on transport order header. When determining the business opening hours the system uses the usual 'hierarchical' structure (ie. opening hours can be defined on the TMS address itself, or on address calendar, or on country calendar etc.) and uses the latest opening hours timeslot on the address for customer wished day).
For the cases when customer wish is specified on the unload address of the transport order header with maximum details (ie. including the 'hours:minutes' timeslot, then these are still used (and business opening hours on address are ignored).
This allows better precision in the 'early/late' tour visualization in tour gantt screens when customer wish is defined only on the 'date' level.
|2021-02||User Story||72786||Dispatching & confirmation||
Missing confirmation dialog in GPB 'Resource Dispatching' screen, when merging tour stops that have some manual ETA specified
In GPB 'Tour Dispatching' screen, when merging tour stops that have some manual ETA specified, a confirmation dialog is shown where user has to confirm that the merge of tour stops shall really happen (as the merging will delete the existing manual ETA). But in 'Resource dispatching' screen such confirmation dialog was previously missing (and the tour stops were immediately merged, with manual ETA being deleted). This task enhances the 'Resource Dispatching' screen, to populate the same confirmation dialog (as is already existing in the 'Tour Dispatching' screen).
|2021-02||User Story||76529||Dispatching & confirmation||
New feature: cleaning framework and truck loading history
A new framework isintroduced, that is responsible for warning the user when, where and which carryingresource needs to be cleaned. Furthermore, based on the mode of the cleaning,additional costs can be added to the tour.
Prerequisites of using thecleaning determination logic are:
- the setup of the cleaningtype, that defines the way of cleaning and the efficiency of it
- the setup of the cleaningmatrix, that contains the rules which determine what type of cleaning is necessaryif a certain commodity was carried by the vehicle/compartment prior the currentload
The aim of the logic is todetermine what type of cleaning has to be done before loading goods intovehicle or compartment. This cleaning type is returned on the one hand to theconflict management (where it triggers a conflict), on the other hand to anew form, that gives information to the user about the necessity of cleaningand provides a semi-automatic way of inserting cleaning activity/activities.
Regardless of which tool is used,the goal is to insert cleaning activity/activities with the right cleaningtype into existing or new cleaning specific tour stops. Such activities are notonly the indicators for the driver (that cleaning has to be done at pre-definedlocations), but they are also used for the creation of tour additional costsautomatically at the confirmation of the cleaning activity.
As an overview for the useralso a new form is introduced, the Truck loading history. Via this form, thesystem grants always up-to-date information for the user, what activitieshappened with which vehicle. It depends on a new parameter of the activitymaster data, whether the activity is shown in the Truck loading history.
|2021-02||User Story||77611||Dispatching & confirmation||
ETA of tour stop is not anymore overwritten by its confirmed date & time
When confirming date/time of a tour stop in the tour confirmation, the system re-schedules the successor tour stops ETA, which is correct and important. But the system also re-scheduled the ETA of current confirmed tour stop by overwriting it by the confirmed value. This was not entirely needed and it caused that the original ETA of current tour stop was lost, hence this logic was removed. Newly, the confirmation of date/time only re-schedules the successor tour stops ETA, but the current tour stop ETA is not updated (ie. is preserved).
|2021-02||User Story||77641||Dispatching & confirmation||
Tour confirmation enhancement: the order confirmation is not anymore done via 'Confirmed' checkboxes but via dedicated menuitems
The order confirmation (in tour confirmation form) is not anymore done via 'Confirmed' checkboxes but newly via dedicated menuitems 'Confirm' and 'Undo confirmation'. The reason for such change was that several issues/limitations were related to the confirmation via checkboxes (eg. the change of the confirmation quantity was sometimes reset when the checkbox 'Confirmed' was used; the order confirmation shall differ when orders with (or without) packages are confirmed etc.).
|2021-02||User Story||77643||Dispatching & confirmation||
Enhancement of the tour confirmation process, when the confirmation happens on the package level
Previously the tour confirmation (via package confirmation) was possible but the feature was lacking in certain aspects, especially in the area of how confirmed quantities were handled/updated on the tour order line from the package confirmation. Depending on the package data users could for example experience the loss of confirmed weight (or volume) quantity, or it was not clear why certain confirmed quantity was updated (as some conversion rules were applied etc.). The package confirmation mechanism was thus re-worked and following key logic is now applied, for the tours/orders that contain some packages:
- Package confirmation now updates the confirmed transport quantity (by the count of confirmed packages, when the last package is processed/confirmed). The confirming transport quantity is locked for manual editing (as it is managed by the package confirmation)
- Package confirmation now updates the confirmed weigh (and volume) based quantity (by the summing of data from the packages, when the last package is processed/confirmed), but only if such weight (or volume) data is available on all packages that are being confirmed. Otherwise (eg. when some weight or volume data is not available on some confirmed package), then the confirmed quantity is not updated. Users still can manually adjust the confirming quantity, as the fields are editable.
|2021-02||User Story||77657||Dispatching & confirmation||
Improvement of the activity category handling in both GPB gantt screens
A follower of task 77411 (Enhancement of the transport activities, new activity types & activity category feature), that was released in previous release GPB 2.3.7 (with TAL 10.0-CAP14.0).
Following enhancements were added in this task:
- Previously introduced activity 'Category' field (and also a new 'Mandatory for Driver app' field) are now also displayed in both GPB gantt screens (in level 3, in the activity overview 'slide in' side window)
- Activity visualization in both GPB gantt screens (in level 2, in the activity overview section) newly only activities of type Dispatching or Execution are shown. As only these do affect the duration of the tour.
For more details about activity category feature please see the release letter of the task 77411 (Enhancement of the transport activities, new activity types & activity category feature), that was released in previous release GPB 2.3.7 (with TAL 10.0-CAP14.0).
|2021-02||User Story||78508||Dispatching & confirmation||
Manual ETA specification is newly also shown in the GPB 'Transport orders /-legs' screen
In GPB, in 'Transport order /-legs' screen, in tour stop overview, the GPB displays the entire transport leg structure, ie. also the transport legs that are already planned in some tour. The detailed scheduling of such transport legs could have been already adjusted via Manual ETA specification on the tour, but such information was previously not anyhow reflected in the transport leg structure overview. This was enhanced, the Manual ETA specification is newly also visualized (by green font color & icon) in the transport leg structure overview in the 'Transport order /-legs' screen.
|2021-02||User Story||78581||Dispatching & confirmation||
TAL infolog 'No conflicts detected.' was replaced by GPB native infolog, in GPB conflict analysis menuitems
Previously released task 72628 (Conflict analysis sometimes didn't open in several TMS forms) enhanced the behavior of the conflict analysis menuitems in TAL dispatching screens, showing a new infolog 'No conflicts detected.' when no conflicts were detected by conflict analysis.
Having a TAL infolog is certainly sufficient for TAL forms but is not sufficient for GBP screens (as the user would have to wait for TAL browser window to open, just to learn that there were no conflicts detected). So for GPB processes the TAL infolog was replaced by a native GPB infolog (that is displayed instantly).
For more details about the infolog logic in the conflict analysis please see the release letter of task 72628 (in TAL release 10.0-CAP14.0)
|2021-02||User Story||78644||Dispatching & confirmation||
Better distinguishing of confirmed 'Sender delivery' transport legs in the goods planning status overview
Previously, the identification of 'Sender delivery' transport legs (that were confirmed) was confusing in the goods planning status overviews (especially in the transport leg planning & cross-docking forms), as these legs were previously treated as common transport legs (with goods planning statuses of 'Roughly planned'). This was enhanced and following goods planning status logic is newly applied:
- When the 'sender delivery' leg is confirmed and is not in the tour - it gets goods planning status 'Arrived'
- When the 'sender delivery' leg is confirmed and is in the tour - it gets goods planning status 'Unloaded'
|2021-02||User Story||78782||Dispatching & confirmation||
The functionality of 'auto pop-up' of work instructions on the tour was depreciated (GPB)
Previously released task 78781 (The functionality of 'auto pop-up' of work instructions on the tour was depreciated) removed the menuitems for 'auto pop-up' of work instructions from TAL forms. This task also removes the 'auto pop-up' menuitem from the GPB gantt screens.
For more details about depreciated 'auto pop-up' functionality please see the release letter of task 78781 (in TAL release 10.0-CAP14.0)
|2021-02||User Story||79119||Dispatching & confirmation||
Allow to bypass in GPB the initial TAL compatibility check
When launching the GPB, the GPB client automatically checks whether some compatible TAL version is installed. The compatibility check was previously mandatory, ie. GPB client could be launched only with the TAL compatible version only. For various (mostly test) purposes it is sometimes needed to bypass such validation, hence a new parameter in the GPB config file was introduced. For more details please see the installation guidelines document.
- Bypassing the TAL compatibility check was introduced for maintenance & support purposes, must not be done on the productive applications, as it might lead into unforeseen GPB behavior, possibly even to data corruption.
|2021-02||User Story||79188||Dispatching & confirmation||
Performance improvement of the initial opening of both GPB gantt screens
Previously the initial opening of both GPB gantt screens could be less performing, especially when higher count of resources and tours had to be loaded at once. The responsible code was enhanced in this task, to achieve quicker gantt screen opening. The optimization was done purely on the code structure level, besides the performance improvement it leads to no functionality difference.
|2021-02||User Story||79390||Dispatching & confirmation||
Performance driven enhancement of the GPB, newly only one background service is used for maintenance of the refresh of the dispatching entities
Previously there were two background services that were responsible for maintaining the automated refreshing of the entities in GPB (eg. tours, transport legs, resources etc). To improve the general GUI experience with all GPB screens, both background services were merged into one.
|2021-02||User Story||79569||Dispatching & confirmation||
Transport order and transport leg can be blocked / put on hold by means of reason code
Transport order and transport leg can be blocked by indicating a reason code:
- Blocking TRO: TRO cannot be pre-dispatched
- Blocking transport leg: Leg cannot be dispatched in tour
Indicating a reason code allows to define why an order or leg should be put on hold. Possible reasons: Awaiting new date/time slot from customer, or any other documents, or even credit limit issues.
|2021-02||User Story||79611||Dispatching & confirmation||
Automatic release of tour to WHS
A new periodic function 'Release to warehouse – Tour' was introduced, which can be used to release trading orders assigned to tour to warehouse.
The following parameter can be defined:
- Tour plus days: Defines for how many days in the future – related to the tour start –tours should be released to warehouse.
- Calendar: The defined calendar controls which dates should be taken into account for the tour start date to select tours that are to be released to warehouse. Only the dates marked as ‘Open’ will be used. If no calendar is specified, all dates are used.
New periodic function is accessible in following path:
- Main menu -> CAPcargo Transport -> Periodic -> Dispatching -> Release to warehouse - Tour
Additionally, a new 'Release to warehouse' menuitem has been added, to following places:
- to GPB (to action pane on both gantt screens, in menuitem group Shipment)
- to 'Dispatch light - Tours' form (to menuitem group Shipment)
via which it is newly possible to release multiple tours to warehouse at the same time. The function can also be run in batch processing mode.
|2021-02||User Story||79638||Dispatching & confirmation||
New target for work instructions: tour stop
By enhancing the transport address related work instruction template, the user is enabled to define such address specific instructions, that are initialized to the tour stop during the tour stop creation.
|2021-02||User Story||79730||Dispatching & confirmation||
Two new languages were added to the GPB app
From now on the GPB app includes and supports also the 'en-gb' and 'en-au' languages.
|2021-02||User Story||79732||Other / General||
Two new languages were added to the TAL
From now on the TAL includes and supports also the 'en-gb' and 'en-au' languages.
|2021-02||User Story||64567||Driver App||
Enhancement of the activity configuration framework (Package scan mandatory / error with reason code)
To avoid the need to individualize the validation for scanning, a generic solution is introduced, to set Driver app activities mandatory or optional:
- Mandatory activities can only be cancelled/skipped with entering a reason code and optionally some description.
- Optional activities can be cancelled/skipped without entering a reason code, but with the option to add a description.
This configuration is possible for each driver activity type, being previously mostly initialized from TAL tour activities; additionally, it is possible to define whether the package scanning is optional or mandatory for the 'load' and 'unload' activities.
Special driver activities “Start working…”, “Arrived” and “Depart” are still hard-coded and not subject of this configuration. They are always mandatory.
- The configuration happens in the 'Instruction activity rules' (accessible in main menu path under:
main menu -> CAPcargo Transport -> Setup -> Dispatching -> Instruction activity rules
- New option 'Barcode scan required (package)' was added to the Activity type. This allows to set up rule(s) for activity being mandatory (or not), to be applied for all customers (or some), to be applied during loading (or unloading, or both) etc.
|2021-02||User Story||64571||Driver App||
Introducing an option in Driver app, to 'not confirm' (ie. skip) certain activities
To avoid the need to individualize the processes for all potential failed activities, a generic solution is introduced to 'not-confirm' an activity and add a reason code telling why.
Instead of confirming (ie. swiping off) an activity, the driver newly has an option (per activity and per tour stop (serving as multi-select of all activities on this tour stop)), to skip (ie. not-confirm) one or several activities. By doing so, the app asks the driver for a reason code which has to be selected from a list.
Before Failed activity can be used in Driver app, following pre-requisites are needed in D365:
- At least one transport order cancellation reason code for process "None" must be set up (it is used to fail activities other than load / unload)
- At least one transport order cancellation reason code for process "Failed delivery" must be set up
- At least one transport order cancellation reason code for process "Failed pickup" must be set up
- Doublecheck that these reason codes are shown in Driver app reason code form (main menu -> CAPcargo Transport -> Inquiries -> Driver app -> Driver app reason code
- If not, click "Settings refresh / synchronize" button
- The Driver app reason codes are expected to stay in sync with transport order cancellation reason codes. But if some transport order cancellation reason codes were created in the system before Driver app was activated, then they must be synchronized using "Settings refresh / synchronize" button.
|2021-02||User Story||72354||Driver App||
Failed delivery process from Driver App
The failed deliveryprocess can be launched from Driver App which automatically handles ordercancelling or potential re-attempting of delivery. Retry of delivery is possible within the sametransport order.
Further, automatic re-scheduling or blocking of new transport leg or new transport order is possible. For that a new function on transport order and transport leg was introduced, where an order or a leg can be blocked by indicating a reason code:
- Blocking TRO: TRO cannot be pre-dispatched
- Blocking transport leg: Leg cannot be dispatched in tour
By means of order import update, new appointment/wish dates forre-attempts can be imported and automatically updated in dispatching. Further,there is some configuration for potential automatic unblocking of theorder/leg.
|2021-02||User Story||72460||Driver App||
Failed pickup process from Driver App
The failed pickupprocess can be launched from Driver App which automatically handles ordercancelling or potential re-attempting of pickup. Retry of pickup is possiblewithin the same transport order (keeping all the references) or with a newtransport order.
Further, automaticre-scheduling or blocking of new transport leg or new transport order ispossible. For that a new function on transport order and transport leg wasintroduced, where an order or a leg can be blocked by indicating a reason code:
- Blocking TRO: TRO cannot be pre-dispatched
- Blocking transport leg: Leg cannot be dispatched in tour
By means of order import update, new appointment/wish dates for re-attempts can be imported and automatically updated in dispatching. Further, there is some configuration for potential automatic unblocking of the order/leg.
|2021-02||User Story||78964||Driver App||
Timestamp of the driver's approval is now visualized in GPB tour details in the time zone of the tour start address
In gantt screens in tour details (in level 2) the GPB displays the approval status (and the timestamp) from the Driver app. The logic was enhanced and GPB now also respects the potential time zone shift, applying the same time zone as on the tour start address.
|2021-02||User Story||79588||Driver App||
The main checkbox parameter 'Driver must accept the tour' was replaced by more flexible 'Driver acceptance before tour start' enum
By introducing the ‘Driver acceptance before tour start’ parameter, a new configuration option is provided. Hence besides the previously existing 2 options (driver accepts/rejects tour, tour is automatically accepted by driver), a third option is added: driver acknowledges tour. In this case rejecting the tour is not possible in the Driver app, but only 1 icon (=accept) is shown on the tour tile.
Furthermore, the new parameter does not only replace the previous ‘Driver must accept tour’ general TMS parameter, but it is introduced on the carrier/vendor as well. So more sophisticated configuration is possible for the external drivers.
|2021-02||User Story||79933||Driver App||
Attaching a picture in the Driver app when reporting a failed activity or a failed barcode scan
It is newly possible to attach a picture in the Driver app when reporting a failed activity or a failed barcode scan.
These pictures are attached to TAL (either to package tour order lines, or to tour order lines, or to tour activity), depending on where captured in the Driver app.
- Define the 'Document type for failed activity' and 'Document type for failed barcode scan' in the main TMS parameters (in section 'Document management') - to specify which document type shall be used for both cases
If parameters are empty, attachments are still handled/attached to TAL but using "first document type for files" that system can find.
Additional new parameterization:
- 'Document type for claim' was added to the main TMS parameters (in section 'Document management') - previously the "first document type for files" that system could find was used when attaching the claims to TAL
|2021-02||User Story||80007||Driver App||
New inquiry forms 'Review Driver app issues' & 'Review Driver app issues (tour line)' were added to the tour confirmation form
New inquiry forms 'Review Driver app issues' & 'Review Driver app issues (tour line)' were added to the tour confirmation form, to show more information about Driver app tours that might exist for the tour & tour stop, eg. to show the failed activities, missing barcode scans etc.
|2021-02||User Story||80229||Driver App||
Driver App: new app features with CAP.Transport&Logistics 10.0-CAP15.0
Following enhancement were added to the Driver app in this release:
- Skip activity and provide a reason code (for example failed pickup, failed delivery)
- Skip mandatory barcode scan and provide a reason code
Document import framework: new target table "Tours"
The document import framework has been extended with the target table tours. After uploading the file via the data management workspace against the existing entity "TAL Imported attachments" it is now possible to attach notes and documents against the tour table. As unique identifier the Tour ID must be specified during the upload.
New feature 'Generic message content' in the Message framework
Message framework was enhanced with a more flexible way of configuring the message content in status message setup.
It is now also possible in an easy way for customers to implement new content (as customization), as well for the product to easily provide further data (when requested).
To achieve this we will provide a possibility to implement a dedicated X++ interface, and those classes shall be selectable finally in the message template configuration.
- The message template content configuration happens in 'Status message template' form (main menu -> CAPcargo Transport -> Setup -> Track and Trace -> Status message template)
- 4 default content definition classes are provided, these are accessible in 'Status message calculated values' form (main menu -> CAPcargo Transport -> Setup -> Track and Trace -> Status message calculated values):
- Transport address (leg)
- Failed delivery reason (leg)
- Failed pickup reason (leg)
- Transport type
|2021-02||User Story||79307||Other / General||
''T&L Sales clerk' and 'T&L Warehouse worker' security roles newly have read access to more tour elements
As needed for several business processes, the security roles 'T&L Sales clerk' and 'T&L Warehouse worker' newly gains a read access to several tour elements, eg. orders in tour etc. Read only access was achieved by assigning a duty 'View tour orders' to both security roles.
|2021-02||User Story||80095||Other / General||
Adjustment of the security parameterization for 'Release tour/leg to warehouse' functionality (duty 'Release to warehouse')
To reduce the need for Full user TAL license amount, an access to 'Release tour/leg to warehouse' functionality has been removed from the 'T&L Warehouse worker' security role, as the 'T&L Warehouse worker' security role requires only Light user TAL license.
On the other hand the security role 'T&L Dispatcher' gained access to 'Release tour/leg to warehouse' functionality, as the 'T&L Dispatcher' security role already requires Full user TAL license.
|2021-02||User Story||77606||Shipment Builder||
Connect container structure to shipment builder
This feature enables the shipment builder to support the automatic containerization process.
At container closing, the shipment builder entities will be updated based on the available information of the container / container type.
At transport order synchronization, the system creates 1 CAPcargo package per container. The volume and weight of the packages are retrieved from the container type and items.
In case a container gets reopened, the related packages will be deleted and the related shipment builder entities get updated.
Multi-level containerization is not fully supported with this feature. The shipment builder can handle multi-level container but only the most outer container (=container level 0) will be considered for transport and plan quantity calculations.
Please note (info for existing customers):
- The parameter “Flexible volume dimensions” on container types has to be set to YES in order to make it work as today.
|2021-02||User Story||78721||Subcontracting/IC invoicing||
Change of the posting profile on the vendor orders doesn't anymore invalidate the previously existing price calculation
Previously, on vendor order types, when changing the posting profile manually on the order (that was previously calculated), the order price calculation was invalidated (ie. 'Calculated' flag was reset to FALSE). As a consequence, the price calculation had to be performed again, to have order calculated. Such behavior was different to the customer order types (where change of posting profile doesn't reset the price calculation).
The behavior on vendor order types was enhanced, to follow the same logic as on the customer order types.
|2021-02||User Story||79605||Subcontracting/IC invoicing||
Enhancement of the vendor invoice posting process, to manually specify the vendor invoice number
Vendorinvoice posting process was enhanced, to optionally populate also the invoice number(on all vendor invoice journal lines), if specified in the vendor invoice poolposting dialog (in new field 'Vendor invoice').
Additionally both vendor invoicing flows (vendor invoice & vendor self-billing) were adjusted, so that each invoicing flow newly uses a separate dedicated number sequence. Previously both invoicing flows shared one number sequence (parameterized under 'Vendor invoice' in main TMS parameters), which was newly renamed to 'Vendor self-billing invoice' (and serves now only for the self-billing posting purposes). New number sequence parameterization for 'Vendor invoice' was added to the main TMS parameterization, for the vendor invoice posting purposes.
- the new number sequence parameterization for 'Vendor invoice' is by default empty and has to be manually specified in the main TMS parameters, by projects that use this functionality.
During the invoice reversal of the transport order system sometimes asked for print destination settings even though no printing of reversal/credit note was activated
The issue was corrected, now the system asks for print destination details only when printing of reversal/credit note is activated in the reversal dialog.
Custom invoice layouts couldn't be used when generating TMS customer invoice
Via print management, it is possible to define a custom layout of the TMS customer invoice. The issue was that such custom invoice layout was ignored and standard default TMS customer invoice layout was always used. The issue was corrected and custom invoice layout is now used when it is defined and activated in the print management.
|2021-02||Bug||43122||Customer order management & pricing||
Overuse of the package ID number sequence
Previously, the package (that was manually created by user) did skip a number in the package ID number sequence. The issue was corrected and the package ID number sequence is allocated correctly even for manually created packages.
|2021-02||Bug||49411||Customer order management & pricing||
''Over package' scope could get broken in certain order management scenarios
''Over package' scope (ie. several packages are linked to the same package parent id) should be processed (ie. planned into tour, removed from from tour) as a whole, to avoid that part of the over package is planned into tour and part not (or part is planned in the different tour etc.). The issue was that in certain order management scenarios the 'over package' scope could get broken. This was happening especially when the packages of two transport orders were linked to the same parent package id (ie. 'over package' scope across different transport orders) and one of the transport orders was removed from dispatching (either via menuitem 'Delete order from dispatching' on non-shipment builder transport order; or via menuitem 'Remove from transportation' on trade order lines). The issue was corrected and such transport order is not anymore removed from dispatching (if it would break the 'over package' scope) and user is informed via error infolog.
|2021-02||Bug||78472||Customer order management & pricing||
Missing time stamps for certain track & trace statuses
Previously, time stamps were missing for following track & trace statuses:
* (Status430) - Delivered by sender
* (Status436) - Picked up by receiver
The issue was corrected and both track & trace statuses are now properly marked by time stamp when the status was reached.
|2021-02||Bug||79190||Customer order management & pricing||
Newly created address was not visible in the return sales order creation dialog
Previously when creating a new shipping address (via address creation wizard in the return sales order creation dialog), the shipping address on the return sales order dialog was not automatically updated. The issue was corrected, the details of newly created address are immediately visible on the return sales order creation dialog, once address creation wizard is closed.
|2021-02||Bug||79400||Customer order management & pricing||
The change of the values in header section of the transport order line view was sometimes not saved (ie. lost)
The change of the values in header section of the transport order line view was sometimes not saved (ie. lost). This was happening when header section changes were not manually saved and user continued to change the line section values (eg. transport quantity). Then the line section values (eg. transport quantity) were successfully saved but header section values were just reloaded from database, without saving the changes first. The issue was corrected and header section changes are also first saved, before the automated reload happens.
|2021-02||Bug||44167||Dispatching & confirmation||
Several issues were corrected in the transport leg related forms
Following issues were corrected in the 'Dispatch light - Transport legs' screen:
- Only first few records/transport legs showed the correct planning quantity (in the right info section). The rest transport legs showed zero planning quantity
- Some fields were directly editable (eg. planning quantity or conflict state)
- When new fields were added to the grid (via form personalization) then sometimes the new fields were immediately opened for user changes
Following issues were corrected in the 'Transport leg points' form (which can be launched from transport order form):
- Some fields were not displayed correctly for the second transport leg point record (eg. address ID was missing on unload leg point)
- Some fields were directly editable (eg. planning quantity, transport leg type checkboxes)
|2021-02||Bug||64544||Dispatching & confirmation||
Docking/undocking icons were sometimes not shown in the tour stop overview in both GPB gantt screens
When the docking (or undocking) activity occurs on the tour stop, the tour stop is highlighted by the small icon below the tour stop overview (aka. in level 3), in both GPB gantt screens. The issue was that the visualization of these icons was not reliable - sometimes the icons were shown, sometimes not, sometimes the icons disappeared when changing the focus between the tours etc. The visualization is now corrected.
|2021-02||Bug||77414||Dispatching & confirmation||
Conflict visualization on the tour was not automatically refreshed when conflict analysis was done automatically during the tour release
The conflict visualization on tour was not automatically refreshed when conflict analysis was done automatically during the tour release, so dispatchers didn't have accurate information about the detected conflicts. The issue was corrected and the conflict visualization on tour is refreshed after the tour release, in both gantt screens.
|2021-02||Bug||77588||Dispatching & confirmation||
Duplicated gantt grid refresh in certain scenarios when dispatchers rearranged the tour stop sequence (via drag and drop)
Previously, when rearranging the tour stops (via drag and drop in GPB gantt screens) in certain constellations the GPB performed a duplicate grid refresh. The issue was corrected and the gantt grid is now refreshed only once after rearranging the tour stop sequence.
|2021-02||Bug||78643||Dispatching & confirmation||
Goods planning status 'To be picked up by receiver' was sometimes showing on transport legs even on non-receiver business cases
Goods planning status 'To be picked up by receiver' was sometimes showing on transport legs even on non-receiver business cases. This was especially happening after the removal of depot split from transport legs. The issue was corrected and the proper goods planning status 'Ready for collection' is shown on transport legs.
|2021-02||Bug||78879||Dispatching & confirmation||
Several menuitems were not accessible in the forms for users without 'System administrator' security role
Following menuitems were accessible in the forms only for users with 'System administrator' security role:
In 'Dispatch light - Transport legs' form:
- Sync transport order
- Dispatch in tour
- Release to warehouse
In tour confirmation form:
- Revoke package conf. (complete tour line)
In global address book address detail form:
- CAPcargo edit coordinate
Issues were corrected, menuitems don't anymore require 'System administrator' security role.
|2021-02||Bug||79244||Dispatching & confirmation||
Duplicated packages after a failed delivery registration
Process of registration of a failed delivery could in some cases lead to the corrupted data in transport leg & tour structure. The visual impact to user is that the packages get duplicated after performing the failed delivery but in fact the problem was caused by corrupted data in the transport leg & tour structure. The issue was fixed and the failed delivery process behaves correctly now.
|2021-02||Bug||79286||Dispatching & confirmation||
Confirmed tour quantity sometimes failed to update the planning quantity on the successor transport legs
In certain data constellation, confirmed tour quantity sometimes didn't update the quantity on the successor transport leg. This was only happening on successor transport legs which were not yet planned into any tour and which were not directly succeeding (ie. there was at least one depot split between the tour stop that is being confirmed and the successor transport leg). The issue was a regression of task from the TAL 10.0-CAP9.0 release, which was realized only recently and is fixed now.
|2021-02||Bug||79365||Dispatching & confirmation||
Missing address name dropdown, in the dialog of 'Change unload address' menuitem, in the 'Dispatching light - Transport legs' form
Previously, in the 'Dispatching light - Transport legs' form, in the dialog of 'Change unload address' menuitem, the address name dropdown worked correctly only for users with 'System administrator' security role. The issue was corrected and address name dropdown now opens correctly even for users without 'System administrator' security role.
|2021-02||Bug||79367||Dispatching & confirmation||
Tour details (in level 2) in GPB gantt screens were not refreshed correctly in some cases, so the traces of tour were still visible on the screen (in level 2) even when tour was removed from the gantt
The issue was happening for example when dispatchers changed the owner company, then tour disappeared from the main gantt grid but the tour details (aka. level 2) were still left visible in the gantt screens. The issue was corrected, the section with tour details (level 2) is now automatically refreshed when the main gantt grid is refreshed.
|2021-02||Bug||79680||Dispatching & confirmation||
GUI enhancement of the visualization of the generic buttons on the GPB Resources screen
Previously the generic buttons on the GPB Resources screen got graphically distorted once pressed. The issue was corrected.
Also the general compatibility of the generic buttons in Resource screen was improved, to cover more business cases.
|2021-02||Bug||79737||Dispatching & confirmation||
Wrong activity status after certain dispatching actions
Certain dispatching actions can lead to the copy of activity (for example from existing tour stop to new tour stop). The issue was that the activities were copied also including the activity status. This was happening for example when a failed delivery was performed on a tour that already had some unload activities with status 'in progress' (and user didn't decide for transport order cancellation). Then the new tour stops were generated and their activities inherited the 'in progress' status. The issue was corrected, now the activities are copied but their confirmation status is reset.
|2021-02||Bug||80123||Dispatching & confirmation||
Quantity split on transport leg failed with generic error in some complex dispatching cases
Splitting a transport leg (via quantity split) on certain complex dispatching cases could fail with generic error 'Cannot create a record in Orders in Tour (CIRTRATourOrderLine). Order: TO-123456. The record already exists.'. This was especially happening when 'Promote confirmed quantity to successor planning leg' feature was activated in the transport type parameterization. The issue was simulated on certain complex (and rather hypothetical) dispatching case where several quantity splits were combined with several depot splits, together with different confirmed quantities in the tour confirmation. The issue was corrected and quantity split mechanism was improved to cover such case.
|2021-02||Bug||80236||Dispatching & confirmation||
Selected transport leg is sometimes unselected in GPB 'Transport orders /-legs' screen when full grid refresh is triggered
In GPB 'Transport orders /-legs' screen, when full grid refresh was triggered (for example by performing a depot split), then previously selected transport leg got sometimes unselected. This was especially happening when more transport legs were filtered than could fit onto one screen. The issue was corrected and selection of transport leg is now preserved even after the full grid refresh.
|2021-02||Bug||80306||Dispatching & confirmation||
Failed pickup: Wrong scheduling in some constellation
It could happen that the 2nd attempt to re-pickup was wrongly scheduled. It is supposed to be scheduled at least +1 day after the failed pickup attempt, maybe later depending on the opening dates and route scheduling. The bug was, that this scheduling was not properly respected and it even could happen that the re-pickup date (load of 2nd attempt) was after the unload date of the 2nd attempt. - This was fixed.
Address lookup in the fuel location setup showed wrong address name (or no address name at all)
When creating a new fuel location, the transport address lookup was showing wrong address names (or no address names at all), when lookup filtering option 'All' was used. The issue was corrected and the fuel location address lookup now shows correct address names.
Address area couldn't be deleted
Previously it was not possible to delete an address area (either from transport address or directly in the main menu in address area setup); the delete action failed with error 'Field Vehicle must be filled in.'. The issue was corrected and address area can be deleted.
|2021-02||Bug||78755||Other / General||
Specifying 'miles' as PTV 'Distance unit' didn't calculate the driving distance in miles, but still in kilometres
When the 'Distance unit' was specified as 'miles' (in the Geo services in main TMS parameters) then such parameterization was previously not respected (as system requested the PTV map component still for result in kilometres). The issue was corrected, and system now supports also the driving distance calculation in miles.
- When switching the PTV 'Distance unit' to 'miles' (in the Geo services in main TMS parameters) then also the 'Distance' (and 'Distance (empty)' & 'Distance (loaded)') in the main TMS parameters must be specified in units that have a 'System of units' classification as 'United States customary units', in order to get correct result in miles.
Display of TMS scheduling information (on D365 trade order lines) was not following the 'Modes of delivery' parameterization
On 'Modes of delivery' it is possible to define whether TMS scheduling information (that is available as 'CAPcargo scheduling information' on D365 trade order lines) shall be shown either for load part, or for unload part, or for both. The issue was that the 'Modes of delivery' parameterization was ignored and CAPcargo scheduling information was shown always for load & unload parts. The issue was corrected and the setup on 'Modes of delivery' is now respected.
Wrong warning in certain cases when trade order line cannot be removed from transportation
When a trade order line cannot be removed from transportation (because of transport order being too far in the process) the system in certain cases showed wrong warning. This was especially happening when 'Partially remove from transportation' parameter was activated in the CAPcargo Trade & Distribution main parameters.
Previously the system showed the warning 'Order line SO-123456 / 1.00 has been partially removed from transportation.', which was wrong, as the order line was not removed from transportation.
The warning was corrected, now it properly informs the user that 'The order line SO-123456 / 1.00 cannot be removed from transportation! The linked transport order is already too far in the dispatching process (Parameter settings, tour release/confirmation, sub-contracting etc.) or has been manually part-delivered.
SO-123456 order id, 1.00 line id wasn't removed from transportation.'
Function 'Remove from transportation' on trade order lines didn't work correctly when only shipment lots were existing
By menuitem 'Remove from transportation' (accessible on trade order lines) it is possible to remove TMS shipment lots, remove TMS shipments, remove transport order/legs etc. The issue was that the menuitem performed correctly only when TMS shipment lots were assigned to some TMS shipment. The issue was corrected, now the menuitem 'Remove from transportation' removes TMS shipment lots even when they are not assigned to any TMS shipments.
Third party LTL transport leg sub-contracting tariff surcharges were in certain constellation not processed during automated vendor invoicing
In vendor invoice automation process, it is possible to setup a rule that orders gets also calculated (via 'Calculate orders first' parameter). The issue was that the price calculation (when launched as part of automated invoicing process) didn't calculate the third party LTL transport leg sub-contracting tariff surcharges, which were in result also not invoiced. The issue was corrected and such third party surcharges are now correctly processed (ie. calculated & invoiced) when 'Calculate orders first' parameter is used in automated invoicing rules.
|2021-02||Bug||78968||Subcontracting/IC order management & pricing||
Re-calculation of FTL sub-contracting tour order sometimes didn't happen correctly
Re-calculation of FTL sub-contracting tour order (which was previously already calculated) sometimes didn't happen correctly. The FTL order seemed calculated by new tariff quantity (as the 'Calculated' flag was checked), but the order totals were still showing the old (now obsolete) price. The issue was fixed and the order totals are calculated correctly even after the re-calculation of previously calculated order.
|2021-02||Data conversion||78583||Master data||
Data migration job for task 77654 (Customer self-billing), to update transport order / default order
Data migration job for task 77654 (Customer self-billing) to have existing transport order (and default order) transactions compatible with the new feature of customer self-billing.
|2021-02||Data conversion||78587||Master data||
Data migration job for task 77654 (Customer self-billing), to update customer account
Data migration job for task 77654 (Customer self-billing) to have existing customer accounts compatible with the new feature of customer self-billing.
|2021-02||Data conversion||78593||Master data||
Data migration job for task 77654 (Customer self-billing), to update customer invoices
Data migration job for task 77654 (Customer self-billing) to have existing customer invoices compatible with the new feature of customer self-billing.
|2021-02||Data conversion||79346||Master data||
Data migration job for the task 76529 (New feature: cleaning framework and truck loading history)
The data migration job populates new field 'Level' on Activity time class table by value 'None' on all existing time class records.
|2021-02||Data conversion||79347||Master data||
Data migration job for the task 76529 (New feature: cleaning framework and truck loading history)
The data migration job populates new field 'Level' on 'Activity Time per Address' table (on the transport address) by value 'None' on all existing 'Activity Time per Address' records.
|2021-02||Data conversion||79608||Master data||
Data migration job for the task 79588 ('Driver acceptance before tour start' enhancement)
The data migration job populates the new parameter 'Driver acceptance before tour start' from the old parameter 'Driver must accept the tour', in the main TMS parameters.
|2021-02||Issue||80231||Dispatching & confirmation||
KNOWN ISSUES or missing functionality in the area of failed pickup and failed delivery
The entire process of failed pickup and failed delivery has been redesigned and fully integrated to the Driver App. The main features are available and successfully tested. The following issues/topics are not yet implemented:
-  Special case which is not fully nor partialy failed pickup
If a transport order consists of 2 order lines and one of them fails entirely in picking up, then this is currently not properly covered. From an order perspective it is a partial failure (which currently focuses on splitting off quantities from an order line), and from a practical perspective is fully failing an entire "position", but full failure will fail the complete order currently. - Concept and implementation to be enhanced in a future release.
-  Unload list report
The unload list still prints the "dummy/zero-qty/pre-confirmed" unload point from the failed pickup leg. Should be suppressed for better UX.
-  Partially failed delivery not available in TAL yet, only fully failed delivery.
The Driver App allows though partial failure for load and unload, hence would support partial failed delivery, but cannot be handled then by TAL. - Concept and implementation to be enhanced in a future release.
-  Multiple partially failed pickup with different reason codes not supported
Driver App supports to fail pickup of every single package and enter as well for each a different reason code. In TAL that process is grouped and only one reason code per failure can be handled. - Concept and implementation to be enhanced in a future release.
-  Partially failed pickup not supported for order from shipment builder
In TAL we don't support partially failed pick-up (= quantity split) for transport orders originating from trade module (shipment builder) because the splitting of records would lead to unclear references in the WH module. However, the app itself cannot validate this yet and hence would allow a partial failure of pickup, which would lead to an error in TAL. In reality this would not be a very realistic scenario, since pick-up happens in the own warehouse. If there are some issues they should be solved before driver has to load them
|2021-02||Issue||80270||Dispatching & confirmation||
KNOWN ISSUE: Special case "Depot split after removed/reduced part-delivery" promotes wrong quantities
If a transport order (e.g. 10 PAL) is part-delivered, i.e. split into 2 legs (e.g. 8 PAL & 2 PAL), then we have the option to end one path, for example, if the customer decides to not need the transportation of the 2 PAL anymore. With the function "remove part delivery" this is achieved.
If now, the dispatcher decides to ship the remaining 8 PAL via a hub, he can perform a depot split. Here the issue happens, the successor leg (Depot to Receiver) initiates the quantity of 10 PAL instead of 8 PAL.
This issue will be fixed asap in a next release with #80232.
|2021-02||Issue||80312||Dispatching & confirmation||
KNOWN ISSUE: Failed pickup: Retry within same order schedules the confirmed/failed leg points
After failed pickup a 2nd retry can happen within the same transport order. This will create a 2nd leg while the first leg will be put to "failed" and "confirmed":
- 1st leg A-A, 0 qty, failed, confirmed
- 2nd leg A-B, x qty, open to dispatch
The depot split function reschedules all the legs, instead of only the 2nd leg (because first is already confirmed). Depending on the setup (e.g. route weekday scheduling indicates closed on the confirmed date - which would be quite rare), then the scheduler could update the planning dates of the first leg to a later date, which is wrong. However, the confirm date is not touched and since the leg is anyway already confirmed, these potentially wrong planning dates will appear nowhere in the planning process. Also track & trace is not affected, since that bases also on [correct] confirm dates.
Will be fixed with ADO 80311.