When creating Ad hoc views, selecting the project domain, add project name, id and then summary totals (measurements)
In the view, filter on a project where actuals exist in the past, as in beyond your actuals time slices start date for dwh assignment actuals.
When I do this, the actuals only show from the time in which the time slice from data exists. Example, ours starts 7/1/2015, but this is a multi year project, so actuals started back in 2013 (this is very common in services related project). The total actuals to date (wip) are say 27,500. However, in the ad hoc view, using project summary totals >project>total hours. total actual hours (or even total labor hours, since all of ours are labor), we only get 460, which is the total hours from July 1, 2015, which matches our slice table If I choose a current project, where actuals did not start until AFTER 7/1/15, then the total actual hours are correct.
It looks like it is hitting the 1000013 slice table. CA had us change our to Quarterly (used to be monthly) and as we know, your DWH and regular slices must have the same from date and # periods when associated to the same slice such as daily, weekly, etc). This from date, # periods matched our monthly actuals slice table too #4)
I logged a support ticket, and they told me to log an idea to change this, yet they agree the totals should not be dependent on slice tables. I am still waiting to hear confirmation that this actually was designed this way?? So, in order for us to get project actuals (totals), we have to create ANOTHER custom field? That does not sound reasonable at all, so I did respond that I would reach out to the community to see if there was some misunderstanding.
We are 15.1. patch 3 (test environment). I can understand the calendar periods, where data is divided by months, etc to depend on the slices, but the project summary values then are useless, if they are designed the same way (slice dependent). Can anyone clarify this? I have attached the upper portion of the Summary totals measures in Ad hoc. The summary total actual hours read from the DWH_INV_SUMMARY_FACTS.ACTUAL_TOTAL_HOURS which is different from the calendar periods. I don't recall this doing this when we first dabbled in ad hoc at 14.4.
Any ideas or input are appreciated.
Thank you for working with us on the Support case! Yes, this is how the Data Warehouse was designed, we discussed your concerns with Sustaining and currently are working on a user story for you.
Before getting to DWH_INV_SUMMARY_FACTS, the data will be taken from the period's view DWH_INV_ASSIGN_PER_FACTS_V. The period data is taken from the slices. The reason this view was used was mostly for consistency (to ensure summary data matches the period data).
Now we realize your use case is valid and this is why we are going to add this user story to our backlog and ensure you have a better solution than creating a custom field. For now whilst this is not yet done you have the following two options:
Please also raise the idea here as this would help Product Management also prioritize the request.
Thank you -Nika
Support has stated it is reading off the slice tables. That makes no sense at all. Has no one really discovered this yet? Those summary totals are useless, in my opinion, with this logic. By terms of a defect, this should be a defect against the design and sadly it is things like this where CA can fall short against its competitors - goes back to not fully understanding your customers . Nika_Hadzhikidi can you explain this design logic for summary data? And, can you help us how we are supposed to get project total actuals without creating more custom fields? Certainly, CA thought of its long term customers when designing this DWH and realizes that project total actuals are a standard measurement, so I would hope we and support are just missing something.
we created a custom field. We started with the application in 2002 and there is no way we can possibly know how far back customers may need to go, nor should we limit them; however, since ca has stated that DWH slices MUST match the like standard slices (from date and # periods), then setting are slices back further is not an option. The performance is already horrible with slices, and this would cause more issues.
Logged the idea as a design defect- it is not an enhancement. This is a design miss.