Skip to content

MPDX-9368 - Other Section of PDS Goal Calculator#1730

Merged
wjames111 merged 11 commits intomainfrom
MPDX-9368
Apr 20, 2026
Merged

MPDX-9368 - Other Section of PDS Goal Calculator#1730
wjames111 merged 11 commits intomainfrom
MPDX-9368

Conversation

@wjames111
Copy link
Copy Markdown
Contributor

@wjames111 wjames111 commented Apr 20, 2026

Description

  • Add SupportItemStep component that combines salary and other expense sections in the PDS Goal Calculator
  • Add SalarySection with a DataGrid displaying salary breakdown (base salary, geographic adjustment, gross monthly pay, employer FICA, and total)
  • Add OtherSection with a DataGrid displaying other expense breakdown (reimbursable expenses, 403(b) contributions, worker's comp, benefits, attrition, credit card fees, and assessment)
  • Add OtherExpenses calculation module with unit tests for computing other expense line items
  • Add salaryBreakdown and otherBreakdown row/column builders for DataGrid rendering
  • Refactor SalaryStep to render the new SupportItemStep component
  • Refactor salary calculation logic to use SalaryConstants for geographic multiplier and FICA rate

Related ticket: MPDX-9368
Depends on: #1721 (MPDX-9367 — SalarySection component)

Testing

  • Go to the PDS Goal Calculator
  • Fill in the required fields to reach the Support Item step
  • Check that the Salary section displays a breakdown table with base salary, geographic adjustment, gross monthly pay, employer FICA, and total
  • Check that the Other section displays a breakdown table with reimbursable expenses, 403(b), worker's comp, benefits, attrition, credit card fees, and assessment
  • Verify calculations match expected values based on the input salary and constants
  • Verify empty/null states render correctly (no table shown when data is missing)

Checklist:

  • I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)"
  • I have applied the appropriate labels (Add the label "Preview" to automatically create a preview environment)
  • I have run the Claude Code /pr-review command locally and fixed any relevant suggestions
  • I have requested a review from another person on the project
  • I have tested my changes in preview or in staging
  • I have cleaned up my commit history

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 20, 2026

Bundle sizes [mpdx-react]

Compared against 35fb128

Route Size (gzipped) Diff
/accountLists/[accountListId]/reports/pdsGoalCalculator/[pdsGoalId] 325.33 KB +1.06 KB

@wjames111 wjames111 changed the title MPDX 9368 MPDX-9368 - Other Section of PDS Goal Calculator Apr 20, 2026
@wjames111 wjames111 self-assigned this Apr 20, 2026
@wjames111 wjames111 added Preview Environment Add this label to create an Amplify Preview On Staging Will be merged to the staging branch by Github Actions labels Apr 20, 2026
@wjames111 wjames111 marked this pull request as ready for review April 20, 2026 17:26
@github-actions
Copy link
Copy Markdown
Contributor

Preview branch generated at https://MPDX-9368.d3dytjb8adxkk5.amplifyapp.com

@wjames111 wjames111 requested a review from zweatshirt April 20, 2026 18:30
@zweatshirt
Copy link
Copy Markdown
Contributor

For the review would you be able to rebase to get rid of my commits? Tough to read through what changes are yours and which were mine. Sorry about that Will

Copy link
Copy Markdown
Contributor

@zweatshirt zweatshirt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UI looks amazing! My only suggestion is to pull the MpdGoalMiscConstant API constants instead of hardcoding them. Could we do that quickly?

Comment on lines +85 to +87
workCompPercentage: 0.17,
attritionRate: 0.06,
creditCardFeeRate: 0.06,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These constants should be available on the MpdGoalMiscConstant GraphQL query, we can replace this to pull those directly instead of hardcoding them. They'll be changeable by admins. The credit card fee rate is .006

const attrition = subtotal * constants.attritionRate;
const creditCardFees = (subtotal + attrition) * constants.creditCardFeeRate;
const preAssessment = subtotal + attrition + creditCardFees;
const assessment = preAssessment / 0.88 - preAssessment;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember what this .88 is. Do we want to consider making this into a constant in MpdGoalMiscConstant as well?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes sorry this was before I updated.

@zweatshirt zweatshirt self-requested a review April 20, 2026 18:56
Copy link
Copy Markdown
Contributor

@zweatshirt zweatshirt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noticed you fixed the constants issue 💯

Comment on lines +94 to +99
describe('null/undefined status', () => {
it('excludes both workComp and benefits when status is null', () => {
const result = calculateOtherExpenses(noStatus(), defaultConstants);
expect(result.workComp).toBe(0);
expect(result.benefits).toBe(0);
});
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if we should actually make status non-nullable at some point... I don't think there should ever be a time this would be null in practice? I guess if the API pull from HCM fails. I know at some point we need to block 'Continue' on the Setup Step until the user has input all fields.

Comment on lines +167 to +174
expect(result.reimbursableExpenses).toBe(500);
expect(result.fourOThreeBContributions).toBeCloseTo(400);
expect(result.workComp).toBe(0);
expect(result.benefits).toBe(1500);
expect(result.subtotal).toBeCloseTo(7400);
expect(result.attrition).toBeCloseTo(444);
expect(result.creditCardFees).toBeCloseTo(470.64);
expect(result.assessment).toBeCloseTo(997.76, 1);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why we use toBeCloseTo in some instances and toBe in others? Is this possible rounding or truncation?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think toBeCloseTo is for anything derived from a potential Float

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why it would make a difference as everything is just an int in JS. I'd assume it's just for rounding what could be a very large integer

@wjames111 wjames111 merged commit 64f57c2 into main Apr 20, 2026
22 of 24 checks passed
@wjames111 wjames111 deleted the MPDX-9368 branch April 20, 2026 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

On Staging Will be merged to the staging branch by Github Actions Preview Environment Add this label to create an Amplify Preview

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants