[HOLD for payment 2025-01-13] Tax rate - System message does not show the correct tax rate when category has tax rate

[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.78-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Windows 11
App Component: Money Requests

Action Performed:

Precondition:

• Rules and Taxes are enabled.
• There are three tax rates - A, B and C.
• Tax rate A belongs to Workspace currency default.
• Tax rate B belongs to Foreign currency default.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Categories.
3. Click Advertising category.
4. Click Default tax rate.
5. Select Tax rate C.
6. Go to workspace chat.
7. Submit an expense in foreign currency, and with "Advertising" category from Step 3.
8. Go to transaction thread.
9. Click Category.
10. Click on Advertising category to unselect it.
11. Note that tax field shows Tax rate B, but the system message shows "changed the tax rate to Tax rate A".
12. Click Category.
13. Select any other category except Advertising.
14. Note that tax field shows Tax rate B, but the system message shows "changed the tax rate to Tax rate A".

Expected Result:

In Step 11 and 14, the system message should correctly reflect the current state of selected tax rate.

Actual Result:

In Step 11 and 14, the system message shows that the tax rate is changed to Tax rate A, when the tax field shows that Tax rate B is selected.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6701713_1735034366618.bandicam_2024-12-24_17-54-15-171.1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @sakluger

[melvin-bot]

Triggered auto assignment to @grgia (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

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

[melvin-bot]

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

[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.

[sakluger]

Discussing in Slack.

[nkdengineer]

Proposal

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

In Step 11 and 14, the system message shows that the tax rate is changed to Tax rate A, when the tax field shows that Tax rate B is selected.

What is the root cause of that problem?

We always pass the defaultTaxRate param as policy?.taxRates?.defaultExternalID then the system message is updated wrongly

App/src/libs/TransactionUtils/index.ts

Line 1262 in 12e0941

const categoryTaxCode = getCategoryDefaultTaxRate(taxRules, category, policy?.taxRates?.defaultExternalID);

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

We should use getDefaultTaxCode function that already handled the case foreign currency to get the correct default tax rate.

const categoryTaxCode = getCategoryDefaultTaxRate(taxRules, category, getDefaultTaxCode(policy, transaction, getCurrency(transaction)));

App/src/libs/TransactionUtils/index.ts

Line 1262 in 12e0941

const categoryTaxCode = getCategoryDefaultTaxRate(taxRules, category, policy?.taxRates?.defaultExternalID);

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

We need another test case for getCategoryTaxCodeAndAmount when the transaction currency is different with the policy currency and verify that the default tax rate will be the Foreign tax rate if it exists.

What alternative solutions did you explore? (Optional)

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.

[bernhardoj]

I'm fixing it here

[jasperhuangg]

The PR fixes this issue mostly in the front-end, but we still need a back-end PR to fully solve this issue, so I'm adding the Web blocker label.

[sakluger]

I'm going to add reviewing for now since the front-end PR is merged and awaiting deploy. @jasperhuangg what's the plan for the backend fix?

[jasperhuangg]

cc @MonilBhavsar I remember it was mentioned you would work on the back-end fix, correct?

[MonilBhavsar]

This one does not need a backend change. #54579 should fix it!

[jasperhuangg]

@MonilBhavsar #54579 (comment) what about this comment? Or is that going to be a separate concern handled elsewhere?

[bernhardoj]

@jasperhuangg I think #54513 is the only one that needs a BE fix. This issue is fully FE.

[sakluger]

@bernhardoj, just to confirm, no additional payment is required for this issue, right?

[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.80-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Don't apply the category tax rules for distance request #54579

If no regressions arise, payment will be issued on 2025-01-13. 🎊

[melvin-bot]

@grgia @sakluger @grgia The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[bernhardoj]

@sakluger yes, no payment here.

[sakluger]

Perfect, thank you for confirming!