[Tracking] Create consistency between scanning receipts and pending transactions, and update how we handle card transaction reporting on instant submit/submit + close

[kevinksullivan]

Problem

Context here

Problem 1

We decided in this thread that it is weird to treat pending transactions and scanning receipts differently. For example, we show the former immediately, because we figure we shouldn't hide transaction info from admins if we have it. But we decided to introduce a "whisper" to hide scanning receipts.

Problem 2

When a company has instant submit enabled, and there are no approvals configured (this is the only option on a Free workspace, but also a possibility on paid workspaces), there is really no action to take on a card transaction. And yet, we co-mingle these expenses with cash expenses, which leads to some odd cases we must handle.

Mainly, it's the fact that have to deal with the fact that a report can contain a batch of non-reimbursable expenses with no action to take, and yet we need to show some action to "end" the report, and stop the batching. That's where we came up with Mark as done, which we planned to show in the case where all expenses on a report are non-reimbursable. However, this action doesn't really "do" anything from the user's perspective, it's more of a technical detail for how we solve for the fact that we batch card transactions with no clear CTA. So overall this is a bit of an odd experience, and it's not clear what "done" means.

Solution(s)

1. Show pending transactions and scanning receipts as system messages in the workspace chat. Then, once the transaction is posted, or the scanning receipt is finished scanning, let's add them to the relevant report.

• Note: these system messages should not create a notification in the workspace chat.
• Note: we'll use the lighter background and a new icon to indicate these expenses are still being finalized.

2. Update our reporting logic of card transactions, so that when instant submit and submit and close settings are enabled, we separate card transactions onto their own reports, and contain them to one transaction per report. Additionally, once the card transaction posts, we'll report the transaction on a report in the closed state. This avoids any batching of transactions that ultimately have no action to take.

3. Remove the Mark as done button, or any button for that matter, on reports containing only a non-reimbursable expense in the Closed state. This action is unnecessary given there is no real action to take, and we don't need to worry about transactions piling up one report.

[melvin-bot]

Triggered auto assignment to @muttmuure (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[quinthar]

Update our reporting logic of card transactions, so that when instant submit and submit and close settings are enabled, we separate card transactions onto their own reports, and contain them to one transaction per report. Additionally, once the card transaction posts, we'll report the transaction on a report in the closed state. This avoids any batching of transactions that ultimately have no action to take.

I agree with this, but I'd like to clarify that this isn't special card logic. Rather, whenever you submit any non-reimbursable expense (card, receipt, manual, or distance) on any workspace with Submit & Close, it should be kept on its own report. So a corporate card does this not because it's a corporate card, but because it's non-reimbursable. Does that make sense?

[luacmartins]

Show pending transactions and scanning receipts as system messages in the workspace chat

Are these system messages whispers to the user who created them or are we showing that to admins too?

Then, once the transaction is posted, or the scanning receipt is finished scanning, let's add them to the relevant report.

Does that mean that we initially create these transactions unreported and then later on report them?

[grgia]

reports containing only a non-reimbursable expense in the Closed state.

So both reports and transactions themselves have a closed state?

[melvin-bot]

@kevinksullivan Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

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

[kevinksullivan]

Sorry I missed getting back to this.

Are these system messages whispers to the user who created them or are we showing that to admins too?

No, they're visible to all parties.

Does that mean that we initially create these transactions unreported and then later on report them?

Correct

So both reports and transactions themselves have a closed state?

No, just the reports. Sorry, when I say "closed state" there, I mean the report state.

[kevinksullivan]

Next step - gotta write a pre-design for this.

[kevinksullivan]

Prioritizing a pre-design this week.

[trjExpensify]

@kevinksullivan do you need to close this in favour of https://github.com/Expensify/Expensify/issues/340874?

[kevinksullivan]

yiz