Re: [Tsheetx-developers] [SPAM] Re: Simple time sheet

[Krabina B. <kr...@kd...>]

Dear all,

I think the discussion regarding the relation of simple timesheet and other input methods pretty much relates to my earlyer suggestion: keep the record of work times/absences separate from billing times to projects. Simple timesheet is perfect for doing the latter, so maybe make a simpler version of the weekly and daily input methods just to record precences/absences?

Peter, I'll paste my previous thoughts on this in this e-mail in case you missed my first post.

regards,
Bernhard

> There are two separate goals with time tracking that usually get mixed
> together, which in my opinion is not such a good idea.
> 
> Goal 1 - Track the legally necessary times
> ------------------------------------------
> The requirements are quite basic. You need to record in a timesheet
> the time an employee started to work. Because there are different work
> times, you should be able to track the following:
> - regular work time
> - overtime (maybe overtime 50% and overtime 100%)
> - travel time
> - absences (with reason, e. g. doctor appointment or sickness leave)
> - break (maybe paid and unpaid break)
> - (maybe "block time" - this is a speciality for overtime starting
> after regular work time with more than 3 continuour hours, but this
> could also be left to the HR department ;-)
> 
> In Timesheet NG this could be done be enhancing the idea of the
> absences sheet. It's important to have a report for the employee to
> sign to stat that this were his woking times.
> 
> Goal 2 - Track times associated to projects (or even tasks)
> -----------------------------------------------------------
> What is needed is the number of hours a person records to a certain
> project (per week or month is usually enough). And nice reporting and
> export functions for further controlling purposes.
> 
> The problem now is, that with trying to combine these two goals in one
> solution, you usually have the following effects:
> - tracking becomes inconveniently complex for users, they have to
> track very precicely (9-10, project A, work time, 10-12, project B,
> travel time; 12-14, project B, work time...),
> - tracking solutions tend to become quite complex as well because of
> that
> 
> So my suggestion is to keep these things separated.
> 
> This can cause the problem that the two times recorded might not
> match. There are several possibilities to handle this:
> 1. leave it. If users want to cheat, they will cheat. The
> Presence/Absense sheet is the only legally binding thing. The user has
> to sign it and declare that these have been his/her working times. If
> there are differences on the times recorded for projects and
> presences, they will show up in the controlling.
> 2. make a connection.
> - case a: the user has recorded 40 hours a week and has only assigned
> 30 hours to projects. This case is easy: the tracking tool could
> automatically assign the remaining times to a "project" called
> "administrative tasks" - so everything not billable/productive gets
> added there. (Or the tool does nothing but requiring the user to bill
> exacly 40 hours where the user will manually bill the remaining hours
> to the "project" called "administrative tasks"
> - case b: the user has recorded 40 hours and tries to assign 50 hours
> to projects. Also easy: don't allow it
> 
> For making a connection the use case could be like this:
> - Users track time on a regular basis (dayly is best) to record their
> absence/presence.
> - At the end of a period (usually a week or a month) the user clicks
> on "assign times to projects" or something like this.
> - For the selected period, the number of productive recorded hours (in
> the example 40 for the week) are displayed, the user can assign them
> to predifined projects until he has assigned all hours or there are
> some left that get associated with "adminstrative tasks"
> 
> I know that this approach does not fit to everyone. I can understand
> that one-man-companies want to be able to have everyting recorded in
> big detail, but for companies with employees, time tracking can easily
> be regardes as burdensome and controlling every minute of their
> presence in (and absence from) the company.
> 
> In our company we would vote for a lightwheit solution as I just
> described. And by the way 30 min. intervals are enough, I don't want
> our employees to record "9:12 - 10:22, project A". Assigning times to
> tasks is nice, but in our case not necessary.
> 
> It would be great if Timesheet NG could offer a solution for this
> approach. I think it's actually not very far from it...

----- Ursprüngliche Mail -----
> I agree, Scott that there are problems swapping between the two
> styles. And I can see in the simple form the work that has been done
> to aggregate multiple daily entries into one entry for display and
> editing.
> 
> But precisely because there are issues in running the two styles on
> the one system, I think we need a different approach to make both
> consistent. Or a significant warning of the limitations of the simple
> time entry.
> 
> Yes, in the simple form, the transaction ID field (trans_num in times
> db) can be used to track which time entry is which. I would rather
> throw the problem at the user though. If sometimes the user enters
> times on the weekly sheet and records start and stop time, then, when
> adjusting hours worked on the simple sheet, the user should be
> presented with the individual entries in some format, and he can
> decide which one to edit. On the other hand, some users will complain
> about that difficulty, and added complexity - it's no longer a simple
> form.
> 
> So where my thinking is going at the moment is to leave simple.php as
> it is. I am toying with the idea of the weekly sheet with some
> simplified entry option. It currently displays for each task, the
> multiple time periods that have been worked. Perhaps we could allow
> these entries to be selected and edited. Perhaps a user could elect to
> enter either hours worked, or start and stop times. I need to think
> this one through a lot more though and draw up a mockup on paper.
> 
> Submission and approval. Agree that this function needs to be in
> separate forms. Supervisor review, approve function needs to be in a
> separate form. But should the user submission be in a separate form,
> or another button on an existing form? Users may prefer to submit
> times from the weekly/simple sheets just after they have finished
> editing. But it would be simpler from a development point of view to
> do submission from a separate sheet.
> 
> Re the user configuration table. What things are you thinking of
> putting in there?
> 
> Peter
> 
> On 09/23/2010 12:19 AM, Scott Miller wrote:
> 
> Well, to be honest, the reason I'm currently advocating never to
> switch between them is because of the various problems that can crop
> up when doing this. Start/stop times, if they exist, are wiped out to
> all begin at midnight, and week spanning entries can cause time losses
> or time replications. There may be others, but these issues are
> currently non-trivial to fix, but they are easily avoided if you don't
> switch between the two input methods.
> 
> I've thought about how to tackle these issues: if we keep track of the
> transaction ID's within the simple timesheet, that appears to be a
> workable solution, but then when we throw the aggregation
> possibilities into the mix, things break down. But, iIf we kept a list
> of the transactions for the aggregations, maybe that would work? If an
> aggregate is edited, throw out the individual entries and create a new
> one that starts at midnight. If it's not edited, leave them alone. For
> entries with a single transaction, the length could be edited, leaving
> the start time in tact. This also helps make the week spanning time
> entries problems more easily solvable.
> 
> As far as submission to management and approval go, I would highly
> recommend putting that stuff in separate forms.
> 
> BTW, many things seem to hinge on having some sort of per user
> configuration tables. Timesheet submission and approval seem to need
> these from what I've been able to figure out. I would love to have a
> per user timezone entry, but then we need to fix the timezone
> problems...
> 
> -Scott
> 
> 
> On Wed, Sep 22, 2010 at 6:05 AM, David Thompson <
> tom...@us... > wrote:
> 
> 
> 
> I would disagree with the view that you shouldn't switch between the
> two, why not? Sometimes you just want to say I worked today from 7 to
> 18, and let the TS work out how many hours that was, and other times
> you say OK, yesterday I did about 4 hours.
> 
> If the simple timesheet didn't have all the problems that Peter has
> rightly identified, then it wouldn't be so tricky to swap between the
> two styles of entry. I could imagine merging the simple and weekly
> timesheets and offering the user the choice of style.
> 
> Cheers
> 
> > From: it...@ea...
> > To: pal...@gm... ; tsh...@li...
> > Date: Tue, 21 Sep 2010 19:37:05 -0400
> > Subject: Re: [Tsheetx-developers] Simple time sheet
> 
> 
> >
> > I've got to agree with Scott... If you want to enter start and stop
> > times,
> > use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple
> > timesheet works great for those who only need to enter hours and
> > minutes and
> > the start/stop times don't mean anything to us: just the time in the
> > end
> >
> > -----Original Message-----
> > From: Peter Lazarus [mailto: pal...@gm... ]
> > Sent: Tuesday, September 21, 2010 7:05 PM
> > To: tsh...@li...
> > Subject: [Tsheetx-developers] Simple time sheet
> >
> > I posted this comment on simple timesheet entry on the bug tracking
> > system. Scott Miller has responded and suggested we discuss this
> > issue
> > on the developers forum. Can the wider community add their opinions
> > and
> > suggestions. Scott's response is reproduced further down.
> > Peter
> >
> > I've been using the simple timesheet to add a function for
> > submitting and
> > approving timesheets. The more I work on my new function I discover
> > that
> > simple timesheet has some inconsistencies with the other entry
> > methods. One
> > issue that I don't like is that simple deletes the time records and
> > them
> > puts them back. This means quite a lot of detail can be lost.
> >
> > So can we suggest/design a new time entry format, perhaps similar to
> > simple's approach. Some of the requirements I would like to see are:
> > - enter times for the week against the projects/tasks
> > - time entry must include start and stop times to be consistent with
> > the
> > other input
> > - multiple periods on the one day against one
> > project/task/description
> > similar to what can be entered with daily or weekly
> > - changes to existing times cause db updates rather than
> > deletion/insertion
> > - ability to submit time records for a week for approval (requires a
> > supervisor) although submission could be done in another panel
> >
> > (0000231) Scott Miller (developer) - 2010-09-21 20:05
> > http://bugs.timesheetng.org/view.php?id=109#c231
> > ----------------------------------------------------------------------
> > I agree that deleting records only to recreate them seems to be the
> > wrong
> > thing to do, but keeping track of what items need to change then
> > becomes
> > necessary and that's not a trivial task.
> >
> > I totally disagree with requiring a start and stop time. Simple was
> > designed for those who don't want to have to deal with start/stop
> > times,
> > and just want to be able to record time spent per item.
> >
> > That said, I believe that if start/stop times exist, they should not
> > be
> > deleted; again this is not trivial.
> >
> > For further discussion, please join the developers mailing list, and
> > lets
> > discuss this there. You can find a link in the wiki area to join.
> >
> > One example of why these are not trivial problems is that simple.php
> > currently combines multiple time entries for identical task/log
> > messages.
> > How do you handle an edit of an aggregate amount of time?
> >
> > I personally believe that users should be free to choose which
> > system they
> > want to use, but I highly recommend NEVER switching between time
> > entry
> > systems because they represent entirely different ways of
> > thinking/looking
> > at time tracking.
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers