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