Our August Enable update is now available within your UAT (user acceptance testing) environment. This provides the perfect opportunity to test newly introduced features, solution improvements and performance enhancements.
Enable’s proactive approach to Enable updates ensures that our software is constantly being improved and enhanced. Working within 6-week development cycles means we can deliver regular updates to you in easy to manage bitesized portions. Our methodology ensures that all of our clients are free to concentrate on their core business, whilst we focus on keeping the key software platforms maintained to the highest standard. This newsletter provides an overview of our latest Enable update.
As well as research-led development based on current market demands, many of our updates result from feedback received from our clients. Any feedback, positive or negative, that you have on Enable can be submitted via email to projects@enable.com. Our dedicated Client Services team will be on hand to answer any queries you may have.
Our latest update was deployed to your UAT environment on 10th August 2018 and is now available for testing. This UAT environment is separate to your Live environment and provides a suitable testing platform without any risk to the integrity of your live data.
The UAT process will last for approximately 5 weeks. During this time you will be able to try out the new features and give us your feedback. The update will be deployed to your Live Enable environment on 18th September 2018.
This update contains a combination of new features, feature enhancements and performance improvements. The majority of these changes will be deployed as standard to your Enable system. There are however, certain new features and enhancements described in this document which are only available by request, as they require additional configuration in order to be applied to your Enable system.
Please contact a member of your Client Services team for more information.
A new setting called Turnover line includes primary key has been introduced, and will be turned off by default. The setting can be turned on by an Enable system administrator, by request only.
This setting can only be enabled if there is no turnover line (reconciled, unreconciled or unmatched) which does not have a primary key. If there is a turnover line without a primary key, then this setting cannot be enabled. If there is no existing turnover then this setting can be enabled.
If this setting is on, then both the manual and automated turnover imports will require an additional column in the import file labelled ‘Primary key’. This will allow a unique key (known as the ‘Primary key’) to be associated with imported turnover lines. It can also be used to delete an existing turnover line with this key or recreate a single turnover line with this key.
In addition, when this setting is on the ‘Primary key’ value for a turnover line will be included in turnover shown in some areas, such as the unreconciled turnover report and the unmatched turnover report.
Previously, unreconciled turnover lines could only be deleted one supplier at a time and required an admin user to enter their password once for each supplier. An admin user will now be able to delete unreconciled turnover lines for multiple suppliers en masse, where they will only have to enter their password once to confirm the action.
Value and unit figures used in the calculation of the following values for Apportioned fixed amount and Apportioned external earnings calculation plugins are now stored within the system.
This change has no effect on the system currently, but these values will be used in future enhancements.
When determining the value that should be deducted from eligible turnover when calculating baseline earnings for a deal, the baseline earnings of any deduction deals will now be used. No baseline earnings for deals will be recalculated, but calculations will use the baseline earnings of deduction deals going forward.
Previously, when a deal was configured with a deduction deal, the earnings of the deduction deal were subtracted from the turnover before earnings or target calculations are performed.
The system has been updated so that the turnover value that is stored is the turnover value before any deduction deal earnings are subtracted. This applies to:
Non-retrospective growth deals have been identified as not required within the system, and therefore the pane has been changed so that it is no longer possible to configure a growth deal to be non-retrospective. A user will still be able to choose whether a deal is fully retrospective or retrospective. The default selection for the deal configuration will be fully retrospective. This change is available immediately within the Live environment and helps simplify the configuration of growth deals.
For growth deals, the scaled accrual earnings calculation has been enhanced to ensure that the discount percentage configured for the deal is included in the scaling ratio applied to the accrual earnings. Additionally, if configured, the baseline value is included in the scaling ratio where it wasn’t previously. This helps ensure the accuracy of the scaled value when accrual bands are entered “net” of the baseline. These enhancements have been made available directly within the Live system to allow users of these deals types to benefit from these changes immediately.
A new setting Stop automatic baseline calculation after (days) is now available for Enable system administrators to configure, by request. This is to allow for deals to be removed from the automatic recalculation queue after a certain time for performance reasons. This setting determines the number of days after the end of a deal’s baseline period for which Enable will continue to automatically recalculate baseline earnings. This setting will default to ‘30’.
A new setting Baseline scaling completion delay (days) is now available for Enable system administrators to configure for you, upon request. This setting will determine the number of days that will pass between the ending of the baseline period of a deal and the triggering of a recalculation of baseline turnover line unit and value results. This setting will have a default value of ‘5’.
A new setting Forecast scaling completion delay (days) is also now available for Enable system administrators to configure, by request. This setting will determine the number of days that will pass between the ending of the deal period and the triggering of a recalculation of actual forecast deal earnings. This setting will have a default value of ‘5’.
Where a scaling factor is used, a constraint has been applied to ensure that the factor is always greater than or equal to 1. Where the scaling factor is less than 1, a factor of 1 will be used instead.
The calculation of baseline earnings has been updated to use the client latest transaction date in the scaling factor rather than the deal latest transaction date. The new scaling factor for baseline value and units is X / Y where X is the number of days between the start date of the baseline period and the end date of the baseline period (inclusive) and Y is the number of days between the start date of the baseline period and the client latest transaction date.
The calculation of forecast earnings has been updated to use the client latest transaction date in the scaling factor rather than the deal latest transaction date. The new scaling factor for forecast value and units is X / Y where X is the number of days between the start date of the deal period and the end date of the deal period (inclusive) and Y is the number of days between the start date of the deal period and the client latest transaction date.
Changes have been made regarding the calculation triggers of both proposal schemes and workflow status.
The process for calculating baseline earnings will continue to run on demand for the affected deals whenever the standard process is triggered by a deal being created, a deal being edited, or a scheme being edited. It will continue to run as a scheduled process that calculates baseline earnings for every deal where the set of baseline turnover or the deal dimension items have changed since the process last ran. The process will only run for deals where less than X days have passed since the deal end date, where X is the value of the Stop automatic baseline calculation after setting.
The process for calculating baseline earnings now considers deals that belong to proposal schemes as well as those that belong to active schemes.
The process no longer considers the workflow status of a scheme when determining whether to perform a recalculation of the baseline earnings. This means that baseline recalculation will now occur for schemes where workflow is in progress or completed.
A Recalculate baseline earnings button has been added in the baseline tab for a scheme that when clicked triggers a recalculation of the baseline earnings for all deals within that scheme. This button will trigger the recalculation regardless of the current workflow status of the scheme. This enhancement will not change functionality — it will only trigger the process as it currently exists.
When a deal’s baseline period is X days past its end, where X is the value of the Baseline scaling completion delay setting, then the baseline earnings are recalculated by an overnight process. The purpose of this new trigger is to ensure that when the baseline period has ended, the baseline results accurately reflect the actual earnings of the deals that were active during the baseline period. This new trigger will cause recalculation regardless of the current workflow status of the scheme to which the deal belongs.
When forecast earnings or baseline earnings are calculated for a deal after the threshold date (defined as the configured number of days after the end date of the deal or baseline period), then no scaling factor is used in the calculation.
When a deal is Y days past its end date, where Y is the value of the forecast scaling completion delay setting specified above, then the forecast earnings will be recalculated by an overnight process. This new trigger ensures that when the deal period has ended, the forecast results match the actual results. This new trigger causes recalculation regardless of the current workflow status of the scheme to which the deal belongs.
A new weekly process has been added to Enable in order to update baseline and forecast earnings for deals where they are not being recalculated due to turnover or dimension item changes. The process will not run if the client latest transaction date has not been updated since the process last ran.
The weekly process now recalculates baseline earnings for all deals where the deal latest transaction date is prior to the date that the weekly process last ran and the baseline period end date is after the date that the weekly process last ran. The weekly process also recalculates forecast earnings for all deals where the deal latest transaction date is prior to the date that the weekly process last ran and the deal end date is after the date the weekly process last ran.
When a deal is calculated, the scaling now uses the client latest transaction date (going forward). If no other change to the deal or turnover triggers a recalculation of the deal, then the scaling will become out-of-date as the client latest transaction date moves on. The scaling factor may have used a client latest transaction date that has since changed.
We have enabled HTTP/2 for Enable in Azure hosting environments. This will provide an immediate minor performance improvement in web browsers that support HTTP/2, which is the case for all modern browsers. Enabling HTTP/2 in the hosting environment is the first step in unlocking further potential performance benefits which can be realized when we begin to optimize the system for HTTP/2.
We have enabled Brotli compression for Web API responses. Brotli is a modern compression algorithm which is more efficient than previous compression standards and will provide a minor performance improvement for modern browsers.
We have improved system behavior when a user becomes signed-out whilst using a “child” application within Enable. Previously, the system would show an error message with a Go back button which, when clicked, resulted in the Enable sign-in page being displayed incorrectly (i.e. not the full browser window). In this scenario the system now shows a Sign in button which, when clicked, navigates the user to the sign-in page at the top level of the browser window.
We have implemented additional background logging for Enable functionality. This will provide Enable’s Development team with a more thorough and efficient way of troubleshooting unexpected problems that users may encounter.
A database query that forms part of the net spend calculation functionality has been identified as being resource-intensive. This query has been re-written so that it now takes several seconds instead of minutes to complete.
In line with Enable’s commitment to release an Enable update every six weeks, our next update will be deployed for testing within your UAT environment on 21st September, with deployment to your Live environment to take place on 30th October.
As part of our September update, we will be making further performance optimisations and platform enhancements. Alongside this, we will be introducing a series of new functionality, as well as enhancing existing Enable features. Here’s what you can expect in the next cycle.
A new collection setting will be available entitled “Enable mapping”. This will enable or disable dimension item mapping for each collection. When enabled, the system will allow you to maintain (view, export or import) a list of mapped deal dimension items. These mapped deal dimension items will allow zero, one or more different dimension item references to be mapped to a single dimension item. These mappings will not be visible in areas of the system such as the “Scheme PDF”, but will be used in calculations when matching earnings (which can use the dimension item reference, or a mapped dimension item reference).
This entire functionality will be optionally enabled or disabled at the client level by an Enable system administrator, and will be disabled by default.
Changes for the client final role, and client first role in the scheme signatories functionality will select the first signatory alphabetically where more than one signatory has matched the existing selection rules. If no candidate signatories match, then the signatory will be left blank in line with current functionality.
The Watchlist app excel report download currently contains 2 tabs. Both tabs will be enhanced to include a “Note” column which will contain the note that was entered by the user when setting the accrual band for the deal to which the report row relates.
“Earnings at risk” and “Earnings to gain” calculations will also be updated to ensure they continue to use the accrual band selected by a user rather than the actual band, even if the actual band is higher.
During the calculation of rebate (group) and rebate (by client division), earnings where the parent scheme is a proposal, will no longer be included. This has the effect of ensuring that the net spend (group) and net spend (by client division) values only include earnings from active or interim schemes.
If you have any questions regarding our current or upcoming Enable updates, please contact your Client Services team at projects@enable.com.
.svg)