What is the impact of modifying the Time Slice properties for Project Planned Cost?
As an example, data starts from Sept 2015. But in the Project, the Allocation was present from Apr 2015 to Aug 2015. Hence, the cost for this period could not be calculated when custom job was run.
The current monthly allocation Time Slice configuration is three years in the past and five years in the future.
Specifically, data for 33 months in the past and 65 months in future.
The proposed configuration would be for 60 months in the past and 36 months in future.
This would make sure we can populate planned costs for all old allocations in the respective projects.
Time Slices are not flagged to be included in the Data Warehouse tables.
What impact could this change have on the system?
1) The major consideration when altering Time Slice periods is performance.
As such, you should benchmark operations involving the Time Slices before a change, and then compare after.
This is because Time Slices involve the largest tables, and are a potential performance risk if increased too far in scope.
In the example given, testing would be needed to see if there is a performance impact, as even though the period length is the same, the amount of data included in one range could be a lot different.
2) The second concern is that all Time Slices are moved in unison.
That is you, don't move the Start Date of some Time Slices but not others.
This is because in Jaspersoft Reports there is an expectation that the data will match. That the Actuals and Allocations cover the same period range, for example.
In the example given, as Time Slices are not flagged to be included in the Data Warehouse tables, the second concern is not relevant here.
It is still recommended to align all periods though, so that Data Warehouse and Jaspersoft Report functionality can be enabled in the future if needed without issue.
It should be possible to make the change in the example without incident, however, each site must carefully test for potential performance impacts on development before repeating this change in production.
There is a great deal of variability between sites, and how their data is stored, which makes performance testing a requirement for any site considering this change.
For this reason, it is recommended that consideration be given to the setting of these periods at the initial installation time, so that an appropriate future-proof range may be selected.