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:
<!--New invoiceType: "Payrol"-->
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
