none
PS 2010: Jumping Timesheet Numbers RRS feed

  • Question

  • OK, here's a very strange one.  We've just started using Timesheets this month for our internal chargebacks, and this bug is aging me very quickly.

    Scenario:

    • This happens on a Manually Scheduled task that spans the fiscal year and captures certain utility time.
    • All members of a certain department are assigned to the task.
    • A minority of the assigned users see one of the following behaviors:
        >  Enter 8 hours for the task on Monday, click Save and see the number change to 2.67, but see the Work to Date column correctly accumulate 8 hours;
        > As above, but see the 2 and 2/3 value appear on Monday, Tuesday and Wednesday (which adds up to 8);
        > Enter 4 hours for the task on Wednesday, click Save, and the 4 moves to a different day.

    The Project consists of three such Tasks, all identically configured, and (as far as we know) this only is happening on one of the Tasks.

    The inconsistency among users is what worries me.  I don't know when/if it will pop up in other contexts.

    At this point I don't expect a fix, but I'd sure like to know if anyone else is seeing anything like this.

    - Tom

    Tuesday, September 13, 2011 9:39 PM

Answers

  • Hi TASB Tom - you must be running SP1 to be able to enter time against manually scheduled tasks - but have you also loaded a Cumulative Update?  Do you have any calendars associated with the project, tasks or resources that may affect their working time?  If you really need to have your timesheets as a static record of the time entered and want to use Single Entry Mode then you will need to ensure that no data is entered against the plan from any other source.  Or consider turning off Single Entry Mode.

    Best regards,

    Brian.


    Blog | Facebook | Twitter | Posting is provided "AS IS" with no warranties, and confers no rights.
    Project Server TechCenter | Project Developer Center | Project Server Help | Project Product Page


    Brian,

    We finally got our server administrators to load the August CU, and that cleared up LOTS of issues.

    However, I kept seeing occasions when recalling an Approved Timesheet resulted in the numbers shifting around.  I finally tracked this down to "bad behavior" on Project Managers' parts. 

    Specifically:

    The first time that hours are logged to a Task, Project Professional sets the Task's Actual Start to that date, and forces Start to match.

    If the Project Manager moves the Task's Start date earlier, Project Professional tries to make its Actual Work entries reflect this.  It may also distribute the work over several days. (We're instituting weekly work sessions with the Project Managers for the rest of the calendar year for additional training and Project Plan show & tells.)

    From a Timesheet point of view, you may see Friday's hours jump back to Tuesday, or even the prior week, when the Timesheet is recalled. 

    One other problem cause was a (one-time so far) failure of a batch of queued Task update Approvals.

    Hopefully these issues will abate, but just to be safe, I've created the following query against the ...Reporting database to return any discrepancies between Approved Timesheets and Project Plan Actual Work.

    SELECT TL.[PeriodName]
          ,TL.[ResourceName]
          ,TL.[ProjectName]
          ,TL.[TaskName]
          ,CONVERT(VARCHAR(18),TA.TimeByDay, 101) AS [Date]
          ,SUM(TA.[ActualWorkBillable]) AS [Timesheet Hours]  -- Sums all adjustments
          ,EAD.AssignmentActualWork AS [Plan Hours]
          
          
      FROM MSP_TimesheetActual TA
      
     INNER JOIN MSP_TimesheetLine_UserViewCF TL
        ON TL.TimesheetLineUID = TA.TimesheetLineUID
       AND TL.PeriodStatusID = 0   -- Opened Timesheet Periods only
    
     INNER JOIN dbo.MSP_EpmAssignment_UserView EA
        ON TL.ResourceUID = EA.ResourceUID
    
     INNER JOIN dbo.MSP_EpmAssignmentByDay_UserView EAD
        ON EA.AssignmentUID = EAD.AssignmentUID
       AND TL.ProjectUID = EAD.ProjectUID
       AND TL.TaskUID = EAD.TaskUID
       AND TA.TimeByDay = EAD.TimeByDay
    
     WHERE TL.[TimesheetLineStatusID] = 1  -- Approved
        
     GROUP BY TL.[PeriodName]  -- Grouped to allow summing of Timesheet Adjustments 
          ,TL.[ResourceName]
          ,TL.[ProjectName]
          ,TL.[TaskName]
          ,TA.TimeByDay
          ,EAD.AssignmentActualWork
    HAVING SUM(TA.ActualWorkBillable) <> EAD.AssignmentActualWork
    

     

    • Marked as answer by TASB Tom Thursday, October 6, 2011 2:28 PM
    Thursday, October 6, 2011 2:28 PM

All replies

  • Here's a follow-up, following two lines of investigation.

    TIMESHEET RECALL ISSUE

    I had an issue with one line in an Approved timesheet not linking to the Reporting database's Task view in a reporting query. 

    In such cases, the solution has been to use the Recall/Delete/Create/Save/Send Timesheet sequence.

    Fortunately, our fiscal year started on 9/1, so our first timesheet was only for Thursday and Friday.

    Just to make sure I didn't lose anything, I screen-snapped the approved timesheet just before Recalling, and then screen-snapped the recalled timesheet.

    They didn't match.

    A task line that was missing on the Approved timesheet suddenly appeared, with .25h showing for Thursday (it should have been on Friday).

    Two other tasks had their time shifted to Thursday.

    Here's what I know at this point:

    • This has still only been detected on Manually Scheduled tasks;
    • It is not easily replicated, and varies by user (or timesheet creation method?)
    • On the above timesheet, where a Manually Scheduled task had time for both days or only the first day, no date shifting occurred;

    SPLITTING OF NUMBER ENTERED ISSUE

    In the previous post I described how, after posting 8 hours for a timesheet task on a single day, clicking Save caused the 8 hours to be split into three equal parts and spread across three days.

    I examined the Task Usage view of the related project, and found that in one case, the 8/3 hours were spread across the Monday where the original 8 hours had been posted, and on the preceding Thursday and Friday, which would be in a different Timesheet Period.

    Since we need these numbers for timesheet period chagebacks, this is very disturbing.

    IS ANYONE ELSE USING SINGLE-ENTRY-MODE TIMESHEETS AND OCCASIONAL MANUALLY SCHEDULED TASKS?

    Thursday, September 15, 2011 1:40 PM
  • Hi TASB Tom - you must be running SP1 to be able to enter time against manually scheduled tasks - but have you also loaded a Cumulative Update?  Do you have any calendars associated with the project, tasks or resources that may affect their working time?  If you really need to have your timesheets as a static record of the time entered and want to use Single Entry Mode then you will need to ensure that no data is entered against the plan from any other source.  Or consider turning off Single Entry Mode.

    Best regards,

    Brian.


    Blog | Facebook | Twitter | Posting is provided "AS IS" with no warranties, and confers no rights.
    Project Server TechCenter | Project Developer Center | Project Server Help | Project Product Page
    Friday, September 16, 2011 5:17 PM
    Owner
  • Hi TASB Tom - you must be running SP1 to be able to enter time against manually scheduled tasks - but have you also loaded a Cumulative Update?  Do you have any calendars associated with the project, tasks or resources that may affect their working time?  If you really need to have your timesheets as a static record of the time entered and want to use Single Entry Mode then you will need to ensure that no data is entered against the plan from any other source.  Or consider turning off Single Entry Mode.

    Best regards,

    Brian.


    Blog | Facebook | Twitter | Posting is provided "AS IS" with no warranties, and confers no rights.
    Project Server TechCenter | Project Developer Center | Project Server Help | Project Product Page


    Brian,

    We finally got our server administrators to load the August CU, and that cleared up LOTS of issues.

    However, I kept seeing occasions when recalling an Approved Timesheet resulted in the numbers shifting around.  I finally tracked this down to "bad behavior" on Project Managers' parts. 

    Specifically:

    The first time that hours are logged to a Task, Project Professional sets the Task's Actual Start to that date, and forces Start to match.

    If the Project Manager moves the Task's Start date earlier, Project Professional tries to make its Actual Work entries reflect this.  It may also distribute the work over several days. (We're instituting weekly work sessions with the Project Managers for the rest of the calendar year for additional training and Project Plan show & tells.)

    From a Timesheet point of view, you may see Friday's hours jump back to Tuesday, or even the prior week, when the Timesheet is recalled. 

    One other problem cause was a (one-time so far) failure of a batch of queued Task update Approvals.

    Hopefully these issues will abate, but just to be safe, I've created the following query against the ...Reporting database to return any discrepancies between Approved Timesheets and Project Plan Actual Work.

    SELECT TL.[PeriodName]
          ,TL.[ResourceName]
          ,TL.[ProjectName]
          ,TL.[TaskName]
          ,CONVERT(VARCHAR(18),TA.TimeByDay, 101) AS [Date]
          ,SUM(TA.[ActualWorkBillable]) AS [Timesheet Hours]  -- Sums all adjustments
          ,EAD.AssignmentActualWork AS [Plan Hours]
          
          
      FROM MSP_TimesheetActual TA
      
     INNER JOIN MSP_TimesheetLine_UserViewCF TL
        ON TL.TimesheetLineUID = TA.TimesheetLineUID
       AND TL.PeriodStatusID = 0   -- Opened Timesheet Periods only
    
     INNER JOIN dbo.MSP_EpmAssignment_UserView EA
        ON TL.ResourceUID = EA.ResourceUID
    
     INNER JOIN dbo.MSP_EpmAssignmentByDay_UserView EAD
        ON EA.AssignmentUID = EAD.AssignmentUID
       AND TL.ProjectUID = EAD.ProjectUID
       AND TL.TaskUID = EAD.TaskUID
       AND TA.TimeByDay = EAD.TimeByDay
    
     WHERE TL.[TimesheetLineStatusID] = 1  -- Approved
        
     GROUP BY TL.[PeriodName]  -- Grouped to allow summing of Timesheet Adjustments 
          ,TL.[ResourceName]
          ,TL.[ProjectName]
          ,TL.[TaskName]
          ,TA.TimeByDay
          ,EAD.AssignmentActualWork
    HAVING SUM(TA.ActualWorkBillable) <> EAD.AssignmentActualWork
    

     

    • Marked as answer by TASB Tom Thursday, October 6, 2011 2:28 PM
    Thursday, October 6, 2011 2:28 PM
  • Hi,

    i have similar problem (http://social.technet.microsoft.com/Forums/en-US/projectserver2010general/thread/9b157e1a-5c9b-4c22-b236-cde1274ea04c)- 

    I have February 2012 CU installed.

    and server settings:

    In Timesheet Settings and Defaults turn on Single Entry mode
    In Task Settings and Display make sure to Check "Only allow task updates via Tasks and Timesheets."


    Does anyone have similar problems with similar configuration?? Can anybody help me?

    Wednesday, May 9, 2012 10:51 AM