Re: HR Package Proposal

[mark]

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?

> 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