Our June 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 email@example.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 29th June 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 7th August 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 optional application is now available by request called the Watchlist App. This Watchlist App is concerned with targeted deals that may be either close to missing a band and having lower than forecast earnings or close to obtaining a higher band and improving their earnings. This new application will provide an area where a user can access an overview of deals that will guide action, such as proactive spending or accrual revision.
Once enabled, the Watchlist App will contain three tabs – one for ‘Opportunities’, one for ‘Risks’ and one for ‘Settings’. A full breakdown of all areas of functionality available within the Watchlist App can be found below.
Within the Opportunities tab, there is a tile per supplier which is displayed in descending order of the value of earnings impact for the biggest opportunity within the supplier. Clicking on a supplier tile shows a listing of targeted deals.
When a supplier is expanded, the deal rows within that supplier are displayed in descending order of the value of earnings impact.
Each deal row has a View bands option which displays a view of the deal’s turnover bands where actual, accrual and forecast bands are identified.
The Risks tab will show a tile per supplier which will be displayed in descending order of the value of earnings impact for the biggest risk within the supplier. When a supplier is expanded, the deal rows within that supplier will be displayed in descending order of earnings impact. Clicking on a supplier tile shows a listing of targeted deals in the same way as the Opportunities tab.
Admin users will have access to the Settings tab within the Watchlist App and will be able to change the following settings:
It is possible for a user to download an Excel data file containing the watchlist data. Once downloaded, the Excel data file will contain one sheet for opportunities and one for risks. The data is not limited by the display limit set in the Settings tab.
If no manual forecast has been entered for a deal, the turnover target from the current accrual band is used in place of the manual forecast in all relevant calculations and for display in a deal row within the watchlist app. If no manual forecast has been entered and there is no accrual band for the deal, then the deal will not be displayed in the UI, although it will still be represented by a row in the watchlist download.
The framework has been built for an Executive Summary application to be built into Enable. This is intended to provide Enable users with a summary of a scheme as it passes through the approval workflow in order to allow their users to approve the scheme with the minimum of effort.
In order to integrate this functionality, additional build work will be required in order to design and integrate your business specific templates. If you have any further questions on implementing this functionality into Enable, please contact a member of Enable’s Customer Success team.
Collections whose dimension ‘Display type’ attribute is set to Reporting only no longer appear within the list of collections to select within the deal configuration area. This prevents unexpected errors that occurred when trying to select the dimension items from these collections.
Performance enhancements have been made to improve the efficiency of calculating a large number of deals. In this scenario deals will now be batched into manageable chunks to avoid users having to wait for extended periods of time when processing deals.
The pager on the Browse > Suppliers page and Config > Turnover > Reconciliation page has been updated to relocate when a right panel slides after clicking on a supplier.
For clients that require load tests to be run, we have made improvements to the load test results for ‘Queued’ and ‘Processing’ total averages. This will make load test results more accurate. For more information on load testing, please contact a member of Enable’s Customer Success team.
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 10th August, with deployment to your Live environment to take place on 18th September.
As part of our August 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.
Currently, when a deal is configured with a deduction deal, the earnings of the deduction deal are subtracted from the turnover before earnings / target calculations are performed.
The system will be updated so that the turnover value that is stored will be the turnover value before any deduction deal earnings are subtracted. This applies to:
A new client level setting named Turnover line includes primary key will be available and will be turned off by default. The setting can only be turned on by an Enable platform administrator, will be available by request only and will not be presented as default.
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 allows a unique key (known as the ‘Primary key’) to be associated with turnover lines imported and can also be used to delete any existing turnover lines with this key and 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.
A new setting Baseline scaling completion delay (days) will be added to the deals tab of the platform configuration area. 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) will also be added to the deals tab of the platform configuration area. 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’.
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 should be used. No baseline earnings for deals will be recalculated, but calculations will use the baseline earnings of deduction deals going forward.
A new client level setting Stop automatic baseline calculation after (days) will be added to the deals tab of the platform administration area. This is to allow for deals to be removed from the automatic recalculation queue after a certain time for performance reasons. This setting will determine 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’.
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 will now consider deals that belong to proposal schemes as well as those that belong to active schemes.
The process will no longer consider 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.
Currently the system does not store the value and units figures used in calculation of:
The system will be updated to store the value and units figures used in these calculations. These enhancements apply to the Apportioned fixed amount and Apportioned external earnings calculation plugins.
The figures stored will be scaled up appropriately to either the baseline period, or the deal period, as per the current rules for scaling turnover for deal plug-ins that are not apportioned fixed amount or apportioned external earnings.
Accrual earnings calculation
When calculating the scaled accrual multiplier, the baseline will be added to the denominator when calculating the scaled accrual multiplier. This will be the case with all growth deals where the manual forecast is expressed net of the baseline, i.e. targeted percentage or unit rate growth deals with unit or value targets. This will change for cases where ‘require manual forecasts’ is turned ON, where manual forecasts are not entered and where the threshold of the accrual band is used.
Scaled accrual earnings
The calculation for scaled accrual will be updated to use the discounted actual turnover instead of the full actual turnover. The scaling ratio for scaled accrual earnings will be X / Y where X is the actual turnover multiplied by a factor of ((100-D)/100) where D is the discount percentage that was entered when configuring the deal, and Y is the accrual turnover. Where a deal has separate target and earnings turnover, this calculation change will only apply if the discount percentage applies to the earnings turnover.
The pane will be 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.
A button will be 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, only trigger the process as it currently exists.
Scaling factor constraints
Where a scaling factor is used, a constraint will be applied to ensure that the factor is always greater than or equal to 1. Where the scaling factor would be less than 1, a factor of 1 will be used instead.
Scaling factor for baseline earnings
The calculation of baseline earnings will be 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 will be 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.
Scaling factor for forecast earnings
The calculation of forecast earnings will be 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 will be 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.
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 will be 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 will be 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 will ensure that when the deal period has ended, the forecast results match the actual results. This new trigger will cause recalculation regardless of the current workflow status of the scheme to which the deal belongs.
Unreconciled turnover lines can only be deleted one supplier at a time and requires the client admin user to enter their password once for each supplier. A client admin user will 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.
The Turnover line includes primary key setting can only be enabled by an Enable platform administrator if there are no turnover lines without a primary key. In order to enable this setting, there cannot be any unreconciled turnover lines in the client's instance which do not have a primary key.
A new weekly process will be 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 will recalculate 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 will also recalculate 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 will use 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.
If you have any questions regarding our current or upcoming Enable updates, please contact your Client Services team at firstname.lastname@example.org.