Re: Comments on the HR Draft

[Derek A. Neighbors]

> I'm not quite clear here, but in principle I agree it would be good to make
> the re-hire process as streamlined as possible, avoiding rekeying of data
> wherever possible.
Im not entirely clear either, so I guess this is a call for how best to 
handle a rehire. :)

> I'm thinking the 'Posts' module should be re-titled 'Organizational Planning
> ' (Alan Clifford suggested this, which I feel is clearer). Post equals
> jobcode/title, so if 'Job' is more widely understood than 'Post', lets go
> with 'Job'. I'll revise the proposal to reflect this. Yes I agree there is a
Well Im just a dumb l'american, so Im not saying its right or wrong, 
job/post no major difference to me, just wanted to make sure what it was. :)

> lot more to Job than what is in the draft Personnel module so far, and yes I
> would expect job data to be held in a Job Class to be described in the
> 'Organizational Planning' module. Job data (Job Title, Job Hours, Job
> Minimum Qualifications, etc) can exist independently of the employee, as
> when a job is vacant. But I've come across some employers (small ones
I definitely think they should be independent and if we dont have listed 
we will want to do position control, whether part of an existing module 
or a module of its own.

> typically) for whom setting up an organizational structure with departments
> and jobs is overkill. They would prefer just to give a person/contract a job
> title, and leave it at that. So in the draft proposal I was trying to cater
> for both the small and simple employer, and the big and complex employer.
> The downside to my suggested approach is that the same data (e.g. job title)
> could be held in two different Classes, the Contract and the Job. Perhaps
> there's a better way to provide flexibility/ease of use?
I think the right way to do it woudl be to have the person and the job 
be separate, but in the template for a smaller company we make the 
information for postion/employee all be on one screen so they dont 
'think' they are putting in different classes.  This way if they grow 
and decide to change their mind they arent redoing data structures, but 
rather just using different forms.  I hope that makes sense.

> My understanding is that Payroll will definitely want pay info from the last
> job, especially total tax paid this tax year. But Payroll normally don't
Im not sure why payroll needs to know anything about prior employment? 
At least in the states this is not a requirement.

> need pay info from jobs before the last employer. For HR, details from
> previous employers might be very useful, so I would agree it should be
> catered for. I'm assuming this former employer data would be keyed in  as
> part of the recruitment process, but might be wanted by HR after recruitment
Right that was where I was going with it.

> is complete. The HR package is going to have a lot of Classes that are used
> by different modules (e.g. 'person' will be used by all of them, and each
> will extend it with new data items). I suppose the best way to get a clear
> overview is to draft out the key Classes in the whole package at once,
> rather than try a module by module approach. So I'll attempt that, in a high
> level, requirements only format, which the Business Object Definitions can
> then be developed from.
I think the current approach is ok.  We have 'base' classes that are 
really used if you have things that are spanning across multiple 
packages like person class.

I do wonder if we might need package bases as well....  So you might have

Package                  Module
GNUe                     Base
GNUe Human Resources     Base
GNUe Human Resources     Payroll
GNUe Human Resources     Organization Management
etc.
etc.
etc.

Just thinking outloud.

Derek