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
