-----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-----
