OFBiz › OFBiz - User

Discussion: HR payroll entity anomalies.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Hans Bakker

Discussion: HR payroll entity anomalies.

Community opinion requested:

I am looking to integrate Payroll functions into Human resources
component. I studied the current status of the component and looked at
the Datamodel resource book and see the entities are exactly copied,
except for the the paycheck where we did not follow the book and used
the Invoice for that.

Although normally the datamodels in the book are pretty good, for the HR
component there are some strange things which make it difficult to
understand:

Payrol benefits:
1. PartyBenefit is linked to employment (same key) but is called
PartyBenefit, why not EmploymentBenefit?
2. BenefitType now should link to invoiceItemType

Payrol deductions:
1. Deduction is only linked to a paymentId with an amount. We now use
the invoiceItem for that, so this entity is redundant.
3. DeductionType seems to be ok (better name: EmplDeductionType) but
should now be linked to invoiceItemType instead of Deduction.
4. The entity PartyBenefit or better EmploymentBenefit is missing
completely and should have a similar function as PartyBenefit but then
subtracted from the gross amount in payroll.

Employment Pay history:
PayHistory has the same key as employment so why is the name not called
EmploymentPayHistory?

Because the entities do not start with employment they are also not
listed together in the entity list and therefore this part is difficult
to understand.

Anybody any preferences or strong opinions here?

I do not expect that this part of the system is used? I am prepared to
put some effort to change this, if we agree that it is not required to
write any data-migration tools.

Regards,
Hans

--
http://www.antwebsystems.com :
Quality OFBiz support for competitive rates....

David E Jones-3

Re: Discussion: HR payroll entity anomalies.

My main thought on this is to just make sure to compile requirements
for what data you need to track before trying to design a data model
for it. In other words, list all of the "data elements" (don't worry
about whether they will be an entity or a field at first), and then
define relationships between them, group them together, and the data
model will emerge from that.

-David

On Feb 4, 2009, at 7:45 PM, Hans Bakker wrote:

> Community opinion requested:
>
> I am looking to integrate Payroll functions into Human resources
> component. I studied the current status of the component and looked at
> the Datamodel resource book and see the entities are exactly copied,
> except for the the paycheck where we did not follow the book and used
> the Invoice for that.
>
> Although normally the datamodels in the book are pretty good, for
> the HR
> component there are some strange things which make it difficult to
> understand:
>
> Payrol benefits:
> 1. PartyBenefit is linked to employment (same key) but is called
> PartyBenefit, why not EmploymentBenefit?
> 2. BenefitType now should link to invoiceItemType
>
> Payrol deductions:
> 1. Deduction is only linked to a paymentId with an amount. We now use
> the invoiceItem for that, so this entity is redundant.
> 3. DeductionType seems to be ok (better name: EmplDeductionType) but
> should now be linked to invoiceItemType instead of Deduction.
> 4. The entity PartyBenefit or better EmploymentBenefit is missing
> completely and should have a similar function as PartyBenefit but then
> subtracted from the gross amount in payroll.
>
> Employment Pay history:
> PayHistory has the same key as employment so why is the name not
> called
> EmploymentPayHistory?
>
> Because the entities do not start with employment they are also not
> listed together in the entity list and therefore this part is
> difficult
> to understand.
>
> Anybody any preferences or strong opinions here?
>
> I do not expect that this part of the system is used? I am prepared to
> put some effort to change this, if we agree that it is not required to
> write any data-migration tools.
>
> Regards,
> Hans
>
>
> --
> http://www.antwebsystems.com :
> Quality OFBiz support for competitive rates....
>

hans_bakker

Re: Discussion: HR payroll entity anomalies.

David, that is exactly what i did, have the requirements from the
customer, then to try to match them on the current datamodel and list
the problems i found.

actually i also found another problem:

The key of the employment, partyBenefit, payHistory, entity is:
roletypeIdfrom roletypeIdto partyIdfrom partyIdTo fromdate

1. partyIdFrom is always an organizationPartyId so a party in the role
of organization
2. so why is the role/from/to and partyFrom/to duplicated over all the
files? Therefore i propose to have an "employmentId" and have part of
the current key role/from/to and partyFrom/to only in the employment
entity and not in the others.

regards,
Hans

On Wed, 2009-02-04 at 21:14 -0700, David E Jones wrote:

> My main thought on this is to just make sure to compile requirements
> for what data you need to track before trying to design a data model
> for it. In other words, list all of the "data elements" (don't worry
> about whether they will be an entity or a field at first), and then
> define relationships between them, group them together, and the data
> model will emerge from that.
>
> -David
>
>
> On Feb 4, 2009, at 7:45 PM, Hans Bakker wrote:
>
> > Community opinion requested:
> >
> > I am looking to integrate Payroll functions into Human resources
> > component. I studied the current status of the component and looked at
> > the Datamodel resource book and see the entities are exactly copied,
> > except for the the paycheck where we did not follow the book and used
> > the Invoice for that.
> >
> > Although normally the datamodels in the book are pretty good, for
> > the HR
> > component there are some strange things which make it difficult to
> > understand:
> >
> > Payrol benefits:
> > 1. PartyBenefit is linked to employment (same key) but is called
> > PartyBenefit, why not EmploymentBenefit?
> > 2. BenefitType now should link to invoiceItemType
> >
> > Payrol deductions:
> > 1. Deduction is only linked to a paymentId with an amount. We now use
> > the invoiceItem for that, so this entity is redundant.
> > 3. DeductionType seems to be ok (better name: EmplDeductionType) but
> > should now be linked to invoiceItemType instead of Deduction.
> > 4. The entity PartyBenefit or better EmploymentBenefit is missing
> > completely and should have a similar function as PartyBenefit but then
> > subtracted from the gross amount in payroll.
> >
> > Employment Pay history:
> > PayHistory has the same key as employment so why is the name not
> > called
> > EmploymentPayHistory?
> >
> > Because the entities do not start with employment they are also not
> > listed together in the entity list and therefore this part is
> > difficult
> > to understand.
> >
> > Anybody any preferences or strong opinions here?
> >
> > I do not expect that this part of the system is used? I am prepared to
> > put some effort to change this, if we agree that it is not required to
> > write any data-migration tools.
> >
> > Regards,
> > Hans
> >
> >
> > --
> > http://www.antwebsystems.com :
> > Quality OFBiz support for competitive rates....
> >
>

--
Antwebsystems.com: Quality OFBiz services for competitive prices

David E Jones-3

Re: Discussion: HR payroll entity anomalies.

On Feb 4, 2009, at 10:49 PM, Hans Bakker wrote:

> David, that is exactly what i did, have the requirements from the
> customer, then to try to match them on the current datamodel and list
> the problems i found.

Could you share those? It would make a discussion a lot easier, less
hypothetical.

> actually i also found another problem:
>
> The key of the employment, partyBenefit, payHistory, entity is:
> roletypeIdfrom roletypeIdto partyIdfrom partyIdTo fromdate
>
> 1. partyIdFrom is always an organizationPartyId so a party in the
> role
> of organization
> 2. so why is the role/from/to and partyFrom/to duplicated over all the
> files? Therefore i propose to have an "employmentId" and have part of
> the current key role/from/to and partyFrom/to only in the employment
> entity and not in the others.

That is the case for your needs now, but what if other needs come up
in the future or if others have other needs? What if these are used to
model an employment relationship that does not involve and internal
organization?

-David

> On Wed, 2009-02-04 at 21:14 -0700, David E Jones wrote:
>> My main thought on this is to just make sure to compile requirements
>> for what data you need to track before trying to design a data model
>> for it. In other words, list all of the "data elements" (don't worry
>> about whether they will be an entity or a field at first), and then
>> define relationships between them, group them together, and the data
>> model will emerge from that.
>>
>> -David
>>
>>
>> On Feb 4, 2009, at 7:45 PM, Hans Bakker wrote:
>>
>>> Community opinion requested:
>>>
>>> I am looking to integrate Payroll functions into Human resources
>>> component. I studied the current status of the component and
>>> looked at
>>> the Datamodel resource book and see the entities are exactly copied,
>>> except for the the paycheck where we did not follow the book and
>>> used
>>> the Invoice for that.
>>>
>>> Although normally the datamodels in the book are pretty good, for
>>> the HR
>>> component there are some strange things which make it difficult to
>>> understand:
>>>
>>> Payrol benefits:
>>> 1. PartyBenefit is linked to employment (same key) but is called
>>> PartyBenefit, why not EmploymentBenefit?
>>> 2. BenefitType now should link to invoiceItemType
>>>
>>> Payrol deductions:
>>> 1. Deduction is only linked to a paymentId with an amount. We now
>>> use
>>> the invoiceItem for that, so this entity is redundant.
>>> 3. DeductionType seems to be ok (better name: EmplDeductionType) but
>>> should now be linked to invoiceItemType instead of Deduction.
>>> 4. The entity PartyBenefit or better EmploymentBenefit is missing
>>> completely and should have a similar function as PartyBenefit but
>>> then
>>> subtracted from the gross amount in payroll.
>>>
>>> Employment Pay history:
>>> PayHistory has the same key as employment so why is the name not
>>> called
>>> EmploymentPayHistory?
>>>
>>> Because the entities do not start with employment they are also not
>>> listed together in the entity list and therefore this part is
>>> difficult
>>> to understand.
>>>
>>> Anybody any preferences or strong opinions here?
>>>
>>> I do not expect that this part of the system is used? I am
>>> prepared to
>>> put some effort to change this, if we agree that it is not
>>> required to
>>> write any data-migration tools.
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> --
>>> http://www.antwebsystems.com :
>>> Quality OFBiz support for competitive rates....
>>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive prices
>

hans_bakker

Re: Discussion: HR payroll entity anomalies.

David,

I really hope you are not going to slow down this implementation, as you
did last time. The basic requirements you can see already for some time
in the invoice items types I added and are available in the file
applications/accounting/data/AccountingTypeData.xml under the heading:


What the customer now wants is to set the parameters in the HR component
to be able to automatically generate these payroll slips
(invoice/payment/application) every payperiod. All these parameters are
related to the employment entity where we need : benefits, deductions
(including tax) and Earnings and Hours. Then we need a list to
show/approve and print the generated payslip preferably in the HR
component...(can already do in the accounting component)

i was trying to use the current entities and saw the problems i listed
below.

regards,
Hans

On Wed, 2009-02-04 at 23:01 -0700, David E Jones wrote:

> On Feb 4, 2009, at 10:49 PM, Hans Bakker wrote:
>
> > David, that is exactly what i did, have the requirements from the
> > customer, then to try to match them on the current datamodel and list
> > the problems i found.
>
> Could you share those? It would make a discussion a lot easier, less
> hypothetical.
>
> > actually i also found another problem:
> >
> > The key of the employment, partyBenefit, payHistory, entity is:
> > roletypeIdfrom roletypeIdto partyIdfrom partyIdTo fromdate
> >
> > 1. partyIdFrom is always an organizationPartyId so a party in the
> > role
> > of organization
> > 2. so why is the role/from/to and partyFrom/to duplicated over all the
> > files? Therefore i propose to have an "employmentId" and have part of
> > the current key role/from/to and partyFrom/to only in the employment
> > entity and not in the others.
>
> That is the case for your needs now, but what if other needs come up
> in the future or if others have other needs? What if these are used to
> model an employment relationship that does not involve and internal
> organization?
>
> -David
>
>
> > On Wed, 2009-02-04 at 21:14 -0700, David E Jones wrote:
> >> My main thought on this is to just make sure to compile requirements
> >> for what data you need to track before trying to design a data model
> >> for it. In other words, list all of the "data elements" (don't worry
> >> about whether they will be an entity or a field at first), and then
> >> define relationships between them, group them together, and the data
> >> model will emerge from that.
> >>
> >> -David
> >>
> >>
> >> On Feb 4, 2009, at 7:45 PM, Hans Bakker wrote:
> >>
> >>> Community opinion requested:
> >>>
> >>> I am looking to integrate Payroll functions into Human resources
> >>> component. I studied the current status of the component and
> >>> looked at
> >>> the Datamodel resource book and see the entities are exactly copied,
> >>> except for the the paycheck where we did not follow the book and
> >>> used
> >>> the Invoice for that.
> >>>
> >>> Although normally the datamodels in the book are pretty good, for
> >>> the HR
> >>> component there are some strange things which make it difficult to
> >>> understand:
> >>>
> >>> Payrol benefits:
> >>> 1. PartyBenefit is linked to employment (same key) but is called
> >>> PartyBenefit, why not EmploymentBenefit?
> >>> 2. BenefitType now should link to invoiceItemType
> >>>
> >>> Payrol deductions:
> >>> 1. Deduction is only linked to a paymentId with an amount. We now
> >>> use
> >>> the invoiceItem for that, so this entity is redundant.
> >>> 3. DeductionType seems to be ok (better name: EmplDeductionType) but
> >>> should now be linked to invoiceItemType instead of Deduction.
> >>> 4. The entity PartyBenefit or better EmploymentBenefit is missing
> >>> completely and should have a similar function as PartyBenefit but
> >>> then
> >>> subtracted from the gross amount in payroll.
> >>>
> >>> Employment Pay history:
> >>> PayHistory has the same key as employment so why is the name not
> >>> called
> >>> EmploymentPayHistory?
> >>>
> >>> Because the entities do not start with employment they are also not
> >>> listed together in the entity list and therefore this part is
> >>> difficult
> >>> to understand.
> >>>
> >>> Anybody any preferences or strong opinions here?
> >>>
> >>> I do not expect that this part of the system is used? I am
> >>> prepared to
> >>> put some effort to change this, if we agree that it is not
> >>> required to
> >>> write any data-migration tools.
> >>>
> >>> Regards,
> >>> Hans
> >>>
> >>>
> >>> --
> >>> http://www.antwebsystems.com :
> >>> Quality OFBiz support for competitive rates....
> >>>
> >>
> > --
> > Antwebsystems.com: Quality OFBiz services for competitive prices
> >
>

--
Antwebsystems.com: Quality OFBiz services for competitive prices

David E Jones-3

Re: Discussion: HR payroll entity anomalies.

On Feb 4, 2009, at 11:19 PM, Hans Bakker wrote:

> David,
>
> I really hope you are not going to slow down this implementation, as
> you
> did last time.

Give me a break. Don't pretend like you want collaboration and
comments if you really don't. I'll bow out here as honestly I'm not
all that interested in investing personal time in this, and I have no
clients interested this at the minute.

If anyone else is interested in this stuff, please do join in as many
eyes help make things more generally useful along with many other
benefits of collaboration... which is the real power behind the
development model used for OFBiz.

-David

> The basic requirements you can see already for some time
> in the invoice items types I added and are available in the file
> applications/accounting/data/AccountingTypeData.xml under the heading:
> 
>
> What the customer now wants is to set the parameters in the HR
> component
> to be able to automatically generate these payroll slips
> (invoice/payment/application) every payperiod. All these parameters
> are
> related to the employment entity where we need : benefits, deductions
> (including tax) and Earnings and Hours. Then we need a list to
> show/approve and print the generated payslip preferably in the HR
> component...(can already do in the accounting component)
>
> i was trying to use the current entities and saw the problems i listed
> below.
>
> regards,
> Hans
>
> On Wed, 2009-02-04 at 23:01 -0700, David E Jones wrote:
>> On Feb 4, 2009, at 10:49 PM, Hans Bakker wrote:
>>
>>> David, that is exactly what i did, have the requirements from the
>>> customer, then to try to match them on the current datamodel and
>>> list
>>> the problems i found.
>>
>> Could you share those? It would make a discussion a lot easier, less
>> hypothetical.
>>
>>> actually i also found another problem:
>>>
>>> The key of the employment, partyBenefit, payHistory, entity is:
>>> roletypeIdfrom roletypeIdto partyIdfrom partyIdTo fromdate
>>>
>>> 1. partyIdFrom is always an organizationPartyId so a party in the
>>> role
>>> of organization
>>> 2. so why is the role/from/to and partyFrom/to duplicated over all
>>> the
>>> files? Therefore i propose to have an "employmentId" and have part
>>> of
>>> the current key role/from/to and partyFrom/to only in the employment
>>> entity and not in the others.
>>
>> That is the case for your needs now, but what if other needs come up
>> in the future or if others have other needs? What if these are used
>> to
>> model an employment relationship that does not involve and internal
>> organization?
>>
>> -David
>>
>>
>>> On Wed, 2009-02-04 at 21:14 -0700, David E Jones wrote:
>>>> My main thought on this is to just make sure to compile
>>>> requirements
>>>> for what data you need to track before trying to design a data
>>>> model
>>>> for it. In other words, list all of the "data elements" (don't
>>>> worry
>>>> about whether they will be an entity or a field at first), and then
>>>> define relationships between them, group them together, and the
>>>> data
>>>> model will emerge from that.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Feb 4, 2009, at 7:45 PM, Hans Bakker wrote:
>>>>
>>>>> Community opinion requested:
>>>>>
>>>>> I am looking to integrate Payroll functions into Human resources
>>>>> component. I studied the current status of the component and
>>>>> looked at
>>>>> the Datamodel resource book and see the entities are exactly
>>>>> copied,
>>>>> except for the the paycheck where we did not follow the book and
>>>>> used
>>>>> the Invoice for that.
>>>>>
>>>>> Although normally the datamodels in the book are pretty good, for
>>>>> the HR
>>>>> component there are some strange things which make it difficult to
>>>>> understand:
>>>>>
>>>>> Payrol benefits:
>>>>> 1. PartyBenefit is linked to employment (same key) but is called
>>>>> PartyBenefit, why not EmploymentBenefit?
>>>>> 2. BenefitType now should link to invoiceItemType
>>>>>
>>>>> Payrol deductions:
>>>>> 1. Deduction is only linked to a paymentId with an amount. We now
>>>>> use
>>>>> the invoiceItem for that, so this entity is redundant.
>>>>> 3. DeductionType seems to be ok (better name: EmplDeductionType)
>>>>> but
>>>>> should now be linked to invoiceItemType instead of Deduction.
>>>>> 4. The entity PartyBenefit or better EmploymentBenefit is missing
>>>>> completely and should have a similar function as PartyBenefit but
>>>>> then
>>>>> subtracted from the gross amount in payroll.
>>>>>
>>>>> Employment Pay history:
>>>>> PayHistory has the same key as employment so why is the name not
>>>>> called
>>>>> EmploymentPayHistory?
>>>>>
>>>>> Because the entities do not start with employment they are also
>>>>> not
>>>>> listed together in the entity list and therefore this part is
>>>>> difficult
>>>>> to understand.
>>>>>
>>>>> Anybody any preferences or strong opinions here?
>>>>>
>>>>> I do not expect that this part of the system is used? I am
>>>>> prepared to
>>>>> put some effort to change this, if we agree that it is not
>>>>> required to
>>>>> write any data-migration tools.
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>>
>>>>> --
>>>>> http://www.antwebsystems.com :
>>>>> Quality OFBiz support for competitive rates....
>>>>>
>>>>
>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive prices
>

hans_bakker

Re: Discussion: HR payroll entity anomalies.

Can you give me a break?
Can i give you some examples where i changed my proposed implementation?

1. I suggested to have a paycheck entity as was suggested in the
datamodel book, you suggested to use the invoice and i changed.
2. I suggested to have an invoice always in local currency, Jacopo
suggested to keep it in the original currency and convert it on the fly
and i changed (a lot of work)
3. I started the mypage component, portal pages were suggested and i am
now changing mypage to my portal using that...(a lot of work! hope to
complete it soon, have 2 students working on it)

only 3 examples in recent history were i changed the implementation...

so please come up with suggestions which make the implementation below
better and not only questioning what is proposed....
I think payroll is a valuable addition which can be shared.

Regards,
Hans

On Wed, 2009-02-04 at 23:34 -0700, David E Jones wrote:

> On Feb 4, 2009, at 11:19 PM, Hans Bakker wrote:
>
> > David,
> >
> > I really hope you are not going to slow down this implementation, as
> > you
> > did last time.
>
> Give me a break. Don't pretend like you want collaboration and
> comments if you really don't. I'll bow out here as honestly I'm not
> all that interested in investing personal time in this, and I have no
> clients interested this at the minute.
>
> If anyone else is interested in this stuff, please do join in as many
> eyes help make things more generally useful along with many other
> benefits of collaboration... which is the real power behind the
> development model used for OFBiz.
>
> -David
>
>
> > The basic requirements you can see already for some time
> > in the invoice items types I added and are available in the file
> > applications/accounting/data/AccountingTypeData.xml under the heading:
> > 
> >
> > What the customer now wants is to set the parameters in the HR
> > component
> > to be able to automatically generate these payroll slips
> > (invoice/payment/application) every payperiod. All these parameters
> > are
> > related to the employment entity where we need : benefits, deductions
> > (including tax) and Earnings and Hours. Then we need a list to
> > show/approve and print the generated payslip preferably in the HR
> > component...(can already do in the accounting component)
> >
> > i was trying to use the current entities and saw the problems i listed
> > below.
> >
> > regards,
> > Hans
> >
> > On Wed, 2009-02-04 at 23:01 -0700, David E Jones wrote:
> >> On Feb 4, 2009, at 10:49 PM, Hans Bakker wrote:
> >>
> >>> David, that is exactly what i did, have the requirements from the
> >>> customer, then to try to match them on the current datamodel and
> >>> list
> >>> the problems i found.
> >>
> >> Could you share those? It would make a discussion a lot easier, less
> >> hypothetical.
> >>
> >>> actually i also found another problem:
> >>>
> >>> The key of the employment, partyBenefit, payHistory, entity is:
> >>> roletypeIdfrom roletypeIdto partyIdfrom partyIdTo fromdate
> >>>
> >>> 1. partyIdFrom is always an organizationPartyId so a party in the
> >>> role
> >>> of organization
> >>> 2. so why is the role/from/to and partyFrom/to duplicated over all
> >>> the
> >>> files? Therefore i propose to have an "employmentId" and have part
> >>> of
> >>> the current key role/from/to and partyFrom/to only in the employment
> >>> entity and not in the others.
> >>
> >> That is the case for your needs now, but what if other needs come up
> >> in the future or if others have other needs? What if these are used
> >> to
> >> model an employment relationship that does not involve and internal
> >> organization?
> >>
> >> -David
> >>
> >>
> >>> On Wed, 2009-02-04 at 21:14 -0700, David E Jones wrote:
> >>>> My main thought on this is to just make sure to compile
> >>>> requirements
> >>>> for what data you need to track before trying to design a data
> >>>> model
> >>>> for it. In other words, list all of the "data elements" (don't
> >>>> worry
> >>>> about whether they will be an entity or a field at first), and then
> >>>> define relationships between them, group them together, and the
> >>>> data
> >>>> model will emerge from that.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Feb 4, 2009, at 7:45 PM, Hans Bakker wrote:
> >>>>
> >>>>> Community opinion requested:
> >>>>>
> >>>>> I am looking to integrate Payroll functions into Human resources
> >>>>> component. I studied the current status of the component and
> >>>>> looked at
> >>>>> the Datamodel resource book and see the entities are exactly
> >>>>> copied,
> >>>>> except for the the paycheck where we did not follow the book and
> >>>>> used
> >>>>> the Invoice for that.
> >>>>>
> >>>>> Although normally the datamodels in the book are pretty good, for
> >>>>> the HR
> >>>>> component there are some strange things which make it difficult to
> >>>>> understand:
> >>>>>
> >>>>> Payrol benefits:
> >>>>> 1. PartyBenefit is linked to employment (same key) but is called
> >>>>> PartyBenefit, why not EmploymentBenefit?
> >>>>> 2. BenefitType now should link to invoiceItemType
> >>>>>
> >>>>> Payrol deductions:
> >>>>> 1. Deduction is only linked to a paymentId with an amount. We now
> >>>>> use
> >>>>> the invoiceItem for that, so this entity is redundant.
> >>>>> 3. DeductionType seems to be ok (better name: EmplDeductionType)
> >>>>> but
> >>>>> should now be linked to invoiceItemType instead of Deduction.
> >>>>> 4. The entity PartyBenefit or better EmploymentBenefit is missing
> >>>>> completely and should have a similar function as PartyBenefit but
> >>>>> then
> >>>>> subtracted from the gross amount in payroll.
> >>>>>
> >>>>> Employment Pay history:
> >>>>> PayHistory has the same key as employment so why is the name not
> >>>>> called
> >>>>> EmploymentPayHistory?
> >>>>>
> >>>>> Because the entities do not start with employment they are also
> >>>>> not
> >>>>> listed together in the entity list and therefore this part is
> >>>>> difficult
> >>>>> to understand.
> >>>>>
> >>>>> Anybody any preferences or strong opinions here?
> >>>>>
> >>>>> I do not expect that this part of the system is used? I am
> >>>>> prepared to
> >>>>> put some effort to change this, if we agree that it is not
> >>>>> required to
> >>>>> write any data-migration tools.
> >>>>>
> >>>>> Regards,
> >>>>> Hans
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://www.antwebsystems.com :
> >>>>> Quality OFBiz support for competitive rates....
> >>>>>
> >>>>
> >>> --
> >>> Antwebsystems.com: Quality OFBiz services for competitive prices
> >>>
> >>
> > --
> > Antwebsystems.com: Quality OFBiz services for competitive prices
> >
>

--
Antwebsystems.com: Quality OFBiz services for competitive prices

Adrian Crum-2

Re: Discussion: HR payroll entity anomalies.

In reply to this post by David E Jones-3

I have a problem with this approach too. I don't like the idea of rushing half-baked code into the project just because a client is in a hurry for it.

-Adrian

--- On Wed, 2/4/09, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Discussion: HR payroll entity anomalies.
> To: [hidden email]
> Date: Wednesday, February 4, 2009, 10:34 PM
> On Feb 4, 2009, at 11:19 PM, Hans Bakker wrote:
>
> > David,
> >
> > I really hope you are not going to slow down this
> implementation, as you
> > did last time.
>
> Give me a break. Don't pretend like you want
> collaboration and comments if you really don't. I'll
> bow out here as honestly I'm not all that interested in
> investing personal time in this, and I have no clients
> interested this at the minute.
>
> If anyone else is interested in this stuff, please do join
> in as many eyes help make things more generally useful along
> with many other benefits of collaboration... which is the
> real power behind the development model used for OFBiz.
>
> -David
>
>
> > The basic requirements you can see already for some
> time
> > in the invoice items types I added and are available
> in the file
> > applications/accounting/data/AccountingTypeData.xml
> under the heading:
> > 
> >
> > What the customer now wants is to set the parameters
> in the HR component
> > to be able to automatically generate these payroll
> slips
> > (invoice/payment/application) every payperiod. All
> these parameters are
> > related to the employment entity where we need :
> benefits, deductions
> > (including tax) and Earnings and Hours. Then we need a
> list to
> > show/approve and print the generated payslip
> preferably in the HR
> > component...(can already do in the accounting
> component)
> >
> > i was trying to use the current entities and saw the
> problems i listed
> > below.
> >
> > regards,
> > Hans
> >
> > On Wed, 2009-02-04 at 23:01 -0700, David E Jones
> wrote:
> >> On Feb 4, 2009, at 10:49 PM, Hans Bakker wrote:
> >>
> >>> David, that is exactly what i did, have the
> requirements from the
> >>> customer, then to try to match them on the
> current datamodel and list
> >>> the problems i found.
> >>
> >> Could you share those? It would make a discussion
> a lot easier, less
> >> hypothetical.
> >>
> >>> actually i also found another problem:
> >>>
> >>> The key of the employment, partyBenefit,
> payHistory, entity is:
> >>> roletypeIdfrom roletypeIdto partyIdfrom
> partyIdTo fromdate
> >>>
> >>> 1. partyIdFrom is always an
> organizationPartyId so a party in the
> >>> role
> >>> of organization
> >>> 2. so why is the role/from/to and partyFrom/to
> duplicated over all the
> >>> files? Therefore i propose to have an
> "employmentId" and have part of
> >>> the current key role/from/to and partyFrom/to
> only in the employment
> >>> entity and not in the others.
> >>
> >> That is the case for your needs now, but what if
> other needs come up
> >> in the future or if others have other needs? What
> if these are used to
> >> model an employment relationship that does not
> involve and internal
> >> organization?
> >>
> >> -David
> >>
> >>
> >>> On Wed, 2009-02-04 at 21:14 -0700, David E
> Jones wrote:
> >>>> My main thought on this is to just make
> sure to compile requirements
> >>>> for what data you need to track before
> trying to design a data model
> >>>> for it. In other words, list all of the
> "data elements" (don't worry
> >>>> about whether they will be an entity or a
> field at first), and then
> >>>> define relationships between them, group
> them together, and the data
> >>>> model will emerge from that.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Feb 4, 2009, at 7:45 PM, Hans Bakker
> wrote:
> >>>>
> >>>>> Community opinion requested:
> >>>>>
> >>>>> I am looking to integrate Payroll
> functions into Human resources
> >>>>> component. I studied the current
> status of the component and
> >>>>> looked at
> >>>>> the Datamodel resource book and see
> the entities are exactly copied,
> >>>>> except for the the paycheck where we
> did not follow the book and
> >>>>> used
> >>>>> the Invoice for that.
> >>>>>
> >>>>> Although normally the datamodels in
> the book are pretty good, for
> >>>>> the HR
> >>>>> component there are some strange
> things which make it difficult to
> >>>>> understand:
> >>>>>
> >>>>> Payrol benefits:
> >>>>> 1. PartyBenefit is linked to
> employment (same key) but is called
> >>>>> PartyBenefit, why not
> EmploymentBenefit?
> >>>>> 2. BenefitType now should link to
> invoiceItemType
> >>>>>
> >>>>> Payrol deductions:
> >>>>> 1. Deduction is only linked to a
> paymentId with an amount. We now
> >>>>> use
> >>>>> the invoiceItem for that, so this
> entity is redundant.
> >>>>> 3. DeductionType seems to be ok
> (better name: EmplDeductionType) but
> >>>>> should now be linked to
> invoiceItemType instead of Deduction.
> >>>>> 4. The entity PartyBenefit or better
> EmploymentBenefit is missing
> >>>>> completely and should have a similar
> function as PartyBenefit but
> >>>>> then
> >>>>> subtracted from the gross amount in
> payroll.
> >>>>>
> >>>>> Employment Pay history:
> >>>>> PayHistory has the same key as
> employment so why is the name not
> >>>>> called
> >>>>> EmploymentPayHistory?
> >>>>>
> >>>>> Because the entities do not start with
> employment they are also not
> >>>>> listed together in the entity list and
> therefore this part is
> >>>>> difficult
> >>>>> to understand.
> >>>>>
> >>>>> Anybody any preferences or strong
> opinions here?
> >>>>>
> >>>>> I do not expect that this part of the
> system is used? I am
> >>>>> prepared to
> >>>>> put some effort to change this, if we
> agree that it is not
> >>>>> required to
> >>>>> write any data-migration tools.
> >>>>>
> >>>>> Regards,
> >>>>> Hans
> >>>>>
> >>>>>
> >>>>> --http://www.antwebsystems.com :
> >>>>> Quality OFBiz support for competitive
> rates....
> >>>>>
> >>>>
> >>> --Antwebsystems.com: Quality OFBiz services
> for competitive prices
> >>>
> >>
> > --Antwebsystems.com: Quality OFBiz services for
> competitive prices
> >

BJ Freeman

Re: Discussion: HR payroll entity anomalies.

In reply to this post by Hans Bakker

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

before this I would like to interject a overview.
Not saying all this has to be implemented but make sure what direction
we go allows this later.
under the party we have:
union affiliations, when in turn is union dues, as a deduction.

Union Arbitration, as a company, but may effect party Payrate, deduction
benifits

Stock options which are a deduction but then is a asset to the party.

you have Witholding as a deduction with a subtype for the type of
witholding. which then is accumlated as a payment to the respective
agencies.

PS I wrote this before David and you had your exchange.
I wanted to do more thinking before submitting.
from the exchange I am not sure this is going to make a difference

so I will just submit it as is

Hans Bakker sent the following on 2/4/2009 6:45 PM:

> Community opinion requested:
>
> I am looking to integrate Payroll functions into Human resources
> component. I studied the current status of the component and looked at
> the Datamodel resource book and see the entities are exactly copied,
> except for the the paycheck where we did not follow the book and used
> the Invoice for that.
>
> Although normally the datamodels in the book are pretty good, for the HR
> component there are some strange things which make it difficult to
> understand:
>
> Payrol benefits:
> 1. PartyBenefit is linked to employment (same key) but is called
> PartyBenefit, why not EmploymentBenefit?
> 2. BenefitType now should link to invoiceItemType
>
> Payrol deductions:
> 1. Deduction is only linked to a paymentId with an amount. We now use
> the invoiceItem for that, so this entity is redundant.
> 3. DeductionType seems to be ok (better name: EmplDeductionType) but
> should now be linked to invoiceItemType instead of Deduction.
> 4. The entity PartyBenefit or better EmploymentBenefit is missing
> completely and should have a similar function as PartyBenefit but then
> subtracted from the gross amount in payroll.
>
> Employment Pay history:
> PayHistory has the same key as employment so why is the name not called
> EmploymentPayHistory?
>
> Because the entities do not start with employment they are also not
> listed together in the entity list and therefore this part is difficult
> to understand.
>
> Anybody any preferences or strong opinions here?
>
> I do not expect that this part of the system is used? I am prepared to
> put some effort to change this, if we agree that it is not required to
> write any data-migration tools.
>
> Regards,
> Hans
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJiqywrP3NbaWWqE4RAqLPAKCrrJ1yL42EQ/DWIwVRl49IYPJVOwCgxbt6
EIiY5NwPktAFsd5VV09CpnU=
=mgCO
-----END PGP SIGNATURE-----