Release 1.3.0 (04/10/2021)
Guidance notes on the release 1.3.0
Last updated
Guidance notes on the release 1.3.0
Last updated
The largest change to the platform in this release. This change centers around simplifying the Transactions view, in particular the Bookings page and how users view their upcoming bookings and apply filters to organise their priorities.
With this change to the platform, the 'cycle status' column has be renamed as 'Settlement Status' and the two statues of 'Next Cycle' and 'Future Cycle' have been combined and now display as 'Due'. This change means that regardless of whether a booking is committed by the Seller in time for the upcoming cycle or not, they receive the same status of 'Due' and will therefore be displayed to the buyer with immediacy. To support the differentiation between which bookings require priority when a buyer is performing their review, the platform has also been updated to include estimated dates for when a booking is due for collection (Collection Date column) and payment (Payment Date column). The Collection Date and Payment Date columns can be filtered to support the organisation of priorities. To further highlight where dates are estimated, the relevant data will be highlighted in amber.
Below is an example of the display with the aforementioned changes underlined:
Guidance on this area can be found under Review Bookings.
Reason codes have been updated to be the same when both amending or rejecting a booking under Transactions > Bookings. These reason codes were not previously aligned whereas the same list is now presented for both transaction statuses. See Review Bookings for guidance on this area.
The platform will store the batch Id generated from PTX as the 'PaymentRef' of remittances.
Previously, users with a role type 'Normal' could not access Task Scheduler. Both Normal and Admin users now have access to Task Scheduler for their company. See Scheduling Reports for further guidance on this area.
Previously, users with a role type 'Normal' could not view notifications in the platform. Both Normal and Admin users now have access to notifications for their company/companies. See Notifications for further guidance on the display and configuration of notifications.
Notifications can be quite a 'busy' area of the platform, it is therefore now the default for all users, upon registration, to have their notifications configured to a default delivery method of in platform. Email notifications are switched off as default, however they can be configured to on through the Configuring Notifications area.
Previously, if a user profile was updated (Companies and Users > User Profiles) the platform was failing to display error messages if mandatory information was left blank or duplicate email addresses were provided. Users will now see error messages displayed and will be unable to complete a profile update where information does not meet the criteria. See User Management for guidance.
Where a branch of a Head Office has its own users, it is no longer required to review and accept the terms and conditions of the Travel Ledger platform as this will have been completed by the Head Office when they registered initially. See Registering as a New Company for guidance on this area.
When a Seller head office uploaded transactions on behalf of a branch, the Seller branch ID was displaying in the Partner ID field instead of the Buyer ID (correct behaviour).This has now been resolved to display the Buyer ID data in the Partner ID field. See File Format for Upload for guidance.
The behaviour has been fixed for payment validation to only happen at file commit.This was causing duplicate notifications for the PE, they will now only receive one message.
