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: > > <!--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 > > > -- Antwebsystems.com: Quality OFBiz services for competitive prices
