Mailing-List: contact user-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@ofbiz.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID;
  b=1M2FuuWNlIVIIxJMnuLqBVr7oLJB/i+SFdwx3pKFH5S1lyV9rupH3mT/RMLvN66nJnCoFrCmBU5kqLLgVjg9rO9NEInNZ7wbZj4xuj5Xm2AaJB9oQ8SNw5n40poChYza1QfPpeYkvSWBRYhg4koRuQGaRzIB7TIS9QdtvMCvaOs=;
Date: Thu, 5 Feb 2009 00:16:09 -0800 (PST)
From: Adrian Crum <adrian.crum@yahoo.com>
Reply-To: adrian.crum@yahoo.com
Subject: Re: Discussion: HR payroll entity anomalies.
To: user@ofbiz.apache.org
In-Reply-To: <B90176A6-1F13-43C6-AEC8-CB37E69FE562@hotwaxmedia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <669463.6997.qm@web63104.mail.re1.yahoo.com>

I have a problem with this approach too. I don't like the idea of rushing half-baked code into the project just because a client is in a hurry for it.

-Adrian

--- On Wed, 2/4/09, David E Jones <david.jones@hotwaxmedia.com> wrote:

> From: David E Jones <david.jones@hotwaxmedia.com>
> Subject: Re: Discussion: HR payroll entity anomalies.
> To: user@ofbiz.apache.org
> Date: Wednesday, February 4, 2009, 10:34 PM
> 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
> >