I mean, in the end the design is up to you, but for me, I don't see the point of storing the monthly and yearly values when you have the daily. You can use windowing functions to do the sums like I suggested originally and you wouldn't need to persist to disk. Same thing applies to any calculations you need to do. Or, depending on how you create the view/SP, you may not even need windowing functions if you can do it with "group by"'s. Looking at the columns you are trying to use though, I think that windowing functions are going to be your friend here. Alternately, you could use nested selects with self-joins, but that will not be as fast as a windowing function would be.
One big reason I like the above approach is there is no code changes required on the 3rd party app and the database side just needs a new stored procedure or 2 for calculating out the monthly and yearly values. Then if end users need to report on this, they can do it from Excel (use Excel to call the stored procedure and pull the data in) or SSRS or whatever reporting tools you have in your toolkit. No need for a custom app or extra work by the end users. The data exists and you are just doing calculations on it.
And while I agree with Jeff that it would be "blazing fast" to persist to disk, summing up 28-31 days of data for 60 users should already be "blazing fast"... same thing with 365/366 days of data. Especially with only 60 users. SQL can add up 21,900 (60*365) numbers nearly instantly if there is a good index on the data. If you lack good indexes or are not able to make good indexes, then persisting to disk may be required.
Now if persisting to disk is an absolute must, I would still not bother with an app as that is just extra overhead for end users. I would create a job on the SQL server to take the data from the view and do the calculations on it and persist it to disk. For presentation of the data to end users, I'd use a reporting solution (Excel, SSRS, PowerBI, Tableau, etc.) and you are good to go. The ONLY reason I'd use an app is if the end users need to enter some data before it gets pushed back to SQL. Plus if you use the app approach to persist it to disk AND each of the 60 employees needs to click the button, you are going to have a lot of blocking happening on that table. If you use a job to do it, a much smaller chance of blocking.
And what I meant by a YTD view was just to have a view that takes the raw data and sums it up by year.
Like I said, I'd have either 1 stored procedure or 2 views. I personally prefer the stored procedure approach as you could have the parameters set up to give results per employee, per month, or per year based on the parameter provided. 3 INT parameters, all default null. First one being the employee ID, the second being the month (3 for March for example), and the last being the year. Then your query just needs to have a properly formed WHERE clause to get the result for you and that is easy to do with an ISNULL. May not be the most efficient query (functions in WHERE clauses hurt performance), but with only 60 employees I suspect that the performance would be "good enough".
My first step in a situation like this would be to take a sample of the data, remove any PII, and put it into a test system and put it into Excel. In Excel, I would create the monthly and yearly totals so I can see what values I should be expecting. Then I'd move over to my test SQL instance and see if I can reproduce those numbers. The 4 row sample you provided isn't really enough to go in in my opinion. I would want at a minimum 2 employees and time range spanning over 2 months. Now this COULD be done with 4 rows, but I'd want something a bit more interesting when I was building my sample set and would likely want at least 100 rows. Excel can calculate it pretty easily with a SUMIFS() function and SQL can handle it with a SUM and GROUP BY or with a SUM OVER(PARTITION BY) approach.
In the end, the approach you use is up to you, but if I was doing it I only persist to disk things that are hard to calculate or are slow to calculate OR I need point in time data. By hard to calculate, I mean if I need to use a CTE or nested selects or a lot of joins or are data points that have no method to calculate them such as I cannot calculate a persons name. By slow to calculate I mean if I am doing a sum of a column in a table with a few hundred TB of data stored on a HDD, that will not be quick. By needing point in time data I mean in your scenario if you looked at the data on September 15th if you NEED September to be 0 hours and August to be the value it was on September 1st. You indicate that values can be changed going back 2 months historically so if I need the data from a specific point in time (September 1st), then I'd need to persist to disk. If point in time is not required, one big advantage to the stored procedure/view approach is that you get real-time data. You look on September 15th for the number of hours that employee 1 worked in September, it will show you that data and it will be accurate up to the second that you ran the report.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.