[AccessD] Payroll

[James Button]

Or, as happened to me - 
Had to take a 2 hour break from a shift to report to the police that my car had
been broken into and accompany them to the car, 
(in the works car park during working time - the heated rear window smashed!)
Then, the following day another 90 minutes to have the replacement window put
into the car.

OK - I could have taken the rest of the day off, but that would have seriously
annoyed my employer as it would have meant at least 8 hours delay to the already
late project I was working on!

Yes - that was optional as the employer could have said I could not take time
off from a shift. 
That would mean I missed an entire shift.
- 
But court attendance - not optional! 
Not as a juror, or as a witness

JimB  

  

-----Original Message-----
From: AccessD <accessd-bounces at databaseadvisors.com> On Behalf Of Jim Dettman
Sent: Tuesday, May 1, 2018 8:42 PM
To: 'Access Developers discussion and problem solving'
<accessd at databaseadvisors.com>
Subject: Re: [AccessD] Payroll


 That's why I'd rather go for the detail and summarize<g>

 Plus, you never know when and what else you'll be asked to track.   What if
someone takes a half day off for jury duty?

Jim.

-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
Doug Steele
Sent: Tuesday, May 1, 2018 2:22 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Payroll

One other thing I add from (bitter) experience is that, when you build a
time tracking system base on some kind of period (daily, weekly, monthly,
bi-monthly, bi-weekly), give some though to what you would need to do to
your code if the time period suddenly changes!

Doug

On Mon, Apr 30, 2018 at 6:54 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> At times, there are valid reasons for NOT normalising or for re-thinking
> what you actual mean
> by nromalisation.
>
> This is one of them.
>
> Think in terms of a TYPE or Object called a "PayPeriod"  rather than "Day"
> and D1Hours to
> D14Hours become separate attributes, not separate entities. :)
>
> I've built systems exactly like this in the past and in fact I'm doing
> another one right now.
>
> I doubt that there will ever be a fortnight with more or less days. :)
>
> If they decide to change to a different pay period, (weekly or monthly?)
> how you store daily
> attendance hours will be the least of your worries.
>
>
>
> On 30 Apr 2018 at 11:30, Bob Heygood wrote:
>
> > Rocky & Jim,
> > Yes I knew intuitively that I was breaking some normalization rules.
> > Just started to let the UI interface drive the schema.
> >
> > For data entry the user insists on being able to "tab" through a whole
> > pay period (2 weeks) for each employee and job.
> >
> > So, how do I use a table with only one record per day?
> > UNBOUND, I guess. And then via code stuff into a "proper"
> > table........ I have done so before but a lot work.
> >
> > Really don't need any other fields.
> >
> > Thanks for responding,
> >
> > Bob
> >
> >
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com