Have you checked this ?
http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec435572.aspx
====
How should I configure my Time Slices?
Document ID: TEC435572
Last Modified Date: 1/5/2016
Show Technical Document Details
Introduction:
We want to know if there are any 'Best Practices' in configuring our Time Slices within the CA PPM application.
Instructions:
Based on the amount of data and the reporting needs of your individual implementation, you may need a consultation to determine the amount and type of timeslices that are needed to fulfill your requirements. If you need past historical data to be sliced for dates further back than is recommended in this article, it is recommended to consult our CA Services team for advice on alternative configurations for your reporting needs. If you need to look further back we suggest using monthly data in a production environment ; this will create fewer records for reporting historical data within the recommended configurations. Slicing data further back in time for daily slices which create many records, is not recommended in a production environment. Remember that when making the configuration changes to the Slice definition 'From Date' and 'Number of Periods' it will impact the performance of the Time Slicing job and the amount of records created in the database.
Estimates:
There is no need to slice estimates in the past. We recommend that you set the "From Date" to the start of the current month. Most customers maintain daily slice data for ETC one year in the future. If you need to look further out we suggest using monthly data. For daily estimates, in addition to setting the From Date to the start of the current month the Number of Periods should be set to a number close to 365 such as 370-400 to add a small buffer of data.
Actuals:
If you require daily actual data for a year in the past, we recommend that you set your From Date for the Actuals slice request to the start of the current month 1 year in the past. For example, if today is June 15, 2015 set the from date to June 01, 2014. Also set the Number of Periods to 400. This will store a year in the past as well as a some days in the future in case anybody creates and submits a timesheet early.
Baseline and Availability:
The logical configuration for both Baseline and Availability slice data should start at the beginning of the period defined for 'Actuals' Time Slice definitions through the period defined for 'Estimates' Time Slice definitions. Set the 'Baseline' and 'Availability' From Date to same From date as 'Actuals' slice request and change the number of periods to 730. When a Resource has a Hire Date and / or Termination Date, the Availability Slices are bound for the Resource within these date ranges.
Daily Datamart Slices:
The following 5 Daily Time Slice Definitions must be set to start at a minimum to start at least 3 months prior to the current month and to start on the first day of the month. This configuration is required for populating Datamart tables without any gaps in the prior 3 months from current month.
EXAMPLE: If the current date is in January 2015, then set the following Time Slice Definitions to start on October 01, 2014 or before.
Slice ID = 1, 2, 3, 10, 11
1 DAILYRESOURCEAVAILCURVE (Availability)
2 DAILYRESOURCEACTCURVE (Actuals)
3 DAILYRESOURCEESTCURVE (Estimates)
10 DAILYRESOURCEALLOCCURVE (Allocation)
11 DAILYRESOURCEBASECURVE (Baseline)
Allocations:
If you are not maintaining allocation at the Project level company wide, you may have no need to maintain slice data for allocation. This is by far the largest portion of slice data, and if it is not entirely valid it can be dramatically reduced. We recommend that if you do not set project level allocation you should set the Number of Periods to four (4) for Allocation slice request. This will minimize the amount of data that is being stored for Allocation slices and also populate in the Datamart tables.
If you are truly using this allocation data it should also be in the same range as Baseline and Availability Time Slice definitions. We recommend that you enforce setting project allocations company wide and be sure to properly zero out any remaining/unused allocations. If allocations are set properly on active projects only valid data will be stored in timeslice therefore dramatically reducing the amount of records needed to maintain allocations.
We also recommend that you zero out "Remaining Allocation", as seen on the Project Roster/Team page, for inactive/closed projects. To zero out the resources "Remaining Allocation", we recommend that you set the allocation finish date to the last date the resource worked on the project. "Remaining Allocation" takes into account the last date the actuals were tracked by the resource. This date should be set as the allocation finish date if the resource is no longer working on the project. Zeroing out any unnecessary Remaining Allocation will reduce the amount of data stored in timeslice, and make your data more realistic. The easiest way, although less accurate way to release unused resource allocation, is to ensure ETC is zero and then click "Allocate From Estimates" button on the Roster/Team page. This method of using the "Allocate from Estimates" button for resource with zero ETC is provided as a quick and easy method to zero out allocation. If this doesn't meet your specific needs, use the recommended method, stated above, because it more closely reflects reality.
Monitoring Progress of Time Slicing Job:
You can count the records in prj_blb_slices to check the progress on the Time Slicing rebuild. The Last Run date will begin to populate when the slices are completed.
You can also use the query below to check the status. You'll see the status go from 1 (needs to be sliced), then to 2 (processing), then to NULL (completed). It will go table by table and process 1000 rows at a time.
SELECT 'Assignment' Slice_Object, Count(*), SLICE_STATUS
FROM prassignment
WHERE SLICE_STATUS in (1,2)
GROUP BY SLICE_STATUS
UNION SELECT 'Allocation' Slice_Object, Count(*),SLICE_STATUS
FROM prteam WHERE SLICE_STATUS in (1,2)
GROUP BY SLICE_STATUS
UNION SELECT 'Availability' Slice_Object, Count(*),SLICE_STATUS
FROM prj_resources
WHERE SLICE_STATUS in (1,2)
GROUP BY SLICE_STATUS
Additional Information:
Reference TEC435563 : Time Slicing Terminology Explanation
Reference TEC618280 : Best Practices: Configuring and reviewing user-defined Time Slice requests to avoid duplicate definitions
====
NJ