Scan IOU - There is a "Enter an amount." error message on receiver side

[izarutskaya]

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: 1.4.80-1
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): gocemate+a171@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. As User A Create a scan money request with User B
2. As User B while scanning change the merchant of the money request
3. User B interact with the notification
4. Take a look at Amount section

Expected Result:

There should be no "Enter an amount." error message on receiver side

Actual Result:

There is a "Enter an amount." error message on receiver side. This option is irresponsible

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Screenshots/Videos

Bug6504736_1717747635354.Recording__3148.mp4

View all open jobs on GitHub

[melvin-bot]

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

[izarutskaya]

We think this issue might be related to the #vip-vsb

[devguest07]

Proposal

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

When report is scanning and we edit merchant, an error appear on amount

What is the root cause of that problem?

On MoneyRequestView we check errors on getErrorForField

App/src/components/ReportActionItem/MoneyRequestView.tsx

this callback re-render and check again when any on the following vars change

[transactionAmount, isSettled, isCancelled, isPolicyExpenseChat, isEmptyMerchant, transactionDate, hasErrors, canUseViolations, hasViolations, translate, getViolationsForField],

https://github.com/Expensify/App/blob/b94ccf3340bcaf0715407a7103ee198fd98a2d69/src/components/ReportActionItem/MoneyRequestView.tsx#L274C74-L274C89

and in this issue, isEmptyMerchant change then the function will check the error for amount

https://github.com/Expensify/App/blob/b94ccf3340bcaf0715407a7103ee198fd98a2d69/src/components/ReportActionItem/MoneyRequestView.tsx#L245C17-L248

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

Error for amount should not be checked if the report is scanning

amount: {
  isError:  isReceiptBeingScanned  &&  transactionAmount  ===  0,
  translationPath:  'common.error.enterAmount',
},

What alternative solutions did you explore?

[melvin-bot]

@anmurali Whoops! This issue is 2 days overdue. Let's get this updated quick!

[anmurali]

What happens here is the scan continues and eventually completes and overwrites the user's input.
While it is still scanning, you have manually entered the merchant name, date defaults to current date and what's left is amount, which is shown with an RBR.

On Classic, this works a little differently. You have to abort the job in order to manually enter. And if you do, then you have to enter all 3 fields, date, merchant name and amount.

I think we want a fix that mimics Classic behavior cause if we allow you to manually enter but keep scanning, we will just end up overwriting the details. Or, we have to abort just that specific field's child SS job but that's a more complex fix as the parent scan job expects results from each of the child jobs.

Thoughts on how to handle this? @kevinksullivan @puneetlath @JmillsExpensify @trjExpensify

[trjExpensify]

On NewDot, entering any of the merchant, date or amount fields manually stops the scanning process. So there's a bug somewhere if that's not happening. If I was to guess, it's probably something to do with the bug report stating that userB took the action and not the person who scanned the receipt.

As User A Create a scan money request with User B
As User B while scanning change the merchant of the money request

@Gonals has some good experience with this logic, having worked on the implementation of scan receipts.

[anmurali]

@trjExpensify - when I tested it though, I scanned a receipt and then manually entered the merchant name. So it can't be cause a user that is NOT the scanner changed it manually. It continued to scan even in the case where I, as the scanner, added merchant name manually.

[trjExpensify]

@trjExpensify - when I tested it though, I scanned a receipt and then manually entered the merchant name. So it can't be cause a user that is NOT the scanner changed it manually. It continued to scan even in the case where I, as the scanner, added merchant name manually.

Got it, so still a bug then. We shouldn't override your manually entered merchant name either, that should "stop" the scanning process and you should see errors . Though on paid plans it continues in the background for Concierge DoubleCheck.

In this case, what I'm seeing is strange insofar as;

1. The fields scanning appear as Scanning... as expected
2. I manually enter a merchant it stops the scanning process for me and asks me to manually enter the amount field manually, as expected.
3. Those fields revert to Scanning..., not expected.
4. Once SS'ing completes for DoubleCheck, my manually entered merchant and amount values are added back.

So the bug I see there is that we're somewhere reverting to Scanning... when we shouldn't be after step #2.

2024-06-19_14-19-44.mp4

[melvin-bot]

@anmurali Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@anmurali this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@anmurali Still overdue 6 days?! Let's take care of this!

[anmurali]

[melvin-bot]

@anmurali Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@anmurali Still overdue 6 days?! Let's take care of this!

[melvin-bot]

@anmurali Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[anmurali]

This is intended behavior.
If you interrupt the scan to manually add one of the details, it aborts the scan itself. Then you have to manually add all of the required details or you will see an RBR. Note: Date is defaulted to the date the request is created unless the scan produces a different result.