Re: HR Package Proposal

[Kevin Handy]

mark wrote:
> 
> Kevin Handy wrote
> 
> > A couple of quick notes:
> >
> > You have an assorted number of dates in the employee definition
> > file, trying to cover several bases. But you probably miss a lot
> > of them that some people will need.  What might be nicer is to
> > have a date history file containing fields like
> >
> > code - What the date represents
> > date - the date the event occurred
> > description - any additional descriptive text needed.
> 
> Sounds a good idea, if it helps standardise date fields; and I'm sure you're
> right about there being plenty more dates to come. Providing histories would
> also be a big advantage.
> My only concern would be if it made user queries more difficult to write:
> could we avoid making people think 'give me everyone with date code nn date
> before 1970', when what they mean is 'give me everyone with date_of_birth
> before 1970'?
> 
> > and if you use the description field, could also cover
> >
> > reason for leaving code
> > medical check completed code
> > police check completed code (you left out a date for this code)
> 
> I'm not clear here - do you mean use the description field for the code? If
> so, are there any problems with field length, codes being char 8, but
> description probably needing longer?

What I meant was, you have a code specifying that a police check was
completed, but you haven't supplied a date when it was done.
A company might want to periodically check up again after
several years.

> > Also you have an emergency contact table, but you should make it
> > somewhat more general, as just a contact table.  Use something like
> >
> > code - Type of contact
> > description - any description needed
> > contact - phone number, email, etc.
> >
> > Don't limit it to phone numbers either. You'll want to be able to track
> > email addresses, and web site address, too. There may also be other
> > references in the future (teleport address?) that need to be recorded.
> 
> Hmm; not being a C Developer, maybe I should steer clear of trying to do the
> Business Object Definitions, as it could be more confusing than helpful.
> What I was trying to describe was that Classes like Next of Kin and
> Emergency Contact would  extend the Base Package 'Person'. Base Package
> 'Person' has all the phone numbers, email addresses etc. needed I think. The
> only thing missing for the Personnel module was the 'relationship code' (for
> husband, sister, etc.).
> The idea of codifying the contact seems sensible, but with the same caveat
> about user's not having to think in terms of codes for occasional
> queries/reports.
> 
> Thanks for the comments.
> 
> Could the GNUe core team indicate how these comments should be incorporated
> into the HR proposal? I'm happy to do it, but it might be better for a
> technical authority to look after the Business Object Definition section.
> Mark H. Smith
> Email: address@hidden