Scan - No Merchant, Date, Amount Fields when creating scan via native share

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.78-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #100426
Email or phone of affected tester (no customers): jsdoijnodsdisojo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Open device gallery.
2. Upload a receipt to Expensify app.
3. Select workspace chat.
4. Tap Show more.

Expected Result:

Merchant, Date, Amount Fields will be shown when creating scan via native share.

Actual Result:

Merchant, Date, Amount Fields are missing when creating scan via native share.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7259905_1789436243925.Screen_Recording_20260915_093551_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7259905

Issue Owner

Current Issue Owner: @thelullabyy

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/3bf50741a6d905515baeb4dada44adc4513bc940416bac857e1d66ab9613be4e

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #100426

[melvin-bot]

@puneetlath @Pujan92 you have been assigned to this deploy blocker because you reviewed the offending PR: #100426

[melvin-bot]

@thelullabyy you have been assigned to this deploy blocker because you authored the offending PR: #100426

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #100426 - "[CFI] Show Merchant, Date, Amount Fields in the Scan flow" by @thelullabyy (High confidence)
Related Issues: #101144, #101146, #101147, #101149, #101167 (all five are open deploy blockers on the same release attributed to #100426)

Recommendation: REVERT

PR #100426 rolled the new "enter Merchant / Date / Amount on a Scan" fields out to IOURequestStepConfirmation only, so the share-extension confirmation page (SubmitDetailsPage) and the split flow never got them, and it has produced six deploy blockers on this release — two of which (#101147, #101149) are hard blocks where the user cannot create a scan expense at all. Since the feature is brand new and not in production, reverting restores known-good behavior at zero user cost and lets the feature re-land once all entry points and the P2P/all-or-nothing validation are handled; a targeted fix is included below if the team prefers to roll forward.

Assigned: @thelullabyy (PR author), @puneetlath and @Pujan92 (approving reviewers) from the causing PR — already assigned, no change made.
Labels: No changes. DeployBlockerCash is kept (an App PR caused this and the issue is not reproducible in production). No DeployBlocker label was present, so nothing to remove.

📋 Detailed Analysis

Evidence

• The three fields are gated entirely by shouldShowSmartScanFields, which PR [CFI] Show Merchant, Date, Amount Fields in the Scan flow #100426 changed for the in-app Scan flow only. In IOURequestStepConfirmation.tsx#L1008-L1009 the PR added || canEnterScanFieldsManually, where canEnterScanFieldsManually is true for any non-split, non-test-receipt Scan being created.
• The native-share "submit expense" flow does not go through IOURequestStepConfirmation. The Submit tab routes to ROUTES.SHARE_SUBMIT_DETAILS → SubmitDetailsPage, which renders MoneyRequestConfirmationList itself with a hardcoded shouldShowSmartScanFields={false} and never passes the new canEnterScanFieldsManually prop (which defaults to false).
• "Show more" still appears in the share flow because compact mode is driven by isScanRequest and other optional fields (category, tags, tax, toggles, report) are present — so the user taps it and simply gets no Amount / Merchant / Date, exactly as reported.
• This is an incomplete rollout, not a regression. I fetched SubmitDetailsPage.tsx at [CFI] Show Merchant, Date, Amount Fields in the Scan flow #100426's base commit (1d7b7cd^) and shouldShowSmartScanFields={false} was already on line 696, unchanged by the PR. [CFI] Show Merchant, Date, Amount Fields in the Scan flow #100426 does not appear in this file's history. The share flow behaves exactly as it does in production; [CFI] Show Merchant, Date, Amount Fields in the Scan flow #100426 is what created the expectation and the inconsistency between entry points.
• Ruled out other PRs in the 9.4.78-0 checklist: [CFI] Show Merchant, Date, Amount Fields in the Scan flow #100426 is the only PR in this release that touches scan field visibility (git log on src/pages/Share and src/components/MoneyRequestConfirmationList.tsx shows no other release PR modifying SubmitDetailsPage or the visibility flags).

Verification

Affected files, and how each flag reaches the three fields:

Field	Gate	Location
Amount	amount: shouldShowSmartScanFields && shouldShowAmountField	fieldVisibility.ts#L130
Merchant	shouldShowMerchant = (shouldShowSmartScanFields || isTypeSend) && …	MoneyRequestConfirmationList.tsx#L295
Date	shouldShowConfirmationDate(shouldShowSmartScanFields, isDistanceRequest)	MoneyRequestUtils.ts#L245-L246

shouldShowAmountField is just !isPerDiemRequest, so shouldShowSmartScanFields is the only thing suppressing all three in the share flow. Confirmed that #100426's file list includes IOURequestStepConfirmation.tsx, MoneyRequestConfirmationList.tsx, fieldVisibility consumers and the three sections/*Field.tsx components, and does not include src/pages/Share/SubmitDetailsPage.tsx.

Root Cause

canEnterScanFieldsManually was introduced as an optional prop with a false default on MoneyRequestConfirmationList and threaded in from a single call site. MoneyRequestConfirmationList has three call sites (IOURequestStepConfirmation, SubmitDetailsPage, DynamicSplitBillDetailsPage); only the first was updated, so the share extension silently kept the pre-feature behavior with no type error to flag it. The same omission explains #101144 for the split surface.

Targeted fix, if rolling forward instead

Two changes in src/pages/Share/SubmitDetailsPage.tsx:

1. Replace shouldShowSmartScanFields={false} at L696 with shouldShowSmartScanFields plus canEnterScanFieldsManually. The share flow always seeds a Scan draft, is never a split and never carries a test receipt, so the equivalent of IOURequestStepConfirmation's predicate is unconditionally true here.
2. The share flow builds its receipt by hand and hardcodes receipt.state = SCAN_READY at L545, bypassing both ReceiptFileValidator and useExpenseSubmission.getCurrentReceiptState. Without mirroring that logic (hasAllManuallyEnteredScanFields(transaction) ? RECEIPT_STATE.OPEN : RECEIPT_STATE.SCAN_READY), anything the user types would be silently overwritten by SmartScan — a worse bug than the one reported.

clearMoneyRequestCreated only flips isCreatedSet, leaving created populated, so the existing created: transaction.created submit payload stays valid. Note this fixes only this issue; #101144, #101146, #101147, #101149 and #101167 each need their own fix, which is why revert is the recommendation.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-18 Update every call site when adding a behavior-gating prop
• Condition: When a PR adds an optional prop with a falsy default (prop = false) to a shared component and that prop gates whether UI renders or which validation runs, update or explicitly justify every existing call site of that component in the same PR; never rely on the default to "keep the old behavior" on surfaces the feature is meant to cover.
• Why: The default silently opts other entry points out with no type error, so the feature ships on one surface and is missing on the others — here the share extension and split confirmation kept the pre-feature behavior, producing this deploy blocker and Scan - No Amount, Merchant and Date field when splitting expense in 1:1 DM #101144.
• Search pattern: for each prop added as <name> = false (or = undefined) in a component's props destructuring in the diff, run grep -rn "<ComponentName" src/ and confirm every JSX call site is either updated in the diff or deliberately excluded with a comment.
• Offending code (❌): SubmitDetailsPage.tsx#L696 — call site left with the default while MoneyRequestConfirmationList.tsx#L188 introduced canEnterScanFieldsManually = false
• Fix (✅): IOURequestStepConfirmation.tsx#L1008-L1009 shows the shape the other call sites needed

The full rule file, with the ❌/✅ code inline in App's app-coding-standards format, would go in Expensify/App itself (.claude/skills/app-coding-standards/rules/). If it's worth adding, a maintainer can open it there as a draft PR. No existing CONSISTENCY-* rule covers this (CONSISTENCY-4 is about unused props, CONSISTENCY-3 about duplication).