Details
Critical
Description
— STEPS TO REPRODUCE —
1. Create a new/clean database.
2. Create a contact with a job that pays $100/day.
3. Run the report, "Annual and Monthly Cost Equivalents Report".
4. Observe: The listed annual cost is $100/year. (The monthly cost intuitively appears as 1/12th the annual cost, but the annual cost is way off.)
— WHAT'S MISSING (GENERAL GOALS) —
a. For each pay-unit (per day, per month, per year), we need a formula that annualizes the cost.
b. The formula will most likely need some more data (eg either a system-wide policy on "hours per year", "days per year", etc; or else some per-record data about "days per year for this person"). We need to define the process/UI for entering that data.
c. When a user edits a job's pay, we should display the calculations done to estimate annualized cost.
d. When a user runs the report, we should use the formulas.
e. We need to update the test-case for the report (eg https://github.com/civicrm/civihr/blob/master/hrreport/tests/phpunit/CRM/HRReport/Form/Contact/fixtures/summary-annual-monthly-equiv.csv ).
Attachments
Issue Links
- is blocked by
-
CRM-14253 REST interface treats all cookies as API parameters; breaks Setting API
-
- Done/Fixed
-
Activity
The UI in the mockup is quite clear and appropriate. The only change I'd recommend is in the intro text for the admin UI (editing the pay constants):
Current text:
"The constants defined in this box are used to estimate the amount of work done in each year."
"For example, if an employee makes $10 / hour and the standard is 2,000 hour/year then the estimate annual pay is $20,000."
Suggested text:
"The values below are used to calculate the estimated Annualized Pay for each job based on it's Pay Rate."
"For example, if "hours per year" is 2,000 and the Pay Rate for a job is $10 / hour, then the estimated Annualized Pay for that job is $20,000."
We should also parameterize the text to use the configured default currency in the amount portions of the strings.
A good point was raised that this doesn't weight based on the person's time commitment (eg their FTE value). I don't think that will remove any work – so we'll add in support for weighting by FTE in a second pass.
Vivek's PR: https://github.com/civicrm/civihr/pull/256
Several outstanding issues in the PR.
Reminder to self about outstanding tasks:
- Update UI to match wireframe (esp. to support locking/unlocking estimate)
- Update reports
- Investigate weird settings initialization (works fine with "bash bin/drush-install.sh" but not "bash bin/drush-install.sh --with-sample-data")
- Nice-to-have: Automatically calculate hours_fte (using same general approach as calculating annual pay)
Attach mockup of annualized-pay-estimates.