Clarity

I think I have a time-slicing issue but wanted to see if anyone's experienced the same issue before I raise a case with Support. V12.06 and SQL server with OWB.

In the Project Assignments portlet for a specific resource on a specific project it is showing 6.2 hours of ETC in June and a total of 323 hours (in the timescaled section)for the project. The non-time scaled total for ETC is 264.5 hours.

In Open Workbench for that same resource, there is no ETC in June and the total ETC for the whole project is 264.5 hours.

Looking at slice data I can see that the difference is down to 1 specific task, which has no ETC on it in OWB (but has actuals). I have looked at both PRJ_BLB_SLICES (daliy resource ETC slice) and the insta-slice PRJ_BLB_SLICES_M_ETC which is used by Project Assignments, and they each return a total of 323 for the project.

The 6.2 hours in June is causing us to flag data issues when they don't in fact exist according to OWB.

I can also see that the totals by month are different between OWB and Project Assignments.

Any suggestions? Should I rebuild the whole daily resource ETC slice? Is there an underlying bug with time slicing?

Any help appreciated as always!

Looks like a slice problem to me - if you are seeing different data in the database slice to what you see in OWB then that is a pretty sure indication.

I definably used to get slicing issues with timeentry records in the 7.5.x versions - I used to run a SQL statement that compared the totals on the timeentry with the total on the slice, and where it was wrong in the slice I would just flag* the timeentry for re-slicing. Pretty sure the problem went away as I have not encountered it recently. I also recall mismatches in ETC slicing when we were building some portlets that summed up the slice data ; again the problem went away (think we were only getting the issue in DEV environments when we were deliberately slicing stuff all the time - there used to be an issue when a normal slice was happening and another slice was rebuilding totally ; things went wrong).

(* - There is/was an KB article about flagging things for re-slicing so I took that as a legitimate thing to do. I had a scheduled job that used to look for "errors" and then force a re-slice on the affected records (not the whole slice))

--

Incidentally, what is your resource's "actuals through" date (which should be the latest timeperiod for which they completed a timesheet) - there should be zero ETC prior to that date on any assignment for the resource (thats kinda what "actuals through" is doing in the system).

Thanks Dave for confirming my suspicions. Our users have been deleting, saving then reapplying ETC to assignments, which obviously does trigger the reslice, but we have a feeling this is more than just an isolated case. I'm just starting to build that comparison query to see the scale of it, and I will try to find that KB article you mentioned.

Actuals thru date is 14 July for this resource on this project. No ETC before that, some between that and the start of this week, then the rest. Looking at timesheets I can see she hasn't put one in for w/c 15 and 22 July which would explain why there is some ETC in the past but after 14 July. I wonder if there is some link there to the issue with slicing?

Owen,

You can do a soft reset of the internal ETC slices with the following steps:

1. Pause the scheduled Time Slicing job
 
2. Run the following update statement:

 

UPDATE PRJ_BLB_SLICEREQUESTS

SET EXPIRATION_DATE=NULL,

REQUEST_COMPLETED_DATE=NULL

WHERE ID in (103, 108, 113) --daily, weekly, monthly internal  estimates slice

 
3. Manually run the time Slicing job
 
4. Un-pause the scheduled time slicing job

Once the time slicing job has completed again, check your values in Clarity. If you are still having an issue, please open a ticket with Support.

Regards,
Jenn

- Adfyd a ddwg wybodaeth, a gwybodaeth ddoethineb

Jenn Rinella
Principal Support Engineer
Member, Council for Technical Excellence

CA Technologies | 5465 Legacy Drive Suite 700 | Plano, TX 75024-3106
Office: +1 888-550-6458 | Jenn.Rinella@ca.com

Thanks for that Jenn (or should I say "diolch yn fawr", given the Welsh proverb in your sig...:grin:)

You are most welcome Owen.

As for the proverb - Adversity brings knowledge, knowledge wisdom...

I am apparently collecting them. It started with a Hungarian phrase last year from a book I was reading. This year, one of our Welsh customers sent me this one after a particularly interesting case and I've been using it ever since.

Please let me know if the soft reset helps and have a lovely weekend.

Regards,
Jenn

- Adfyd a ddwg wybodaeth, a gwybodaeth ddoethineb

Jenn Rinella
Principal Support Engineer
Member, Council for Technical Excellence

CA Technologies | 5465 Legacy Drive Suite 700 | Plano, TX 75024-3106
Office: +1 888-550-6458 | Jenn.Rinella@ca.com

Jenn
The soft reset did the trick - I've got consistent results between OWB and Project Assignments now for all the discrepancies I'd identified last week.

Thanks for your help.

Owen

Owen,

That is wonderful news.

The soft reset is nice because it doesn't really force a full reset (like setting slice_status= 1 for an entire table) and usually picks up anything that may have been missed somehow.

It can be used with any of the slices. For obvious reasons, if you think you need to reset more than one slice, only do a few at a time so the job has time to catch up without impacting performance, other job runs, or reporting.

Have a lovely week.

Jenn

- Adfyd a ddwg wybodaeth, a gwybodaeth ddoethineb

Jenn Rinella
Principal Support Engineer
Member, Council for Technical Excellence

CA Technologies | 5465 Legacy Drive Suite 700 | Plano, TX 75024-3106
Office: +1 888-550-6458 | Jenn.Rinella@ca.com