New field to TimeEntry entity?

[Bilgin Ibryam]

What do you think about adding a new field to TimeEntry entity for
keeping the time entry type, like: Night shift, Day shift, Evening
shift?
I don't see a field for storing this kind of information. It could be an
optional field from Enumeration entity.

Bilgin

[hans_bakker]

Bilgin,

the first question is always: what business problem are you trying to
solve? If it is the different rate you want to use to your customer then
you can use the the 'rateType' for that, to indicate a dayly rate or a
special overtime rate for the evening or night.

Regards,
Hans

On Tue, 2008-06-03 at 14:47 +0300, Bilgin Ibryam wrote:
> What do you think about adding a new field to TimeEntry entity for
> keeping the time entry type, like: Night shift, Day shift, Evening
> shift?
> I don't see a field for storing this kind of information. It could be an
> optional field from Enumeration entity.
>
> Bilgin
>
>
--
AntWebsystems.com: Quality OFBiz services for competitive rates.....

[Bilgin Ibryam]

Hans,
Thanks for your answer.

I want to add a field which can be used to classify the time entries
based on time but not rate. And this field will be informative for the
user, but not for the customer.
In industries where Shift work hours are used instead of standard
working day hours, the user can easily check only which shift he/she is.
Also you can have for example the same rate for Day shift and Evening
shift, these fields are not related in most cases.

WDYT?

[hans_bakker]

Hi Bilgin...still sounds a bit questionable because time entries are
after the fact...if you want to use it for planning, then workefforts
are more appropriate.

Regards
Hans
 
On Tue, 2008-06-03 at 16:07 +0300, Bilgin Ibryam wrote:

> Hans,
> Thanks for your answer.
>
> I want to add a field which can be used to classify the time entries
> based on time but not rate. And this field will be informative for the
> user, but not for the customer.
> In industries where Shift work hours are used instead of standard
> working day hours, the user can easily check only which shift he/she is.
> Also you can have for example the same rate for Day shift and Evening
> shift, these fields are not related in most cases.
>
> WDYT?
>
>

--
AntWebsystems.com: Quality OFBiz services for competitive rates.....

[David E Jones]

Yes, that's an interesting point Hans. Bilgin: is planning before hand  
what you had in mind?

My thoughts reading this were that the shift they are part of is  
redundant information because they can specify the starting and ending  
times as opposed to just a number of hours (using the fromDate and  
thruDate). If you wanted to see a report by shift you should be able  
to figure out the shift they are in. In a report or wherever the shift  
information is used you could have that configurable or built in  
("hard coded" if you will).

If being "in a shift" means that they are part of a group then a  
PartyGroup that they have a membership relationship to would be a  
better way to model it. That relationship can have from/thru dates so  
they can change groups over time, etc as well.

-David


On Jun 3, 2008, at 7:27 AM, Hans Bakker wrote:

> Hi Bilgin...still sounds a bit questionable because time entries are
> after the fact...if you want to use it for planning, then workefforts
> are more appropriate.
>
> Regards
> Hans
>
> On Tue, 2008-06-03 at 16:07 +0300, Bilgin Ibryam wrote:
>> Hans,
>> Thanks for your answer.
>>
>> I want to add a field which can be used to classify the time entries
>> based on time but not rate. And this field will be informative for  
>> the
>> user, but not for the customer.
>> In industries where Shift work hours are used instead of standard
>> working day hours, the user can easily check only which shift he/
>> she is.
>> Also you can have for example the same rate for Day shift and Evening
>> shift, these fields are not related in most cases.
>>
>> WDYT?
>>
>>
> --
> AntWebsystems.com: Quality OFBiz services for competitive rates.....
>

[Bilgin Ibryam]

David,

> Bilgin: is planning before hand what you had in mind?
Yes, I want to use Timesheet and TimeEntry entities to plan in advance
the working hours of employees. These two entities looks like enough for
this purpose?
You are right, this field seems redundant. The shifts can be retrieved
using the fromDate and thruDate fields.

Hans,

Can you tell me why you think that workefforts are more appropriate for
planning in advance?

Thanks to both of you.

[David E Jones]

On Jun 3, 2008, at 9:30 AM, Bilgin Ibryam wrote:

> David,
>
>> Bilgin: is planning before hand what you had in mind?
> Yes, I want to use Timesheet and TimeEntry entities to plan in advance
> the working hours of employees. These two entities looks like enough  
> for
> this purpose?
> You are right, this field seems redundant. The shifts can be retrieved
> using the fromDate and thruDate fields.
>
> Hans,
>
> Can you tell me why you think that workefforts are more appropriate  
> for
> planning in advance?
>
> Thanks to both of you.

Yes, in that case I'd agree that WorkEffort is far more appropriate.  
TimeEntry records are meant to model only time that has been finished  
and is billable.

There is a WorkEffortType with workEffortTypeId="AVAILABLE" that is  
meant to model when a person is available (can be used for should be  
working, etc). This is meant to be used to model a work week including  
hours of the day, etc. The recent stuff for the recurrence rule  
enhancements will make this more useful, though I think those need to  
be used in the calendar display and what not to be effective here.  
Events planned would overlay AVAILABLE work efforts to override the  
availability for anything pre-scheduled within the working day (or  
working time period, not to be day/night biased... ;) ).

-David