Scan - No Amount, Merchant and Date field when splitting expense in 1:1 DM

[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): sdsduibhsiuhsih@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open 1:1 DM with other user.
3. Click + > Split expense > Scan.
4. Upload a receipt.

Expected Result:

Show more button should be present to reveal Amount, Merchant and Date field.

Actual Result:

Show more button is not shown when splitting scan expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7259899_1789435936171.4.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7259899

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/3c1c6058d1387c677436b9dc85afe79a92e78b636a95e9c9fa96fdd8f0154321

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this 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]

@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

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (App-side feature scope gap — not a regression)
Causing PR: #100426 - "[CFI] Show Merchant, Date, Amount Fields in the Scan flow" by @thelullabyy — refuted as the cause (High confidence it did not regress this flow)
Related Issues: #93854 (the issue #100426 implemented)

Recommendation: DEMOTE

Split + Scan never showed Amount / Merchant / Date (and therefore never showed a "Show more" button in a 1:1 DM), on staging and on production — #100426 deliberately scoped splits out of the new manual scan fields because StartSplitBill accepts no amount/merchant/date. Nothing in this deploy changed the split-scan confirmation, so this is a feature request for split, not a deploy blocker.

Labels: No changes. DeployBlockerCash left in place for a deployer/BugZero call on demotion; DeployBlocker was never applied, so nothing to remove.

📋 Detailed Analysis

Evidence

1. The pre-#100426 code already hid these fields for splits. On production (27adede):

const shouldShowSmartScanFields = !!transaction?.receipt?.isTestDriveReceipt || isMovingTransactionFromTrackExpense || requestType !== CONST.IOU.REQUEST_TYPE.SCAN;

For + > Split expense > Scan: requestType === SCAN, not a moved tracked expense, not a test-drive receipt → shouldShowSmartScanFields === false. Already false in production.

2. #100426 only added a disjunct that is false for splits. On staging (5b9770e):

const shouldShowSmartScanFields =
    !!transaction?.receipt?.isTestDriveReceipt || isMovingTransactionFromTrackExpense || requestType !== CONST.IOU.REQUEST_TYPE.SCAN || canEnterScanFieldsManually;

and canEnterScanFieldsManually explicitly excludes splits:

const canEnterScanFieldsManually =
    requestType === CONST.IOU.REQUEST_TYPE.SCAN &&
    !isMovingTransactionFromTrackExpense &&
    iouType !== CONST.IOU.TYPE.SPLIT &&
    !transaction?.receipt?.isTestReceipt &&
    !transaction?.receipt?.isTestDriveReceipt;

So false || false = false for split + scan: identical to production. The PR's own comment states the reason — splits are excluded because StartSplitBill takes no amount/merchant/date, and the details are filled in after SmartScan completes.

3. Nothing else in this deploy touched the show-more machinery. The three files that decide whether the "Show more" button renders are byte-identical between production and staging:

• src/components/MoneyRequestConfirmationListFooter/ConfirmationFieldList.tsx
• src/components/MoneyRequestConfirmationListFooter/fieldGroups/fieldVisibility.ts
• src/components/MoneyRequestConfirmationListFooter/hooks/useFooterDerivedFlags.ts

The only staging-vs-production delta in MoneyRequestConfirmationList.tsx is #100426's canEnterScanFieldsManually / partiallyManuallyFilledScanID / inline-error plumbing — none of which is reachable with canEnterScanFieldsManually === false. I checked every PR on the deploy checklist; none modify the split-scan field visibility path.

4. Production reproduction. Because the code path is byte-identical, + > Split expense > Scan in a 1:1 DM on production shows the same compact confirmation with no "Show more" button. The "N/A - new feature" note in the report refers to the non-split scan fields added by #100426, not to the split flow.

Verification

Files that control the reported symptom, all confirmed on staging 5b9770e:

File:line	Role
IOURequestStepConfirmation.tsx#L273-L278	canEnterScanFieldsManually — excludes iouType === SPLIT
IOURequestStepConfirmation.tsx#L1008-L1009	shouldShowSmartScanFields → false for split + scan
MoneyRequestConfirmationList.tsx#L295	shouldShowMerchant → false (split is not isTypeSend)
MoneyRequestConfirmationList.tsx#L347	shouldShowDate = shouldShowConfirmationDate(false, false) → false
MoneyRequestConfirmationList.tsx#L530	isCompactMode → true (scan, portrait)
fieldVisibility.ts#L130-L140	amount / merchant / date all false
fieldVisibility.ts#L149-L163	hasBelowShowMore() → false
ConfirmationFieldList.tsx#L120 + #L172	button gated on isCompactMode && shouldShowMoreButton

Root Cause

In a 1:1 DM split scan, every "below show more" field evaluates to false:

• amount = shouldShowSmartScanFields && shouldShowAmountField → false (split scan)
• merchant = (shouldShowSmartScanFields || isTypeSend) → false
• date = shouldShowConfirmationDate(false, false) → false
• categoryOptional / tagsOptional / tax → false (a DM has no policy)
• attendees → false (shouldShowAttendees returns false for iouType === 'split')
• toggles (billable/reimbursable) and report → false (not a policy expense chat)

hasBelowShowMore() therefore returns false, so ConfirmationFieldList renders the compact receipt + the "we'll automatically enter the expense details" hint and no "Show more" button — correctly, since there would be nothing behind it. This is working as designed for splits, not a regression.

Why a "fix" isn't a one-line flag flip

Dropping iouType !== CONST.IOU.TYPE.SPLIT from canEnterScanFieldsManually would surface the three fields, but StartSplitBillParams has no amount, merchant, or created param — the API only takes splits, receipt, comment, category, tag, currency, tax and the billable/reimbursable flags. Any user-entered values would be silently dropped and then overwritten by SmartScan, and the split amounts per participant could not be computed from them. Enabling this for splits needs a backend change to StartSplitBill first, so it should be a tracked follow-up feature, not a roll-forward on this deploy.

Suggested next step

Demote from DeployBlockerCash and, if manual entry for split scans is desired, open a feature issue covering the StartSplitBill API change plus the App-side flag. @thelullabyy @puneetlath @Pujan92 — please confirm the split exclusion in #100426 was intentional as documented in the code comment.