[
https://issues.apache.org/jira/browse/OFBIZ-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880128#action_12880128
]
BJ Freeman edited comment on OFBIZ-3825 at 6/18/10 5:34 AM:
------------------------------------------------------------
As i stated before all the leave data storage can be done with the
partybenifiet entitiy.
the goal of the model is reuse as much of the basic entities as possible.
Agreements would be a one to many relationship with the partyID.
the type of agreements would be in the agreement, not related to agreement
ID''s
refer to page 146 of vol I.
Agreement roles would by permanent or contractual employees.
as agreement changes new agreements are generated and/or new agreement Items.
leave would be defined under a agreement Item.
to carry this further, a company may have different location and the agreement
may differ for employments in those locations.
refer to page 149.
Just as a thought the leaves can be a product in the agreement. again this
resuses entities and provide an open ended way to describe things.
for instance, if a party benifit was insturance the the Agreement could have a
product from a insurance company.
Agreements type employment are also determine by the organization. so there may
be a union that had a contract agreement with the company that would effect
leave.following the Agreement Item layout allows for that, in the future, if
you don't want to do any code on it now.
Leave types would be in the enumeration entity. take a look at enumTypeId
EMPLOY_STTS
https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=Enumeration&find=true&searchOptions_collapsed=false&VIEW_SIZE=50&VIEW_INDEX=0
So would be LEAVE_STTS and LEAVE_REAS(ON) that puts an a one to many
relationship for enumeration ID in partybenefit that leaves it open for many
other enumerations, depending on the benefit.
When an employee is going to be interview they will need to know what their
benefits are,so the time the HR Admin setup up the appointment they have
associated the Resume with a job postion. HR admin selects the company location
if many, which then calls up the agreements for that organization.That Job
postion will be associate with those agreements.
once the perspective employee is hired the HR admin changes the employment
status to Hired and the code would then generate the partybenifits from the
agreements. as well as associate the partyid of the employee to the agreements.
and partybenifits
when a employee wants to request leave they are presented with the accrued
benefits.
they select the type of leave that then narrows the benifits available.
they then enter a number within the range available and a start date from
their calendar.. they submit for approval. this add a tentative workeffort of
not availible for that period.
there can be a check box for extra ordinary leave that should be covered under
agreements, other wise it would not show.
once approved or denied they get a message in my portal that informs them of
the status of thier request.
Thier Work effort (calendar) is updated so any planning on projects will be
aware of their unavailability
was (Author: bjfreeman):
As i stated before all the leave data storage can be done with the
partybenifiet entitiy.
the goal of the model is reuse as much of the basic entities as possible.
Agreements would be a one to many relationship with the partyID.
the type of agreements would be in the agreement, not related to agreement
ID''s
refer to page 146 of vol I.
Agreement roles would by permanent or contractual employees.
as agreement changes new agreements are generated and/or new agreement Items.
leave would be defined under a agreement Item.
to carry this further, a company may have different location and the agreement
may differ for employments in those locations.
refer to page 149.
Just as a thought the leaves can be a product in the agreement. again this
resuses entities and provide an open ended way to describe things.
for instance, if a party benifit was insturance the the Agreement could have a
product from a insurance company.
Agreements type employment are also determine by the organization. so there may
be a union that had a contract agreement with the company that would effect
leave.following the Agreement Item layout allows for that, in the future,
ifyoiu don't want to do any code on it now.
Leave types would be in the enumeration entity. take a look at enumTypeId
EMPLOY_STTS
https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=Enumeration&find=true&searchOptions_collapsed=false&VIEW_SIZE=50&VIEW_INDEX=0
So would be LEAVE_STTS and LEAVE_REAS(ON) that puts an a one to many
relationship for enumeration ID in partybenefit that leaves it open for many
other enumerations, depending on the benefit.
When an employee is going to be interview they will need to know what their
benefits are,so the time the HR Admin setup up the appointment they have
associated the Resume with a job postion. HR admin selects the company location
if many, which then calls up the agreements for that organization.That Job
postion will be associate with those agreements.
once the perspective employee is hired the HR admin changes the employment
status to Hired and the code would then generate the partybenifits from the
agreements. as well as associate the partyid of the employee to the agreements.
and partybenifits
when a employee wants to request leave they are presented with the accrued
benefits.
they select the type of leave that then narrows the benifits available.
they then enter a number within the range available. and submits it.
there can be a check box for extra ordinary leave that should be covered under
agreements, other wise it would not show.
once approved or denied they get a message in my portal that informs them of
the status of thier request.
Thier Work effort (calendar) is updated so any planning on projects will be
aware of their unavailability
> Proposal for adding new functionality in Leave sub tab under HR module
> ----------------------------------------------------------------------
>
> Key: OFBIZ-3825
> URL: https://issues.apache.org/jira/browse/OFBIZ-3825
> Project: OFBiz
> Issue Type: Improvement
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP, JDK 1.6
> Reporter: Swapnil Sawant
> Priority: Minor
> Fix For: SVN trunk
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> I wish to do some enhancement in existing Leave functionality taking Party
> benefits into consideration in OFBiz.
> Existing functionalities :
> - Currently employee can create leave by selecting his
> approver.
> - Approver will approve the leave applied by the
> employee.
>
> New functionality :
> - Admin party will credit leaves at the beginning of a financial year
> for employees
> - These leaves can be taken by employee under available benefits from
> Party Benefit
> - Party Benefits will be setup for each employee as per existing flow
> - Whenever employee creates leave application, his/her benefits will be
> checked for validation purpose(relation will be set between leave
> reason type and benefit type) along with exclusion of weekend and
> organization wide holidays.
> - On leave approval, corresponding number of leaves would be deducted
> from employee's leave account.
>
> For implementing this, following modifications are being
> thought of :
> - Adding foreign key column 'benefitTypeId' in 'EmplLeaveReasonType'
> (reference from
> benefitType.benefitTypeId)
> By maintaining this relation, each time employee creates a leave
> application (with some leave reason type Id),we can keep track of
> 'availableTime' for this particular employee/party-benefitType combination
> - We can have CreditEmplLeave,EmplLeave and Holiday tables as mention
> in the below thread
> http://ofbiz.135035.n4.nabble.com/Proposal-for-adding-new-functionality-in-Leave-sub-tab-under-HR-module-td2250139.html#a2250139
> Following is a demo flow of above mentioned functionality :
> 1.Admin credits leaves for an employee.
> 2.Employee applies for leave for first time with leave reason type as
> 'Medical' (for time being lets assume 'Sick Leave' is benefit type for
> this leave reason type in 'EmplLeaveReasonType' table)
> 3.Before creating leave application, we would check following two
> things :
> - If that employee has enough leave balance
> - If employee has not crossed 'availableTime' threshold for
> benefit type 'Sick Leave'(using Party Benefits already setup through other
> existing screen)
> 4.After leave application is created, approver can
> approve/reject it
> 5.Corresponding updations will be made in 'EmplLeave'(changing status
> to approve/rejected) and CreditEmplLeave tables(deduction if approved)
> Thanks & Regards,
> Swapnil Sawant
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
