[Due for payment 2025-04-23] [Payment due 25-04-22][$250] Send invoice flow becomes create expense flow

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.1.22-4
Reproducible in staging?: y
Reproducible in production?: y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @shawnborton
Slack conversation (hyperlinked to channel name): #expensify - bugs

Action Performed:

1. Enable 'Send invoice' in a workspace
2. Open FAB select option 'Send invoice'
3. Enter amount click next
4. Select a user and continue

Expected Result:

Should remain in Send invoice flow

Actual Result:

Changed to create expense flow

Workaround:

unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Recording.1104.mp4

CleanShot.2025-04-02.at.11.59.56.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021908026175052487852
• Upwork Job ID: 1908026175052487852
• Last Price Increase: 2025-04-04
• Automatic offers:
• FitseTLT | Contributor | 106819579

Issue Owner

Current Issue Owner: @stephanieelliott

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[FitseTLT]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-02 22:26:07 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Send invoice flow becomes create expense flow

What is the root cause of that problem?

When send invoice from global menu isFromGlobalCreate is true so here

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 210 to 212 in c217111

	const isCurrentReportID = transaction?.isFromGlobalCreate
	? transaction?.participants?.at(0)?.reportID === reportID || (!transaction?.participants?.at(0)?.reportID && transaction?.reportID === reportID)
	: transaction?.reportID === reportID;

isCurrentReportID will be false because the first participant for invoice is not equal to reportID from route because we don't set the first participant of an invoice flow if the participant is not invoice room

App/src/pages/iou/request/step/IOURequestStepParticipants.tsx

Lines 169 to 172 in 3f7933f

	// When multiple participants are selected, the reportID is generated at the end of the confirmation step.
	// So we are resetting selectedReportID ref to the reportID coming from params.
	if (val.length !== 1 && !isInvoice) {
	selectedReportID.current = reportID;

so we are navigated to create expense flow here

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 219 to 224 in c217111

	startMoneyRequest(
	CONST.IOU.TYPE.CREATE,
	// When starting to create an expense from the global FAB, there is not an existing report yet. A random optimistic reportID is generated and used
	// for all of the routes in the creation flow.
	generateReportID(),
	);

this isCurrentReportID condition is implemented here to solve deeplink issue for confirmation page but it didn't correctly take invoices into consideration

What changes do you think we should make in order to solve the problem?

We need to compare transaction?.reportID and reportID for invoices so

const isCurrentReportID =
            transaction?.isFromGlobalCreate && iouType !== CONST.IOU.TYPE.INVOICE
                ? transaction?.participants?.at(0)?.reportID === reportID || (!transaction?.participants?.at(0)?.reportID && transaction?.reportID === reportID)
                : transaction?.reportID === reportID;

We can also make an exception same as we do for isMovingTransactionFromTrackExpense because the original problem here is not reproducible for invoices

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 215 to 216 in c217111

	if (transaction?.transactionID && (!transaction?.isFromGlobalCreate || !isEmptyObject(transaction?.participants)) && (isCurrentReportID || isMovingTransactionFromTrackExpense)) {
	return;

if (
            transaction?.transactionID &&
            (!transaction?.isFromGlobalCreate || !isEmptyObject(transaction?.participants)) &&
            (isCurrentReportID || isMovingTransactionFromTrackExpense || iouType === CONST.IOU.TYPE.INVOICE)
        ) {
            return;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can render IOURequestStepConfirmation with iouType invoice and assert that startMoneyRequest function will not be called.

What alternative solutions did you explore? (Optional)

[ChavdaSachin]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When user initiates send invoice flow and then selects a DM or a workspace which does not have invoices enabled then send invoice flow converts to create expense flow.

What is the root cause of that problem?

Participants which could be selected on MoneyRequestParticipantsSelector page are not filtered properly and hence non intended participant could be selected and hence this issue arises.

What changes do you think we should make in order to solve the problem?

So to solve this problem we should improve our filter process here

Option 1) Create a new dedicated filtering function to show only those workspace chat which has invoices enabled.

Option 2) Add a new parameter iouType to filterAndOrderOptions function here and modify function body to return only intended options ie. invoices enabled workspaces.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

optionally create an automated test to check only invoice enabled workspaces are visible on MoneyRequestParticipantsSelector page when user is in send invoice flow.

What alternative solutions did you explore? (Optional)

Alternatively we could create a simple error page which could state "ask your admin to enable invoices" in case of user selects a workspace without invoice enabled and states "invoices could be only sent to workspace chats" in case of any DM selection.
ofc message strings could be decided with help of design team.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[FitseTLT]

@stephanieelliott I think this is a major flow that should be fixed ASAP. Users now can't send invoices from global FAB.

cc @shawnborton WDYT

[shawnborton]

I don't think many users are using invoicing on NewDot right now, so I don't think we need to be in a super big rush, but let's definitely fix it.

[stephanieelliott]

Yeah I can confirm very few customers are using invoicing in ND. Putting the labels on now so we can get it fixed!

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021908026175052487852

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @jjcoffee (External)