You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Hans Bakker <ma...@antwebsystems.com> on 2012/07/27 05:42:51 UTC
reduction of entities in HR
we intend to reduce the number of entities in HR:
EmplLeave
EmplLeaveReasonType
EmplLeaveType -> workeffort+related-entities so it also appears on the
calendar
JobInterview
JobInterviewType -> communication event and related entities
any comments or suggestions?
Regards,
Hans
Re: reduction of entities in HR
Posted by BJ Freeman <bj...@free-man.net>.
so you would add the types to respective workflow and communication events?
Hans Bakker sent the following on 7/26/2012 8:42 PM:
> we intend to reduce the number of entities in HR:
>
> EmplLeave
> EmplLeaveReasonType
> EmplLeaveType -> workeffort+related-entities so it also appears on the
> calendar
>
> JobInterview
> JobInterviewType -> communication event and related entities
>
> any comments or suggestions?
>
> Regards,
> Hans
>
>
>
Re: reduction of entities in HR
Posted by Pierre Smits <pi...@gmail.com>.
Hans,
Can you elaborate on why you intend to change this?
2012/7/27 Hans Bakker <ma...@antwebsystems.com>
> we intend to reduce the number of entities in HR:
>
> EmplLeave
> EmplLeaveReasonType
> EmplLeaveType -> workeffort+related-entities so it also appears on the
> calendar
>
> JobInterview
> JobInterviewType -> communication event and related entities
>
> any comments or suggestions?
>
> Regards,
> Hans
>
>
>
Re: reduction of entities in HR
Posted by Jacques Le Roux <ja...@les7arts.com>.
I think we should keep positive here. It seems to me than Hans has some points by trying to reuse and connect as much as possible
things, notably Facility for location (this could still be done from an Interview Entity)
But how to relate the possible many (communication) events related to a sole interview? So IMO the point is more if we consider an
interview as one and only one meeting or all the meetings a person has and which are related to a task (like to join a company).
My 2 cts
Jacques
PS: Hans, Adrian name is not either Hardrian ;o)
From: "Hans Bakker" <ma...@antwebsystems.com>
> Hi Ardrian
>
> Sorry for the late reply, i thought it was good to wait a couple of days....
> please find my answers in-line.
>
> Regards,
> Hans
>
> Hans,
>>
>> I apologize for the terse response and waving you off. I was feeling a bit frustrated by this thread - not because of the
>> conversation contained in it, but because of the history of you asking for advice, and when that advice is given, you argue
>> against it.
> Apology accepted.
>
> Yes sure, advice is welcome but when i do not agree with the advice I can and will argue against it, I do not see anything wrong
> with this? Apparently you do?
>> I wasn't trying to appear superior. My response was based on the simple idea of closing your eyes and picturing the job interview
>> process. If you take the time to do that, it should be obvious that the process may include a number of communication events, but
>> is not itself a communication event. If you can't picture that, then maybe it's best to just leave the model alone.
> Sure, but you as the calendar expert you should have known that we want interview dates to appear on the calendar? This can,
> according to me, best be done by creating a related workeffort event and this information should not be added to the 'interview'
> entity as you suggest. Location? this also can be referenced on the same workeffort by means of the facilityId... So really, i do
> not see the need of an "Interview" entity at all.
>
> So, yes sorry, i still think the communication event is fine because it has the advantage that it can list the interviews together
> with all emails and telephone calls, so to list all communications using the existing functionality.....AND this is following the
> data model book.....
>
>> I'm not a data modelling expert, but I do manage to get models right most of the time. When I get it wrong, I will be the first
>> one to point it out. There are other areas of development that I am not skilled in. In those I cases I simply follow the advice
>> of others and trust they are leading me in the right direction.
>>
>> From my perspective, the developer community is composed of skilled analysts, architects, programmers, etc - but I don't believe
>> any one person is all of those things. If the individuals in the developer community see things that way, then consequently there
>> is an acknowledgement that there are some things we as individuals don't know or understand. Some people believe that kind of
>> acknowledgement is a sign of weakness, but I see it as the beginning of wisdom.
>>
> Sorry but the last two paragraphs are a bit too cloudy for me.....
>
>> -Adrian
>>
>
Re: reduction of entities in HR
Posted by Hans Bakker <ma...@antwebsystems.com>.
On 07/30/2012 06:20 PM, adrian.crum@sandglass-software.com wrote:
> .....
> I was trying to say in a polite way that maybe you should consider the
> possibility that data modelling is not one of your stronger skills,
> and trust the advice of others who are better at it.
>
> -Adrian
>
A well know saying is: be hard on the problem and soft on people....
http://www.shalomnova.org/inovations/2011/07/05/be-soft-on-people-but-hard-on-the-problem/
that is probably you and others in this group are missing.......
Re: reduction of entities in HR
Posted by ad...@sandglass-software.com.
Quoting Hans Bakker <ma...@antwebsystems.com>:
> Hi Ardrian
>
> Sorry for the late reply, i thought it was good to wait a couple of days....
> please find my answers in-line.
>
> Regards,
> Hans
>
> Hans,
>>
>> I apologize for the terse response and waving you off. I was
>> feeling a bit frustrated by this thread - not because of the
>> conversation contained in it, but because of the history of you
>> asking for advice, and when that advice is given, you argue against
>> it.
> Apology accepted.
>
> Yes sure, advice is welcome but when i do not agree with the advice
> I can and will argue against it, I do not see anything wrong with
> this? Apparently you do?
>> I wasn't trying to appear superior. My response was based on the
>> simple idea of closing your eyes and picturing the job interview
>> process. If you take the time to do that, it should be obvious that
>> the process may include a number of communication events, but is
>> not itself a communication event. If you can't picture that, then
>> maybe it's best to just leave the model alone.
> Sure, but you as the calendar expert you should have known that we
> want interview dates to appear on the calendar? This can, according
> to me, best be done by creating a related workeffort event and this
> information should not be added to the 'interview' entity as you
> suggest. Location? this also can be referenced on the same
> workeffort by means of the facilityId... So really, i do not see the
> need of an "Interview" entity at all.
>
> So, yes sorry, i still think the communication event is fine because
> it has the advantage that it can list the interviews together with
> all emails and telephone calls, so to list all communications using
> the existing functionality.....AND this is following the data model
> book.....
>
>> I'm not a data modelling expert, but I do manage to get models
>> right most of the time. When I get it wrong, I will be the first
>> one to point it out. There are other areas of development that I am
>> not skilled in. In those I cases I simply follow the advice of
>> others and trust they are leading me in the right direction.
>>
>> From my perspective, the developer community is composed of skilled
>> analysts, architects, programmers, etc - but I don't believe any
>> one person is all of those things. If the individuals in the
>> developer community see things that way, then consequently there is
>> an acknowledgement that there are some things we as individuals
>> don't know or understand. Some people believe that kind of
>> acknowledgement is a sign of weakness, but I see it as the
>> beginning of wisdom.
>>
> Sorry but the last two paragraphs are a bit too cloudy for me.....
I was trying to say in a polite way that maybe you should consider the
possibility that data modelling is not one of your stronger skills,
and trust the advice of others who are better at it.
-Adrian
Re: reduction of entities in HR
Posted by Hans Bakker <ma...@antwebsystems.com>.
Hi Ardrian
Sorry for the late reply, i thought it was good to wait a couple of days....
please find my answers in-line.
Regards,
Hans
Hans,
>
> I apologize for the terse response and waving you off. I was feeling a
> bit frustrated by this thread - not because of the conversation
> contained in it, but because of the history of you asking for advice,
> and when that advice is given, you argue against it.
Apology accepted.
Yes sure, advice is welcome but when i do not agree with the advice I
can and will argue against it, I do not see anything wrong with this?
Apparently you do?
> I wasn't trying to appear superior. My response was based on the
> simple idea of closing your eyes and picturing the job interview
> process. If you take the time to do that, it should be obvious that
> the process may include a number of communication events, but is not
> itself a communication event. If you can't picture that, then maybe
> it's best to just leave the model alone.
Sure, but you as the calendar expert you should have known that we want
interview dates to appear on the calendar? This can, according to me,
best be done by creating a related workeffort event and this information
should not be added to the 'interview' entity as you suggest. Location?
this also can be referenced on the same workeffort by means of the
facilityId... So really, i do not see the need of an "Interview" entity
at all.
So, yes sorry, i still think the communication event is fine because it
has the advantage that it can list the interviews together with all
emails and telephone calls, so to list all communications using the
existing functionality.....AND this is following the data model book.....
> I'm not a data modelling expert, but I do manage to get models right
> most of the time. When I get it wrong, I will be the first one to
> point it out. There are other areas of development that I am not
> skilled in. In those I cases I simply follow the advice of others and
> trust they are leading me in the right direction.
>
> From my perspective, the developer community is composed of skilled
> analysts, architects, programmers, etc - but I don't believe any one
> person is all of those things. If the individuals in the developer
> community see things that way, then consequently there is an
> acknowledgement that there are some things we as individuals don't
> know or understand. Some people believe that kind of acknowledgement
> is a sign of weakness, but I see it as the beginning of wisdom.
>
Sorry but the last two paragraphs are a bit too cloudy for me.....
> -Adrian
>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 7/27/2012 8:43 AM, Hans Bakker wrote:
> On 07/27/2012 02:33 PM, Adrian Crum wrote:
>> A sales order includes products, but a sales order is not a product.
>> A job interview might include communication events, but a job
>> interview is not a communication event.
>>
>> Using your logic, a sales order should be a communication event -
>> because it records a contact between a buyer and a seller.
>>
>> If you don't understand the data model, then you shouldn't change it.
>>
> thank you Adrian, for the nice and polite conversation, this could be
> the reason we cannot get other committers than just framework
> programmers for whom the communication via this medium could be improved.
Hans,
I apologize for the terse response and waving you off. I was feeling a
bit frustrated by this thread - not because of the conversation
contained in it, but because of the history of you asking for advice,
and when that advice is given, you argue against it.
I wasn't trying to appear superior. My response was based on the simple
idea of closing your eyes and picturing the job interview process. If
you take the time to do that, it should be obvious that the process may
include a number of communication events, but is not itself a
communication event. If you can't picture that, then maybe it's best to
just leave the model alone.
I'm not a data modelling expert, but I do manage to get models right
most of the time. When I get it wrong, I will be the first one to point
it out. There are other areas of development that I am not skilled in.
In those I cases I simply follow the advice of others and trust they are
leading me in the right direction.
From my perspective, the developer community is composed of skilled
analysts, architects, programmers, etc - but I don't believe any one
person is all of those things. If the individuals in the developer
community see things that way, then consequently there is an
acknowledgement that there are some things we as individuals don't know
or understand. Some people believe that kind of acknowledgement is a
sign of weakness, but I see it as the beginning of wisdom.
-Adrian
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
Maybe you should follow the advice of Dirty Harry: "A man's gotta know
his limitations."
A job interview:
1. Has an estimated start time and end time
2. Has an actual start time and end time
3. Can be cancelled, postponed, or rescheduled
4. Includes a number of parties in various roles
5. includes a number of communication events
6. Has a location
7. Has a status (the outcome of the interview)
So, a job interview includes communication events, but it is not a
communication event. If anything, it resembles a Work Effort.
-Adrian
On 7/27/2012 8:43 AM, Hans Bakker wrote:
> On 07/27/2012 02:33 PM, Adrian Crum wrote:
>> A sales order includes products, but a sales order is not a product.
>> A job interview might include communication events, but a job
>> interview is not a communication event.
>>
>> Using your logic, a sales order should be a communication event -
>> because it records a contact between a buyer and a seller.
>>
>> If you don't understand the data model, then you shouldn't change it.
>>
> thank you Adrian, for the nice and polite conversation, this could be
> the reason we cannot get other committers than just framework
> programmers for whom the communication via this medium could be improved.
>
> First you do not not provide any reasoning and now you assume your
> knowledge is far superior....
> if you think that an order and a product is similar to an interview
> and communication event, then i wonder who is understanding the data
> model.....
>
> sorry Adrian, not sound nice.......
>
>> -Adrian
>>
>> On 7/27/2012 8:22 AM, Hans Bakker wrote:
>>> Adrian,
>>>
>>> Since you still do not provide reasoning, let me explain a bit more
>>> to you.
>>>
>>> From the data model resource book volume 1 page 47:
>>> *A communication event records any type of contact between parties
>>> with a relationship for example,phonecalls, meetings, emails and so
>>> on.*
>>>
>>> Why does an interview not fit in this example list?
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On 07/27/2012 02:02 PM, Adrian Crum wrote:
>>>> I don't agree that a job interview is just another communication
>>>> event.
>>>>
>>>> -Adrian
>>>>
>>>> On 7/27/2012 7:59 AM, Hans Bakker wrote:
>>>>> Adrian,
>>>>>
>>>>> Just telling me it should stay, is not enough, you have to provide
>>>>> reasoning for that.
>>>>>
>>>>> my opinion is that a job interview is just a communication event
>>>>> of the new type 'Jobinterview' with the roles already there. A job
>>>>> interview can then already relate to other communication events of
>>>>> type email or others.....
>>>>>
>>>>> Hans
>>>>>
>>>>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>>>>> I agree that employee leave belongs in the Work Effort entities.
>>>>>>
>>>>>> The JobInterview entity should stay, but its model needs to be
>>>>>> fixed. There should be a JobInterviewRole entity that connects
>>>>>> the JobInterview with Party, then the jobIntervieweePartyId and
>>>>>> jobInterviewerPartyId fields can be removed. We can also add a
>>>>>> JobInterviewComm entity that connects JobInterview to
>>>>>> communication events.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>>>>> Replacing them with the indicated entities......
>>>>>>>
>>>>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>>>>> I don't understand the question. Are you proposing removing
>>>>>>>> those entities?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>>>>> we intend to reduce the number of entities in HR:
>>>>>>>>>
>>>>>>>>> EmplLeave
>>>>>>>>> EmplLeaveReasonType
>>>>>>>>> EmplLeaveType -> workeffort+related-entities so it also
>>>>>>>>> appears on the calendar
>>>>>>>>>
>>>>>>>>> JobInterview
>>>>>>>>> JobInterviewType -> communication event and related entities
>>>>>>>>>
>>>>>>>>> any comments or suggestions?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Hans Bakker <ma...@antwebsystems.com>.
On 07/27/2012 02:33 PM, Adrian Crum wrote:
> A sales order includes products, but a sales order is not a product. A
> job interview might include communication events, but a job interview
> is not a communication event.
>
> Using your logic, a sales order should be a communication event -
> because it records a contact between a buyer and a seller.
>
> If you don't understand the data model, then you shouldn't change it.
>
thank you Adrian, for the nice and polite conversation, this could be
the reason we cannot get other committers than just framework
programmers for whom the communication via this medium could be improved.
First you do not not provide any reasoning and now you assume your
knowledge is far superior....
if you think that an order and a product is similar to an interview and
communication event, then i wonder who is understanding the data model.....
sorry Adrian, not sound nice.......
> -Adrian
>
> On 7/27/2012 8:22 AM, Hans Bakker wrote:
>> Adrian,
>>
>> Since you still do not provide reasoning, let me explain a bit more
>> to you.
>>
>> From the data model resource book volume 1 page 47:
>> *A communication event records any type of contact between parties
>> with a relationship for example,phonecalls, meetings, emails and so on.*
>>
>> Why does an interview not fit in this example list?
>>
>> Regards,
>> Hans
>>
>>
>> On 07/27/2012 02:02 PM, Adrian Crum wrote:
>>> I don't agree that a job interview is just another communication event.
>>>
>>> -Adrian
>>>
>>> On 7/27/2012 7:59 AM, Hans Bakker wrote:
>>>> Adrian,
>>>>
>>>> Just telling me it should stay, is not enough, you have to provide
>>>> reasoning for that.
>>>>
>>>> my opinion is that a job interview is just a communication event
>>>> of the new type 'Jobinterview' with the roles already there. A job
>>>> interview can then already relate to other communication events of
>>>> type email or others.....
>>>>
>>>> Hans
>>>>
>>>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>>>> I agree that employee leave belongs in the Work Effort entities.
>>>>>
>>>>> The JobInterview entity should stay, but its model needs to be
>>>>> fixed. There should be a JobInterviewRole entity that connects the
>>>>> JobInterview with Party, then the jobIntervieweePartyId and
>>>>> jobInterviewerPartyId fields can be removed. We can also add a
>>>>> JobInterviewComm entity that connects JobInterview to
>>>>> communication events.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>>>> Replacing them with the indicated entities......
>>>>>>
>>>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>>>> I don't understand the question. Are you proposing removing
>>>>>>> those entities?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>>>> we intend to reduce the number of entities in HR:
>>>>>>>>
>>>>>>>> EmplLeave
>>>>>>>> EmplLeaveReasonType
>>>>>>>> EmplLeaveType -> workeffort+related-entities so it also
>>>>>>>> appears on the calendar
>>>>>>>>
>>>>>>>> JobInterview
>>>>>>>> JobInterviewType -> communication event and related entities
>>>>>>>>
>>>>>>>> any comments or suggestions?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
A sales order includes products, but a sales order is not a product. A
job interview might include communication events, but a job interview is
not a communication event.
Using your logic, a sales order should be a communication event -
because it records a contact between a buyer and a seller.
If you don't understand the data model, then you shouldn't change it.
-Adrian
On 7/27/2012 8:22 AM, Hans Bakker wrote:
> Adrian,
>
> Since you still do not provide reasoning, let me explain a bit more to
> you.
>
> From the data model resource book volume 1 page 47:
> *A communication event records any type of contact between parties
> with a relationship for example,phonecalls, meetings, emails and so on.*
>
> Why does an interview not fit in this example list?
>
> Regards,
> Hans
>
>
> On 07/27/2012 02:02 PM, Adrian Crum wrote:
>> I don't agree that a job interview is just another communication event.
>>
>> -Adrian
>>
>> On 7/27/2012 7:59 AM, Hans Bakker wrote:
>>> Adrian,
>>>
>>> Just telling me it should stay, is not enough, you have to provide
>>> reasoning for that.
>>>
>>> my opinion is that a job interview is just a communication event of
>>> the new type 'Jobinterview' with the roles already there. A job
>>> interview can then already relate to other communication events of
>>> type email or others.....
>>>
>>> Hans
>>>
>>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>>> I agree that employee leave belongs in the Work Effort entities.
>>>>
>>>> The JobInterview entity should stay, but its model needs to be
>>>> fixed. There should be a JobInterviewRole entity that connects the
>>>> JobInterview with Party, then the jobIntervieweePartyId and
>>>> jobInterviewerPartyId fields can be removed. We can also add a
>>>> JobInterviewComm entity that connects JobInterview to
>>>> communication events.
>>>>
>>>> -Adrian
>>>>
>>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>>> Replacing them with the indicated entities......
>>>>>
>>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>>> I don't understand the question. Are you proposing removing those
>>>>>> entities?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>>> we intend to reduce the number of entities in HR:
>>>>>>>
>>>>>>> EmplLeave
>>>>>>> EmplLeaveReasonType
>>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears
>>>>>>> on the calendar
>>>>>>>
>>>>>>> JobInterview
>>>>>>> JobInterviewType -> communication event and related entities
>>>>>>>
>>>>>>> any comments or suggestions?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: reduction of entities in HR
Posted by Hans Bakker <ma...@antwebsystems.com>.
Adrian,
Since you still do not provide reasoning, let me explain a bit more to you.
From the data model resource book volume 1 page 47:
*A communication event records any type of contact between parties with
a relationship for example,phonecalls, meetings, emails and so on.*
Why does an interview not fit in this example list?
Regards,
Hans
On 07/27/2012 02:02 PM, Adrian Crum wrote:
> I don't agree that a job interview is just another communication event.
>
> -Adrian
>
> On 7/27/2012 7:59 AM, Hans Bakker wrote:
>> Adrian,
>>
>> Just telling me it should stay, is not enough, you have to provide
>> reasoning for that.
>>
>> my opinion is that a job interview is just a communication event of
>> the new type 'Jobinterview' with the roles already there. A job
>> interview can then already relate to other communication events of
>> type email or others.....
>>
>> Hans
>>
>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>> I agree that employee leave belongs in the Work Effort entities.
>>>
>>> The JobInterview entity should stay, but its model needs to be
>>> fixed. There should be a JobInterviewRole entity that connects the
>>> JobInterview with Party, then the jobIntervieweePartyId and
>>> jobInterviewerPartyId fields can be removed. We can also add a
>>> JobInterviewComm entity that connects JobInterview to communication
>>> events.
>>>
>>> -Adrian
>>>
>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>> Replacing them with the indicated entities......
>>>>
>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>> I don't understand the question. Are you proposing removing those
>>>>> entities?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>> we intend to reduce the number of entities in HR:
>>>>>>
>>>>>> EmplLeave
>>>>>> EmplLeaveReasonType
>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears
>>>>>> on the calendar
>>>>>>
>>>>>> JobInterview
>>>>>> JobInterviewType -> communication event and related entities
>>>>>>
>>>>>> any comments or suggestions?
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Pierre Smits <pi...@gmail.com>.
I agree with Hans.
2012/7/27 Adrian Crum <ad...@sandglass-software.com>
> I don't agree that a job interview is just another communication event.
>
> -Adrian
>
>
> On 7/27/2012 7:59 AM, Hans Bakker wrote:
>
>> Adrian,
>>
>> Just telling me it should stay, is not enough, you have to provide
>> reasoning for that.
>>
>> my opinion is that a job interview is just a communication event of the
>> new type 'Jobinterview' with the roles already there. A job interview can
>> then already relate to other communication events of type email or
>> others.....
>>
>> Hans
>>
>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>
>>> I agree that employee leave belongs in the Work Effort entities.
>>>
>>> The JobInterview entity should stay, but its model needs to be fixed.
>>> There should be a JobInterviewRole entity that connects the JobInterview
>>> with Party, then the jobIntervieweePartyId and jobInterviewerPartyId fields
>>> can be removed. We can also add a JobInterviewComm entity that connects
>>> JobInterview to communication events.
>>>
>>> -Adrian
>>>
>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>
>>>> Replacing them with the indicated entities......
>>>>
>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>
>>>>> I don't understand the question. Are you proposing removing those
>>>>> entities?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>
>>>>>> we intend to reduce the number of entities in HR:
>>>>>>
>>>>>> EmplLeave
>>>>>> EmplLeaveReasonType
>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>>>> the calendar
>>>>>>
>>>>>> JobInterview
>>>>>> JobInterviewType -> communication event and related entities
>>>>>>
>>>>>> any comments or suggestions?
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
I don't agree that a job interview is just another communication event.
-Adrian
On 7/27/2012 7:59 AM, Hans Bakker wrote:
> Adrian,
>
> Just telling me it should stay, is not enough, you have to provide
> reasoning for that.
>
> my opinion is that a job interview is just a communication event of
> the new type 'Jobinterview' with the roles already there. A job
> interview can then already relate to other communication events of
> type email or others.....
>
> Hans
>
> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>> I agree that employee leave belongs in the Work Effort entities.
>>
>> The JobInterview entity should stay, but its model needs to be fixed.
>> There should be a JobInterviewRole entity that connects the
>> JobInterview with Party, then the jobIntervieweePartyId and
>> jobInterviewerPartyId fields can be removed. We can also add a
>> JobInterviewComm entity that connects JobInterview to communication
>> events.
>>
>> -Adrian
>>
>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>> Replacing them with the indicated entities......
>>>
>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>> I don't understand the question. Are you proposing removing those
>>>> entities?
>>>>
>>>> -Adrian
>>>>
>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>> we intend to reduce the number of entities in HR:
>>>>>
>>>>> EmplLeave
>>>>> EmplLeaveReasonType
>>>>> EmplLeaveType -> workeffort+related-entities so it also appears
>>>>> on the calendar
>>>>>
>>>>> JobInterview
>>>>> JobInterviewType -> communication event and related entities
>>>>>
>>>>> any comments or suggestions?
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Scott Gray <sc...@hotwaxmedia.com>.
(trying to find a neutral point to reply to)
If it were me, I would probably keep JobInterview and make it a specialization of WorkEffort, much like Person and PartyGroup are to Party. While an interview certainly requires communication, I think in terms of the company being modeled it's better suited as a task than an HR employee needs to perform. WorkEffort could hold the generic task data and JobInterview holds the data specific to that type of task. Just my 2 cents.
Regards
Scott
On 27/07/2012, at 9:23 PM, Adrian Crum wrote:
> 8. Could be related to an employment position
> 9. Could be related to a requirement
> 10. Could be related to an advertising campaign (which help wanted ad brings in the most applicants?)
>
> The list could go on...
>
> -Adrian
>
> On 7/27/2012 10:19 AM, Pierre Smits wrote:
>> For sure. These are all valid arguments for doing in-dept analysis on the
>> effectiveness of the interviews (or surveys).
>>
>> Nonetheless, how the interview was/is conducted (by phone, online,
>> face-to-face or otherwise) are of less importance to the why of the
>> interview. Also the same applies to the items 1,2, and 6.
>>
>> More important are elements are, obviously, who is the party that is
>> executing the interview, who is interviews, what is the underpinning
>> subject, what are the questions, the types of the questions, and the
>> response. Also, who may see the survey (is it confidential, etc), who may
>> see the outcome to do statistical analysis, who may access individual
>> responses, etc.,
>>
>> But I am wondering where the intention to change this comes from.
>>
>>
>>
>> 2012/7/27 Jacques Le Roux <ja...@les7arts.com>
>>
>>> Yes but Adrian has some points:
>>>
>>>
>>> A job interview:
>>>> 1. Has an estimated start time and end time
>>>> 2. Has an actual start time and end time
>>>> 3. Can be cancelled, postponed, or rescheduled
>>>> 4. Includes a number of parties in various roles
>>>> 5. includes a number of communication events
>>>> 6. Has a location
>>>> 7. Has a status (the outcome of the interview)
>>>>
>>> 1+2) Time, duration, (both estimated and actual)
>>> 3) status
>>> 6) location,
>>> 7) result
>>>
>>> It's not as simple as a phone call (which could though have also the same
>>> attributes, but will then be a conf call) or mail exchange (etc.)
>>>
>>> Disclaimer: did not had a chance to check the data model nor re-read the
>>> book at this stage
>>>
>>> Jacques
>>>
>>> From: "Pierre Smits" <pi...@gmail.com>
>>>
>>> Adrian, Hans,
>>>> Thinking a bit more about the jobinterview, I would say that it a specific
>>>> type of survey (like a customer satisfaction survey or employee
>>>> satisfaction survey). For that, some functionalities are already available
>>>> in the Content application/solution.
>>>>
>>>> But a jobinterview involves a higher level of privacy and security.
>>>>
>>>> Nonetheless, an interview (or a survey) is exchanging communications
>>>> between multiple parties.
>>>>
>>>> My 2 cents.
>>>>
>>>> 2012/7/27 Hans Bakker <mailinglist@antwebsystems.com**>
>>>>
>>>> Adrian,
>>>>> Just telling me it should stay, is not enough, you have to provide
>>>>> reasoning for that.
>>>>>
>>>>> my opinion is that a job interview is just a communication event of the
>>>>> new type 'Jobinterview' with the roles already there. A job interview can
>>>>> then already relate to other communication events of type email or
>>>>> others.....
>>>>>
>>>>> Hans
>>>>>
>>>>>
>>>>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>>>>
>>>>> I agree that employee leave belongs in the Work Effort entities.
>>>>>> The JobInterview entity should stay, but its model needs to be fixed.
>>>>>> There should be a JobInterviewRole entity that connects the JobInterview
>>>>>> with Party, then the jobIntervieweePartyId and jobInterviewerPartyId
>>>>>> fields
>>>>>> can be removed. We can also add a JobInterviewComm entity that connects
>>>>>> JobInterview to communication events.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>>>>
>>>>>> Replacing them with the indicated entities......
>>>>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>> I don't understand the question. Are you proposing removing those
>>>>>>>> entities?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>>>>
>>>>>>>> we intend to reduce the number of entities in HR:
>>>>>>>>> EmplLeave
>>>>>>>>> EmplLeaveReasonType
>>>>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>>>>>>> the calendar
>>>>>>>>>
>>>>>>>>> JobInterview
>>>>>>>>> JobInterviewType -> communication event and related entities
>>>>>>>>>
>>>>>>>>> any comments or suggestions?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
Re: reduction of entities in HR
Posted by Pierre Smits <pi...@gmail.com>.
I meant the DRMB.
2012/7/27 Pierre Smits <pi...@gmail.com>
> Indeed. When speaking of surveys, interviews, etc in general.
>
> Maybe the entire (global?) solution should be revisited and reviewed.
>
> Hmm. I find the fla DMRS ambiguous.
>
Re: reduction of entities in HR
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Adrian :)
Jacques
From: "Adrian Crum" <ad...@sandglass-software.com>
> DMRB = Data Model Resource Book.
>
> -Adrian
>
> On 7/27/2012 10:27 AM, Pierre Smits wrote:
>> Indeed. When speaking of surveys, interviews, etc in general.
>>
>> Maybe the entire (global?) solution should be revisited and reviewed.
>>
>> Hmm. I find the fla DMRS ambiguous.
>>
>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
DMRB = Data Model Resource Book.
-Adrian
On 7/27/2012 10:27 AM, Pierre Smits wrote:
> Indeed. When speaking of surveys, interviews, etc in general.
>
> Maybe the entire (global?) solution should be revisited and reviewed.
>
> Hmm. I find the fla DMRS ambiguous.
>
Re: reduction of entities in HR
Posted by Pierre Smits <pi...@gmail.com>.
Indeed. When speaking of surveys, interviews, etc in general.
Maybe the entire (global?) solution should be revisited and reviewed.
Hmm. I find the fla DMRS ambiguous.
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
8. Could be related to an employment position
9. Could be related to a requirement
10. Could be related to an advertising campaign (which help wanted ad
brings in the most applicants?)
The list could go on...
-Adrian
On 7/27/2012 10:19 AM, Pierre Smits wrote:
> For sure. These are all valid arguments for doing in-dept analysis on the
> effectiveness of the interviews (or surveys).
>
> Nonetheless, how the interview was/is conducted (by phone, online,
> face-to-face or otherwise) are of less importance to the why of the
> interview. Also the same applies to the items 1,2, and 6.
>
> More important are elements are, obviously, who is the party that is
> executing the interview, who is interviews, what is the underpinning
> subject, what are the questions, the types of the questions, and the
> response. Also, who may see the survey (is it confidential, etc), who may
> see the outcome to do statistical analysis, who may access individual
> responses, etc.,
>
> But I am wondering where the intention to change this comes from.
>
>
>
> 2012/7/27 Jacques Le Roux <ja...@les7arts.com>
>
>> Yes but Adrian has some points:
>>
>>
>> A job interview:
>>> 1. Has an estimated start time and end time
>>> 2. Has an actual start time and end time
>>> 3. Can be cancelled, postponed, or rescheduled
>>> 4. Includes a number of parties in various roles
>>> 5. includes a number of communication events
>>> 6. Has a location
>>> 7. Has a status (the outcome of the interview)
>>>
>> 1+2) Time, duration, (both estimated and actual)
>> 3) status
>> 6) location,
>> 7) result
>>
>> It's not as simple as a phone call (which could though have also the same
>> attributes, but will then be a conf call) or mail exchange (etc.)
>>
>> Disclaimer: did not had a chance to check the data model nor re-read the
>> book at this stage
>>
>> Jacques
>>
>> From: "Pierre Smits" <pi...@gmail.com>
>>
>> Adrian, Hans,
>>> Thinking a bit more about the jobinterview, I would say that it a specific
>>> type of survey (like a customer satisfaction survey or employee
>>> satisfaction survey). For that, some functionalities are already available
>>> in the Content application/solution.
>>>
>>> But a jobinterview involves a higher level of privacy and security.
>>>
>>> Nonetheless, an interview (or a survey) is exchanging communications
>>> between multiple parties.
>>>
>>> My 2 cents.
>>>
>>> 2012/7/27 Hans Bakker <mailinglist@antwebsystems.com**>
>>>
>>> Adrian,
>>>> Just telling me it should stay, is not enough, you have to provide
>>>> reasoning for that.
>>>>
>>>> my opinion is that a job interview is just a communication event of the
>>>> new type 'Jobinterview' with the roles already there. A job interview can
>>>> then already relate to other communication events of type email or
>>>> others.....
>>>>
>>>> Hans
>>>>
>>>>
>>>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>>>
>>>> I agree that employee leave belongs in the Work Effort entities.
>>>>> The JobInterview entity should stay, but its model needs to be fixed.
>>>>> There should be a JobInterviewRole entity that connects the JobInterview
>>>>> with Party, then the jobIntervieweePartyId and jobInterviewerPartyId
>>>>> fields
>>>>> can be removed. We can also add a JobInterviewComm entity that connects
>>>>> JobInterview to communication events.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>>>
>>>>> Replacing them with the indicated entities......
>>>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>>>
>>>>>> I don't understand the question. Are you proposing removing those
>>>>>>> entities?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>>>
>>>>>>> we intend to reduce the number of entities in HR:
>>>>>>>> EmplLeave
>>>>>>>> EmplLeaveReasonType
>>>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>>>>>> the calendar
>>>>>>>>
>>>>>>>> JobInterview
>>>>>>>> JobInterviewType -> communication event and related entities
>>>>>>>>
>>>>>>>> any comments or suggestions?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: reduction of entities in HR
Posted by Pierre Smits <pi...@gmail.com>.
For sure. These are all valid arguments for doing in-dept analysis on the
effectiveness of the interviews (or surveys).
Nonetheless, how the interview was/is conducted (by phone, online,
face-to-face or otherwise) are of less importance to the why of the
interview. Also the same applies to the items 1,2, and 6.
More important are elements are, obviously, who is the party that is
executing the interview, who is interviews, what is the underpinning
subject, what are the questions, the types of the questions, and the
response. Also, who may see the survey (is it confidential, etc), who may
see the outcome to do statistical analysis, who may access individual
responses, etc.,
But I am wondering where the intention to change this comes from.
2012/7/27 Jacques Le Roux <ja...@les7arts.com>
> Yes but Adrian has some points:
>
>
> A job interview:
>>
>> 1. Has an estimated start time and end time
>> 2. Has an actual start time and end time
>> 3. Can be cancelled, postponed, or rescheduled
>> 4. Includes a number of parties in various roles
>> 5. includes a number of communication events
>> 6. Has a location
>> 7. Has a status (the outcome of the interview)
>>
>
> 1+2) Time, duration, (both estimated and actual)
> 3) status
> 6) location,
> 7) result
>
> It's not as simple as a phone call (which could though have also the same
> attributes, but will then be a conf call) or mail exchange (etc.)
>
> Disclaimer: did not had a chance to check the data model nor re-read the
> book at this stage
>
> Jacques
>
> From: "Pierre Smits" <pi...@gmail.com>
>
> Adrian, Hans,
>>
>> Thinking a bit more about the jobinterview, I would say that it a specific
>> type of survey (like a customer satisfaction survey or employee
>> satisfaction survey). For that, some functionalities are already available
>> in the Content application/solution.
>>
>> But a jobinterview involves a higher level of privacy and security.
>>
>> Nonetheless, an interview (or a survey) is exchanging communications
>> between multiple parties.
>>
>> My 2 cents.
>>
>> 2012/7/27 Hans Bakker <mailinglist@antwebsystems.com**>
>>
>> Adrian,
>>>
>>> Just telling me it should stay, is not enough, you have to provide
>>> reasoning for that.
>>>
>>> my opinion is that a job interview is just a communication event of the
>>> new type 'Jobinterview' with the roles already there. A job interview can
>>> then already relate to other communication events of type email or
>>> others.....
>>>
>>> Hans
>>>
>>>
>>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>>
>>> I agree that employee leave belongs in the Work Effort entities.
>>>>
>>>> The JobInterview entity should stay, but its model needs to be fixed.
>>>> There should be a JobInterviewRole entity that connects the JobInterview
>>>> with Party, then the jobIntervieweePartyId and jobInterviewerPartyId
>>>> fields
>>>> can be removed. We can also add a JobInterviewComm entity that connects
>>>> JobInterview to communication events.
>>>>
>>>> -Adrian
>>>>
>>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>>
>>>> Replacing them with the indicated entities......
>>>>>
>>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>>
>>>>> I don't understand the question. Are you proposing removing those
>>>>>> entities?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>>
>>>>>> we intend to reduce the number of entities in HR:
>>>>>>>
>>>>>>> EmplLeave
>>>>>>> EmplLeaveReasonType
>>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>>>>> the calendar
>>>>>>>
>>>>>>> JobInterview
>>>>>>> JobInterviewType -> communication event and related entities
>>>>>>>
>>>>>>> any comments or suggestions?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
The job interview model is not in the DMRB - it was something we created
internally. The current model has some flaws that are easily fixed, but
it is fundamentally correct, and it can be expanded to accommodate more
data. For example, there might be information about the interview that a
government agency requires for reporting.
-Adrian
On 7/27/2012 9:52 AM, Jacques Le Roux wrote:
> Yes but Adrian has some points:
>
>> A job interview:
>>
>> 1. Has an estimated start time and end time
>> 2. Has an actual start time and end time
>> 3. Can be cancelled, postponed, or rescheduled
>> 4. Includes a number of parties in various roles
>> 5. includes a number of communication events
>> 6. Has a location
>> 7. Has a status (the outcome of the interview)
>
> 1+2) Time, duration, (both estimated and actual)
> 3) status
> 6) location,
> 7) result
>
> It's not as simple as a phone call (which could though have also the
> same attributes, but will then be a conf call) or mail exchange (etc.)
>
> Disclaimer: did not had a chance to check the data model nor re-read
> the book at this stage
>
> Jacques
>
> From: "Pierre Smits" <pi...@gmail.com>
>> Adrian, Hans,
>>
>> Thinking a bit more about the jobinterview, I would say that it a
>> specific
>> type of survey (like a customer satisfaction survey or employee
>> satisfaction survey). For that, some functionalities are already
>> available
>> in the Content application/solution.
>>
>> But a jobinterview involves a higher level of privacy and security.
>>
>> Nonetheless, an interview (or a survey) is exchanging communications
>> between multiple parties.
>>
>> My 2 cents.
>>
>> 2012/7/27 Hans Bakker <ma...@antwebsystems.com>
>>
>>> Adrian,
>>>
>>> Just telling me it should stay, is not enough, you have to provide
>>> reasoning for that.
>>>
>>> my opinion is that a job interview is just a communication event of
>>> the
>>> new type 'Jobinterview' with the roles already there. A job
>>> interview can
>>> then already relate to other communication events of type email or
>>> others.....
>>>
>>> Hans
>>>
>>>
>>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>>
>>>> I agree that employee leave belongs in the Work Effort entities.
>>>>
>>>> The JobInterview entity should stay, but its model needs to be fixed.
>>>> There should be a JobInterviewRole entity that connects the
>>>> JobInterview
>>>> with Party, then the jobIntervieweePartyId and
>>>> jobInterviewerPartyId fields
>>>> can be removed. We can also add a JobInterviewComm entity that
>>>> connects
>>>> JobInterview to communication events.
>>>>
>>>> -Adrian
>>>>
>>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>>
>>>>> Replacing them with the indicated entities......
>>>>>
>>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>>
>>>>>> I don't understand the question. Are you proposing removing those
>>>>>> entities?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>>
>>>>>>> we intend to reduce the number of entities in HR:
>>>>>>>
>>>>>>> EmplLeave
>>>>>>> EmplLeaveReasonType
>>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>>>>> the calendar
>>>>>>>
>>>>>>> JobInterview
>>>>>>> JobInterviewType -> communication event and related entities
>>>>>>>
>>>>>>> any comments or suggestions?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: reduction of entities in HR
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes but Adrian has some points:
> A job interview:
>
> 1. Has an estimated start time and end time
> 2. Has an actual start time and end time
> 3. Can be cancelled, postponed, or rescheduled
> 4. Includes a number of parties in various roles
> 5. includes a number of communication events
> 6. Has a location
> 7. Has a status (the outcome of the interview)
1+2) Time, duration, (both estimated and actual)
3) status
6) location,
7) result
It's not as simple as a phone call (which could though have also the same attributes, but will then be a conf call) or mail exchange
(etc.)
Disclaimer: did not had a chance to check the data model nor re-read the book at this stage
Jacques
From: "Pierre Smits" <pi...@gmail.com>
> Adrian, Hans,
>
> Thinking a bit more about the jobinterview, I would say that it a specific
> type of survey (like a customer satisfaction survey or employee
> satisfaction survey). For that, some functionalities are already available
> in the Content application/solution.
>
> But a jobinterview involves a higher level of privacy and security.
>
> Nonetheless, an interview (or a survey) is exchanging communications
> between multiple parties.
>
> My 2 cents.
>
> 2012/7/27 Hans Bakker <ma...@antwebsystems.com>
>
>> Adrian,
>>
>> Just telling me it should stay, is not enough, you have to provide
>> reasoning for that.
>>
>> my opinion is that a job interview is just a communication event of the
>> new type 'Jobinterview' with the roles already there. A job interview can
>> then already relate to other communication events of type email or
>> others.....
>>
>> Hans
>>
>>
>> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>>
>>> I agree that employee leave belongs in the Work Effort entities.
>>>
>>> The JobInterview entity should stay, but its model needs to be fixed.
>>> There should be a JobInterviewRole entity that connects the JobInterview
>>> with Party, then the jobIntervieweePartyId and jobInterviewerPartyId fields
>>> can be removed. We can also add a JobInterviewComm entity that connects
>>> JobInterview to communication events.
>>>
>>> -Adrian
>>>
>>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>>
>>>> Replacing them with the indicated entities......
>>>>
>>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>>
>>>>> I don't understand the question. Are you proposing removing those
>>>>> entities?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>>
>>>>>> we intend to reduce the number of entities in HR:
>>>>>>
>>>>>> EmplLeave
>>>>>> EmplLeaveReasonType
>>>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>>>> the calendar
>>>>>>
>>>>>> JobInterview
>>>>>> JobInterviewType -> communication event and related entities
>>>>>>
>>>>>> any comments or suggestions?
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Pierre Smits <pi...@gmail.com>.
Adrian, Hans,
Thinking a bit more about the jobinterview, I would say that it a specific
type of survey (like a customer satisfaction survey or employee
satisfaction survey). For that, some functionalities are already available
in the Content application/solution.
But a jobinterview involves a higher level of privacy and security.
Nonetheless, an interview (or a survey) is exchanging communications
between multiple parties.
My 2 cents.
2012/7/27 Hans Bakker <ma...@antwebsystems.com>
> Adrian,
>
> Just telling me it should stay, is not enough, you have to provide
> reasoning for that.
>
> my opinion is that a job interview is just a communication event of the
> new type 'Jobinterview' with the roles already there. A job interview can
> then already relate to other communication events of type email or
> others.....
>
> Hans
>
>
> On 07/27/2012 01:46 PM, Adrian Crum wrote:
>
>> I agree that employee leave belongs in the Work Effort entities.
>>
>> The JobInterview entity should stay, but its model needs to be fixed.
>> There should be a JobInterviewRole entity that connects the JobInterview
>> with Party, then the jobIntervieweePartyId and jobInterviewerPartyId fields
>> can be removed. We can also add a JobInterviewComm entity that connects
>> JobInterview to communication events.
>>
>> -Adrian
>>
>> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>>
>>> Replacing them with the indicated entities......
>>>
>>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>>
>>>> I don't understand the question. Are you proposing removing those
>>>> entities?
>>>>
>>>> -Adrian
>>>>
>>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>>
>>>>> we intend to reduce the number of entities in HR:
>>>>>
>>>>> EmplLeave
>>>>> EmplLeaveReasonType
>>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>>> the calendar
>>>>>
>>>>> JobInterview
>>>>> JobInterviewType -> communication event and related entities
>>>>>
>>>>> any comments or suggestions?
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Hans Bakker <ma...@antwebsystems.com>.
Adrian,
Just telling me it should stay, is not enough, you have to provide
reasoning for that.
my opinion is that a job interview is just a communication event of the
new type 'Jobinterview' with the roles already there. A job interview
can then already relate to other communication events of type email or
others.....
Hans
On 07/27/2012 01:46 PM, Adrian Crum wrote:
> I agree that employee leave belongs in the Work Effort entities.
>
> The JobInterview entity should stay, but its model needs to be fixed.
> There should be a JobInterviewRole entity that connects the
> JobInterview with Party, then the jobIntervieweePartyId and
> jobInterviewerPartyId fields can be removed. We can also add a
> JobInterviewComm entity that connects JobInterview to communication
> events.
>
> -Adrian
>
> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>> Replacing them with the indicated entities......
>>
>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>> I don't understand the question. Are you proposing removing those
>>> entities?
>>>
>>> -Adrian
>>>
>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>> we intend to reduce the number of entities in HR:
>>>>
>>>> EmplLeave
>>>> EmplLeaveReasonType
>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>> the calendar
>>>>
>>>> JobInterview
>>>> JobInterviewType -> communication event and related entities
>>>>
>>>> any comments or suggestions?
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
>>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
Also, the PerformanceReview model needs to be fixed in the same way as
JobInterview - relate parties to it using an intersection entity.
Taking it even further, JobInterview and PerformanceReview could be
based on a more generic entity - something like PartyInterview, then
each subtype can add its own properties.
-Adrian
On 7/27/2012 7:46 AM, Adrian Crum wrote:
> I agree that employee leave belongs in the Work Effort entities.
>
> The JobInterview entity should stay, but its model needs to be fixed.
> There should be a JobInterviewRole entity that connects the
> JobInterview with Party, then the jobIntervieweePartyId and
> jobInterviewerPartyId fields can be removed. We can also add a
> JobInterviewComm entity that connects JobInterview to communication
> events.
>
> -Adrian
>
> On 7/27/2012 7:17 AM, Hans Bakker wrote:
>> Replacing them with the indicated entities......
>>
>> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>>> I don't understand the question. Are you proposing removing those
>>> entities?
>>>
>>> -Adrian
>>>
>>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>>> we intend to reduce the number of entities in HR:
>>>>
>>>> EmplLeave
>>>> EmplLeaveReasonType
>>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>>> the calendar
>>>>
>>>> JobInterview
>>>> JobInterviewType -> communication event and related entities
>>>>
>>>> any comments or suggestions?
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
>>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
I agree that employee leave belongs in the Work Effort entities.
The JobInterview entity should stay, but its model needs to be fixed.
There should be a JobInterviewRole entity that connects the JobInterview
with Party, then the jobIntervieweePartyId and jobInterviewerPartyId
fields can be removed. We can also add a JobInterviewComm entity that
connects JobInterview to communication events.
-Adrian
On 7/27/2012 7:17 AM, Hans Bakker wrote:
> Replacing them with the indicated entities......
>
> On 07/27/2012 12:27 PM, Adrian Crum wrote:
>> I don't understand the question. Are you proposing removing those
>> entities?
>>
>> -Adrian
>>
>> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>>> we intend to reduce the number of entities in HR:
>>>
>>> EmplLeave
>>> EmplLeaveReasonType
>>> EmplLeaveType -> workeffort+related-entities so it also appears on
>>> the calendar
>>>
>>> JobInterview
>>> JobInterviewType -> communication event and related entities
>>>
>>> any comments or suggestions?
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>>
>>
>
Re: reduction of entities in HR
Posted by Hans Bakker <ma...@antwebsystems.com>.
Replacing them with the indicated entities......
On 07/27/2012 12:27 PM, Adrian Crum wrote:
> I don't understand the question. Are you proposing removing those
> entities?
>
> -Adrian
>
> On 7/27/2012 4:42 AM, Hans Bakker wrote:
>> we intend to reduce the number of entities in HR:
>>
>> EmplLeave
>> EmplLeaveReasonType
>> EmplLeaveType -> workeffort+related-entities so it also appears on
>> the calendar
>>
>> JobInterview
>> JobInterviewType -> communication event and related entities
>>
>> any comments or suggestions?
>>
>> Regards,
>> Hans
>>
>>
>>
>
Re: reduction of entities in HR
Posted by Adrian Crum <ad...@sandglass-software.com>.
I don't understand the question. Are you proposing removing those entities?
-Adrian
On 7/27/2012 4:42 AM, Hans Bakker wrote:
> we intend to reduce the number of entities in HR:
>
> EmplLeave
> EmplLeaveReasonType
> EmplLeaveType -> workeffort+related-entities so it also appears on
> the calendar
>
> JobInterview
> JobInterviewType -> communication event and related entities
>
> any comments or suggestions?
>
> Regards,
> Hans
>
>
>