Staff hours tracking application - Revision history

Rfs: /* To calculate PTO */

2011-09-06T18:16:53Z

To calculate PTO

Ali: categorized

2010-07-06T23:56:33Z

categorized

Ryan52: /* What's left for staff hours */ move staff hours todos

2009-11-26T21:46:14Z

What's left for staff hours: move staff hours todos

Ryan52: /* What's left for staff hours */ add todo

2009-11-26T07:17:19Z

What's left for staff hours: add todo

Ryan52: move staff hours todos

2009-11-26T07:15:57Z

move staff hours todos

Ryan52: /* Right? */

2009-11-07T20:47:13Z

Right?

Ryan52: /* User interface */

2009-11-07T20:46:30Z

User interface

Ryan52: /* User interface */

2009-11-07T19:54:16Z

User interface

Ryan52: /* User interface */

2009-11-07T19:52:40Z

User interface

Rfs: /* Reports needed */

2009-10-24T23:00:45Z

Reports needed

@@ Line 137: / Line 137: @@
 #* (This is done by adding up all the scheduled hours that occur in a month regardless of holiday status. Some months will have more Tuesdays or fewer Saturdays, for example, and people may be scheduled to work more or less on any standard weekday.)
 # Determine the '''ceiling''' hours for a typical work week for the worker '''(B)'''.
-# Determine any holiday credit (1/5 of B per holiday occurring in that month) '''(C)'''.
+# Determine any holiday credit (1/5 of '''(B)''' per holiday occurring in that month) '''(C)'''.
 # Determine how many hours logged in the whole month '''(D)'''.
 # Add '''(D)''' + '''(C)''' for a total hours credited '''(E)'''.

← Older revision		Revision as of 23:56, 6 July 2010
Line 164:		Line 164:
	* Volunteers also often report the start time and end time, rather than the number of hours worked. This makes the front desk worker calculate the hours using time math in their head.		* Volunteers also often report the start time and end time, rather than the number of hours worked. This makes the front desk worker calculate the hours using time math in their head.
	* Once we are able to analyze paid worker shifts according to program type and production/income stream, we may want to look at volunteer hours in the same way. That is, we may want to port these functions to the volunteer app from the staff app.		* Once we are able to analyze paid worker shifts according to program type and production/income stream, we may want to look at volunteer hours in the same way. That is, we may want to port these functions to the volunteer app from the staff app.
		+
		+	[[Category: HR]]

← Older revision		Revision as of 21:46, 26 November 2009
Line 164:		Line 164:
	* Volunteers also often report the start time and end time, rather than the number of hours worked. This makes the front desk worker calculate the hours using time math in their head.		* Volunteers also often report the start time and end time, rather than the number of hours worked. This makes the front desk worker calculate the hours using time math in their head.
	* Once we are able to analyze paid worker shifts according to program type and production/income stream, we may want to look at volunteer hours in the same way. That is, we may want to port these functions to the volunteer app from the staff app.		* Once we are able to analyze paid worker shifts according to program type and production/income stream, we may want to look at volunteer hours in the same way. That is, we may want to port these functions to the volunteer app from the staff app.
−
−	~~== What's left for staff hours ==~~
−	~~nothing really is left that has to be done before release, afaik...~~
−	* make strings on interface make more sense
−	* should make some metadata (the income_streams, wc_categories, and programs) effective/ineffective ([[FGRT: 15817]])
−	** this should be able to wait, since we aren't using this info in the frontend at all...
−	** '''why do we need to make the jobs <-> (income_streams, wc_categories, and programs) many-to-many? for effective dates or for percentages?'''
−	*** ''we will need effective/ineffective logic on all of these (actually we might or might not use it on income streams). we might want to do the percentages thing, but i have a feeling it would be difficult to maintain and therefore not get used, so I want to put off implementing that until we've got the basic system online and in use. but either way, we need the many-to-many stuff.''
−	* need foreign keys
−	* make an interface for editing a worker's worker_type
−	** you can set it on create, but not on edit
−	** if you edit it manually, run ./script/validate_workers afterwards to check your work
−	* 21:23 < RiFraS> also, we'll need to add UIs for updating changes in workers and the wc_categories, programs, etc. tables
−
−	~~[[Category: FGdb]]~~

@@ Line 176: / Line 176: @@
 ** you can set it on create, but not on edit
 ** if you edit it manually, run ./script/validate_workers afterwards to check your work
+* 21:23 < RiFraS> also, we'll need to add UIs for updating changes in workers and the wc_categories, programs, etc. tables
 [[Category: FGdb]]

← Older revision		Revision as of 07:15, 26 November 2009
Line 165:		Line 165:
	* Once we are able to analyze paid worker shifts according to program type and production/income stream, we may want to look at volunteer hours in the same way. That is, we may want to port these functions to the volunteer app from the staff app.		* Once we are able to analyze paid worker shifts according to program type and production/income stream, we may want to look at volunteer hours in the same way. That is, we may want to port these functions to the volunteer app from the staff app.

		+	== What's left for staff hours ==
		+	nothing really is left that has to be done before release, afaik...
		+	* make strings on interface make more sense
		+	* should make some metadata (the income_streams, wc_categories, and programs) effective/ineffective ([[FGRT: 15817]])
		+	** this should be able to wait, since we aren't using this info in the frontend at all...
		+	** '''why do we need to make the jobs <-> (income_streams, wc_categories, and programs) many-to-many? for effective dates or for percentages?'''
		+	*** ''we will need effective/ineffective logic on all of these (actually we might or might not use it on income streams). we might want to do the percentages thing, but i have a feeling it would be difficult to maintain and therefore not get used, so I want to put off implementing that until we've got the basic system online and in use. but either way, we need the many-to-many stuff.''
		+	* need foreign keys
		+	* make an interface for editing a worker's worker_type
		+	** you can set it on create, but not on edit
		+	** if you edit it manually, run ./script/validate_workers afterwards to check your work


	[[Category: FGdb]]		[[Category: FGdb]]

← Older revision		Revision as of 20:47, 7 November 2009
Line 60:		Line 60:

	holiday credit = ceiling for week / 5		holiday credit = ceiling for week / 5
		+
	so far = everything from the beginning of the period of interest to max(today, the day they're entering for).		so far = everything from the beginning of the period of interest to max(today, the day they're entering for).

← Older revision		Revision as of 20:46, 7 November 2009
Line 58:		Line 58:

	=== Right? ===		=== Right? ===
		+
		+	holiday credit = ceiling for week / 5
		+	so far = everything from the beginning of the period of interest to max(today, the day they're entering for).
		+
		+	* Hours for this day: Z (total of whats entered on screen)
		+	* Hours for this week: Y (Z, the week so far, plus holiday credit)
		+	* Maximum hours for this week: X (ceiling_hours)
		+	* Overtime: W (max(Y - Z, 0))
		+	* Range this far in pay period: (for days that have passed, get the ceiling and floor, add them up)
		+	* Hours this far in pay period plus holiday in total for month:
		+	* PTO: max(min(range) - total, 0)

	=== WRONG ===		=== WRONG ===

← Older revision		Revision as of 19:54, 7 November 2009
Line 51:		Line 51:

	The simplest, most convenient possible user interface needs to be designed. Workers will need to be able to very easily enter there hours as accurately as possible, seeing only the date (default of today), and multiple lines with the jobs and the hours. Useful feedback to give the user in the UI includes:		The simplest, most convenient possible user interface needs to be designed. Workers will need to be able to very easily enter there hours as accurately as possible, seeing only the date (default of today), and multiple lines with the jobs and the hours. Useful feedback to give the user in the UI includes:
		+
		+	=== What they need to know ===
		+
		+	* if they're gonna go over their weekly ceiling.
		+	* if they're gonna go under their pay periodly floor.

	=== Right? ===		=== Right? ===

← Older revision		Revision as of 19:52, 7 November 2009
Line 51:		Line 51:

	The simplest, most convenient possible user interface needs to be designed. Workers will need to be able to very easily enter there hours as accurately as possible, seeing only the date (default of today), and multiple lines with the jobs and the hours. Useful feedback to give the user in the UI includes:		The simplest, most convenient possible user interface needs to be designed. Workers will need to be able to very easily enter there hours as accurately as possible, seeing only the date (default of today), and multiple lines with the jobs and the hours. Useful feedback to give the user in the UI includes:
		+
		+	=== Right? ===
		+
		+	=== WRONG ===

	* How many total hours are currently being displayed for the date they are entering (adding up whatever they type in)		* How many total hours are currently being displayed for the date they are entering (adding up whatever they type in)

@@ Line 58: / Line 58: @@
 == Reports needed ==
 === Payroll report ===
 (Needed to report hours to payroll when getting checks issued. This would typically be run