[
https://issues.apache.org/jira/browse/OFBIZ-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654673#action_12654673
]
David E. Jones commented on OFBIZ-2037:
---------------------------------------
My suggestion, and request, was to discuss the data model and settle on that
BEFORE doing any development. Otherwise, this is going to be painful over and
over. If you don't plan and design and check the design before building, then
your chances of something coming up that invalidates earlier work are high.
It's that simple.
In this case, I already commented on this particular issue on the mailing list:
we don't want a general organization for the user, we want the organization for
the client or service provider party for the project (WorkEffort). A global
setting may actually cause significant harm because billing rates will go to
that organization instead of one associated with the project.
I'll ask again, and please consider this as a request to collaborate and not
criticism of your effort or you as an individual: can we start with
requirements for processes and data, then build a data model, then build the
app... and in each step discuss and review before making wide-reaching changes?
> Re-organize RateType, rateAmount and rateCurrency organization in ofbiz.
> --------------------------------------------------------------------------
>
> Key: OFBIZ-2037
> URL: https://issues.apache.org/jira/browse/OFBIZ-2037
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting, humanres, specialpurpose/projectmgr,
> workeffort
> Affects Versions: SVN trunk
> Environment: any
> Reporter: Hans Bakker
> Assignee: Hans Bakker
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: rateChange.diff, rateMod3.diff
>
>
> the rateAmount in ofbiz is defined by the rate type and then by the following
> criteria when defined:
> from most specific to most general:
> 1. for a partyId (partyRate)
> 2. for a workEffort/timeentry (workEffortAssignmentRate)
> 3. for a employee position (EmplPositionTypeRate)
> 4. for a the default rateTypeId (RateType)
> The currency is defined in level 1,4 but not in the others. It should also be
> possible to specify the currency at any level.
> What is proposed:
> ===========
> 1. remove currencyUomId and (normal)rate(amount) in the partyRate and
> rateType (level 1,4) entities
> 2. remove rate(amount) from the workEffortAssignmentRate and employee
> position (level 2,3) entities
> 3. create a new entity: RateAmount with the following fields:
> primary key:
> rateTypeId
> rateCurrencyUomId
> workEffortId
> partyId
> emplPositionTypeId
> periodTypeId (from the PeriodType entity: per
> hour/day/week/month/quarter)
> fromDate
> non-key fields:
> thruDate
> rateAmount
> 4. create a service "getRateAmount" which will retrieve the applicable rate
> amount for the data provided searching from most specific to most general
> 5. depreciate the getPartyRate service.
> 6. create the createRateAmount and deleteRateAmount(expire) service to update
> the new entity
> 7. update existing services and forms.
> QUESTION:
> should the accounting organization partyId be in the key of the new
> RateAmount entity?
> Regards,
> Hans
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.