[No QA] Docs updates for E/A#101080 clarify distance rate behavior when moving expenses between workspaces

[MelvinBot]

Explanation of Change

Help site follow-up to [No QA] Add getRateForPolicyChange to select a distance rate when the policy changes. Reviewing that PR surfaced that the FAQ in Distance-Expenses.md describes distance-rate behavior that the app does not have — and has not had for some time. These inaccuracies are pre-existing and are not caused by that PR, which added an unwired helper.

Two corrections, both verified against code on main:

1. "What happens if a Distance expense is moved to a different Workspace?" was wrong for expense-level moves.

The article said a moved expense always "keeps its original unit and rate." That is only true for one of the two move flows:

• Moving individual expenses to a report on another workspace reprices them. getChangeTransactionsReportOnyxData auto-selects the destination policy's default rate when the current rate is missing, absent from the destination, or disabled — then converts the unit and quantity and recomputes amount, merchant, and currency (src/libs/actions/Transaction.ts:1267-1366). A committed test asserts exactly this: a 10-mile USD expense adopts the destination's GBP rate (tests/actions/TransactionTest.ts:453-540).
• Moving a whole report keeps the rate. changeReportPolicy / moveIOUReportToPolicy never touch customUnitRateID — there are no rate or DistanceRequestUtils references anywhere in src/libs/actions/Report/.

The rewritten answer separates the two flows and keeps the Rate not valid for this workspace violation on the case that actually produces it client-side: a destination workspace with no enabled distance rates (src/libs/Violations/ViolationsUtils.ts:644-682).

2. "Can I update the Distance expense unit or rate?" contradicted itself.

It claimed "It is not possible to adjust the distance rate or unit at the expense level," while the next FAQ answer told users to select a valid rate on the expense. The rate is editable: DISTANCE_RATE is editable on expense reports and unreported distance expenses (src/libs/ReportUtils.ts:5461-5464), and the Rate row renders interactive (src/components/ReportActionItem/MoneyRequestView.tsx:1041-1045). Only the unit is admin-controlled. The answer now says that.

I also added move- and rate-editing keywords to the front matter for retrieval, per section 6 of the authoring spec.

Scope note. This documents behavior shipping on main today. When F3 and F4 of [Tracking] Auto-select distance rate on workspace change (frontend) wire up getRateForPolicyChange, the expense-level paragraph will need a further update, because selection becomes date-aware and prefers an equivalent rate before falling back to the default.

Guidelines applied

• docs/HELP_AUTHORING_GUIDELINES.md — no new headings added, so the existing task-based ## FAQ headings and the single # title are untouched. Added keywords per section 6.
• docs/HELPSITE_NAMING_CONVENTIONS.md — Rate is bolded and unquoted, matching the UI label exactly.
• docs/TEMPLATE.md — no structural change; this edits FAQ answers in an existing article rather than creating one.

UI label verification. The live-UI check could not run: the browser session handed to this run was dead (0 accessibility nodes, no network activity), which is an infrastructure failure rather than an app bug. I verified every label against src/languages/en.ts instead, which is the source of the rendered strings:

Label used	Source	Rendered at
Rate	en.ts:382 (common.rate)	MoneyRequestView.tsx:1041
Rate not valid for this workspace	en.ts:10414 (violations.customUnitOutOfPolicy)	MoneyRequestView.tsx:1222

Please re-confirm the Rate row label in the product when you review, since I could not see it rendered.

Fixed Issues

$ #100557
PROPOSAL:

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review".
// Note: this PR changes help site markdown only, so there is no app behavior to test. What needs confirming is that the two rewritten FAQ answers match what the product actually does — see the checks below.

Suggested verification:

1. Create a Distance expense on a workspace, then move that single expense to a report on a different workspace whose rates differ. Verify the rate, unit, distance, amount, and currency change to match the destination workspace.
2. Repeat step 1 against a destination workspace with no enabled distance rates. Verify the expense keeps its rate and shows the Rate not valid for this workspace violation.
3. Move an entire report to a different workspace. Verify the expenses keep their original unit and rate.
4. Open a Distance expense on an expense report and verify the Rate row is selectable.

• Verify that no errors appear in the JS console

Offline tests

Not applicable — this PR changes help site markdown only and has no runtime or network behavior.

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review", or add "[No QA]" to the PR title.
// Note: help site markdown only — no app surface changes, so this is a likely "[No QA]" candidate.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

AI Tests

Test	Result
npm run spell-changed (cspell — CI merge gate)	✅ 1 file checked, 0 issues
./.github/scripts/createDocsRoutes.sh	✅ docs/routes.yml already up to date
npm run lint / npm run typecheck / npm test	⚠️ not run — no TS, TSX, or JS files are touched by this PR
npm run storybook -- --smoke-test --ci	⚠️ not run — no components or stories are touched by this PR
Live UI label verification	❌ not possible — the browser session for this run was dead (0 accessibility nodes, no network activity). Labels were verified against src/languages/en.ts instead; see the collapsed section above

Screenshots/Videos

This PR changes help site markdown only, so there is no UI change to capture.

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

---

@truph01, please review the files changed and confirm they reflect the current behavior. Then post a new comment saying @MelvinBot mark this PR as ready for review.

[MelvinBot]

I created this PR from an upstream branch since I don't have push access to your fork.

To take ownership of this branch and be able to push updates, run:

git remote add upstream https://github.com/Expensify/App.git
git fetch upstream claude-docsDistanceRateWorkspaceMove
git checkout -b claude-docsDistanceRateWorkspaceMove upstream/claude-docsDistanceRateWorkspaceMove
git push -u origin claude-docsDistanceRateWorkspaceMove

Then you can close this PR and open a new one from your fork.

[OSBotify]

A preview of your ExpensifyHelp changes have been deployed to https://d311299e.helpdot.pages.dev ⚡️

Updated articles:

• articles/new-expensify/reports-and-expenses/Distance-Expenses

[truph01]

@MelvinBot Mark this pR as ready

[melvin-bot]

Concierge reviewer checklist:

• I have verified the accuracy of the article
  • The article is within a hub that makes sense, and the navigation is correct
  • All processes, screenshots, and examples align with current product behavior.
  • All links within the doc have been verified for correct destination and functionality.
• I have verified the readability of the article
  • The article's language is clear, concise, and free of jargon.
  • The grammar, spelling, and punctuation are correct.
  • The article contains at least one image, or that an image is not necessary
• I have verified the formatting of the article
  • The article has consistent formatting (headings, bullet points, etc.) with other HelpDot articles and that aligns with the HelpDot formatting standards.
  • The article has proper text spacing and breaks for readability.
• I have verified the article has the appropriate tone and style
  • The article's tone is professional, friendly, and suitable for the target audience.
  • The article's tone, terminology, and voice are consistent throughout.
• I have verified the overall quality of the article
  • The article is not missing any information, nor does it contain redundant information.
  • The article fully addresses user needs.
• I have verified that all requested improvements have been addressed

For more detailed instructions on completing this checklist, see How do I review a HelpDot PR as a Concierge Team member?

cc @brianlee-expensify

[MelvinBot]

🤖 Done — this PR is now ready for review.

Two things still need your edit before a reviewer signs off:

1. The Tests and QA Steps sections still contain the // TODO: **The human co-author** must fill out... placeholder lines. I left those for you on purpose — I don't fill out the human checklist sections. The title already carries [No QA], so the QA section can just say so.
2. The PR Author Checklist is mostly unchecked.

Checks are green except Check independent approval, which fails because the PR has no independent reviewer yet — that clears once someone reviews.

---

view run

[melvin-bot]

@truph01 @brianlee-expensify One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[github-actions]

HelpDot Documentation Review

Overall Assessment
This PR corrects two inaccurate FAQ answers in Distance-Expenses.md and expands the frontmatter keywords. It fixes a self-contradiction about whether the distance rate is editable and splits the "moved to a different Workspace" answer into two distinct flows (individual expense move vs. whole report move). The edits are well-scoped, factually grounded in the code, and limited to FAQ answer bodies, with no headings or structure changed.

Scores Summary

• Readability: 8/10 - Clear, well-sequenced explanations. The two-flow split with bold lead-ins is scannable and easy to follow. Minor deduction for slightly long compound sentences in the individual-move paragraph and for the curly apostrophes introduced rather than the straight ASCII apostrophes used elsewhere.
• AI Readiness: 9/10 - Strong retrieval alignment. Newly added keywords (change distance rate, move expense to another workspace, rate not valid for this workspace, distance rate violation) map directly to real search intent per Section 6. internalScope and the existing task-based FAQ headings are untouched and remain compliant. Feature and label names match the UI.
• Style Compliance: 8/10 - Rate is correctly bolded, unquoted, and matches the UI label exactly per the naming conventions. "Workspace" is capitalized consistently. The violation string Rate not valid for this workspace is wrapped in quotation marks; as a system violation message rather than a button or tab this is acceptable, though bold or inline code would be more consistent with the deterministic-writing guidance.

Key Findings

• Positive: The change resolves a genuine contradiction between two adjacent FAQ answers. The rate is now correctly described as editable at the expense level while the unit remains admin-controlled.
• Positive: Splitting the move behavior into individual-expense vs. whole-report flows is accurate to the code and gives users a deterministic answer for each case.
• Positive: Keyword additions follow Section 6 retrieval guidance and improve findability without diluting scope.
• Minor: Curly apostrophes were introduced; prefer straight apostrophes to match the rest of the file.
• Minor: The violation-message quoting style could be standardized for consistency.

Recommendations

• Normalize the curly apostrophes to straight apostrophes for consistency with the existing article text.
• Consider a light copy edit of the individual-move paragraph to break the longest sentence into two for improved scannability.
• Optional: standardize how the Rate not valid for this workspace violation string is formatted throughout the answer.

Files Reviewed

• docs/articles/new-expensify/reports-and-expenses/Distance-Expenses.md - Two FAQ answers rewritten for accuracy, keywords expanded. Compliant with governance; only minor stylistic polish suggested.

Note: Detailed line-by-line feedback has been provided as inline comments.