[HOLD for payment 2024-11-01] Invoices - Receipt appears on invoice confirmation page if receipt is added from track expense

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.45-2
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Send invoices.
3. Enter amount and select a receiver.
4. Note that there is no receipt option on the confirmation page.
5. Click back button.
6. Click Just track it (don’t submit it).
7. Add a receipt from the 3-dot menu.
8. Click back button.
9. Select a receiver.

Expected Result:

Receipt will not appear on the invoice confirmation page because invoice does not support receipt (evident from Step 4).

Actual Result:

Receipt appears on invoice confirmation page if receipt is added from track expense first.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6625725_1728157302093.20241006_033817.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

Triggered auto assignment to @trjExpensify (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.

[IuliiaHerets]

We think that this bug might be related to #vip-bills

[IuliiaHerets]

@trjExpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[Nodebrute]

Edited by proposal-police: This proposal was edited at 2024-10-06 17:29:32 UTC.

Proposal

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

Receipt appears on invoice confirmation page if receipt is added from track expense

What is the root cause of that problem?

When we add the receipt it gets added to this transaction and then we move back to send invoice we can see the receipt.

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

Line 624 in 99f280b

transaction={transaction}

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

You can see that if we add categories during the invoice flow and then go back to start the track expense flow, the categories will still be present in the transaction object. However, we don’t see the categories on the screen because we hide them using this check.

App/src/components/MoneyRequestConfirmationList.tsx

Line 261 in 99f280b

const shouldShowCategories = (isPolicyExpenseChat || isTypeInvoice) && (!!iouCategory || OptionsListUtils.hasEnabledOptions(Object.values(policyCategories ?? {})));

The same we can do with receipts. We can add another check here !isTypeInvoice

App/src/components/MoneyRequestConfirmationListFooter.tsx

Line 636 in 99f280b

{!isDistanceRequest &&

What alternative solutions did you explore? (Optional)

We can pass the shouldDisplayReceipt={iouType !== CONST.IOU.TYPE.INVOICE}

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

Line 623 in 99f280b

<MoneyRequestConfirmationList

and then we can use it here to hide the receipt

App/src/components/MoneyRequestConfirmationListFooter.tsx

Line 636 in 99f280b

{!isDistanceRequest &&

Alternative 2
Or we can use setMoneyRequestReceipt to clear the receipt details from transaction object. We can do something like in IOURequestStepConfirmation.tsx

pseudo-code

   useEffect(() => {
        console.log(transaction)
        if (iouType !== CONST.IOU.TYPE.INVOICE && !transaction?.receipt) {
            return;
        }
       IOU.setMoneyRequestReceipt(transactionID, '','',true);

    }, [transactionID, iouType]);

Optional: We can also add !isTypeInvoice check too to hide receipt.
Optional 2: we can also use null instead of ''

[Nodebrute]

Proposal updated
Added alternative solution 2

[cretadn22]

Proposal

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

Receipt appears on invoice confirmation page if receipt is added from track expense

What is the root cause of that problem?

In this case, we have two separate flows: "Send Invoice" and "Track Expense." However, both flows save their data in the same place, "transactionsDraft_1." This results in the receipt from the "Track Expense" flow also being added to the "Send Invoice" flow

A similar issue occurs with the category field, which only exists in the "Send Invoice" flow. If a value is added to category and then "Track Expense" is executed, the category field still appears in the payload of the "Track Expense" API

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

"transactionsDraft_1" can be used to share common information like description, amount, and merchant,... as these exist in both flows. However, if we continue saving receipt information and the category field in "transactionsDraft_1" as we do now, we will need to make some adjustments:

• For the "Track Expense" flow: We need to hide the category field on the confirmation page and remove it from the API payload.
• For the "Send Invoice" flow: We need to hide the receipt information on the confirmation page and remove it from the API payload.

What alternative solutions did you explore? (Optional)

We can save the "Track Expense" information to a new ONYX state (transactionDraft_sideFlow), keeping the data for both flows completely separate. However, the downside of this approach is that any shared information between the two flows will not be available in both.

[trjExpensify]

I think we want to put this one in #f1 as it's a bug from there. @grgia, who's working on this with you? I don't think we should show the "just track it" option in the Send invoice flow. CC: @anmurali

[trjExpensify]

I'll hold off on Help wanted for now, as we might want to route this back to whoever is working on that project as a regression.

[trjExpensify]

Bumped in thread: https://expensify.slack.com/archives/C07HPDRELLD/p1728580440064929?thread_ts=1728363084.092579&cid=C07HPDRELLD

Doesn't look like @fabioh8010 has access to that channel though, so tagging you here!

[fabioh8010]

Hi @trjExpensify Could you assign me here so I can work on the fix? Thanks!

[trjExpensify]

Done!

[grgia]

@fabioh8010 are you able to prioritize this one this week? Thanks!

[fabioh8010]

Created a Draft PR -> #50732

[trjExpensify]

Excellent! When do you think you can have it in review?

[fabioh8010]

I asked for Georgia's feedback in DM but no answer yet, so I think I will just proceed into opening the PR today with screenshots / test videos and tag her again

[trjExpensify]

That would be great, thanks!

[fabioh8010]

PR was opened to review.

[allgandalf]

I was assigned to the ^ PR, does that require C+ review ?

[allgandalf]

bump on ^ @grgia

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.53-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix shouldDisplayTrackExpenseButton logic #50732

If no regressions arise, payment will be issued on 2024-11-01. 🎊

For reference, here are some details about the assignees on this issue:

• @fabioh8010 does not require payment (Contractor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@grgia] The PR that introduced the bug has been identified. Link to the PR:
• [@grgia] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@grgia] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@fabioh8010] Determine if we should create a regression test for this bug.
• [@fabioh8010] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@trjExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: