[HOLD for payment 2024-12-07] [$250] Distance - Rate on confirmation page shows 3 decimal value for a 4-digit decimal value rate

[lanitochka17]

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.41-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
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 workspace settings > Distance rates
3. Click on any distance rate
4. Change the distance rate to 4-digit decimal value (non-zero) and save it
5. Go to workspace chat
6. Click + > Submit expense > Distance
7. Enter waypoints and proceed to confirmation page
8. Click Rate
9. Select the 4-digit decimal value rate in Step 4
10. Note that the rate list only shows 3 decimal value instead of 4
11. Submit the distance expense
12. Go to transaction thread and open the receipt
13. Note that the expense preview and distance receipt shows the complete rate which is 4-digit decimal value

Expected Result:

In Step 10, the rate list should show the complete decimal value (eg, 1.2345)

Actual Result:

In Step 10, the rate list only shows 3 decimal value (eg, 1.234)
In Step 13, the expense preview and distance receipt shows 4 decimal value which is the complete rate (eg, 1.2345)
The rate format is not consistent in the rate list and distance receipt

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

Add any screenshot/video evidence

Bug6618594_1727539618646.20240929_000027.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021841311378926667676
• Upwork Job ID: 1841311378926667676
• Last Price Increase: 2024-10-09
• Automatic offers:
• allgandalf | Contributor | 104470034

Issue Owner

Current Issue Owner: @kadiealexander / @kadiealexander

Issue Owner

Current Issue Owner: @puneetlath / @kadiealexander

[melvin-bot]

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

[lanitochka17]

@kadiealexander 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

[NJ-2020]

Proposal

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

Distance - Rate on confirmation page shows 3 decimal value for a 4-digit decimal value rate

What is the root cause of that problem?

Right here the Rate Decimal for displaying Rate is 3 which is wrong

App/src/CONST.ts

Line 2402 in 0e3b82c

RATE_DECIMALS: 3,

And same here

App/src/libs/PolicyUtils.ts

Line 148 in decf515

const fixedDecimalPoints = decimalPart.length > 2 && !decimalPart.endsWith('0') ? 3 : 2;

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

We should change it to 4

Result

Screen.Recording.2024-09-30.at.07.00.01.mov

What alternative solutions did you explore? (Optional)

[abzokhattab]

i think this is caused by this PR

[thelullabyy]

Proposal

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

We have an inconsistency in the number of decimal places for the distance rate.

What is the root cause of that problem?

In this PR #49773, we decided to always display 4 decimals for all currencies. But we haven't updated this function getRateDisplayValue function.

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

Update to display 4 decimals

App/src/libs/PolicyUtils.ts

Line 149 in 69483ff

return Number(numValue).toFixed(fixedDecimalPoints).toString().replace('.', toLocaleDigit('.'));

        return Number(numValue).toFixed(CONST.MAX_TAX_RATE_DECIMAL_PLACES).toString().replace('.', toLocaleDigit('.'));

App/src/libs/PolicyUtils.ts

Line 122 in 69483ff

return numValue.toFixed(CONST.CUSTOM_UNITS.RATE_DECIMALS);

       return numValue.toFixed(CONST.MAX_TAX_RATE_DECIMAL_PLACES);

I see one more edge case when rate is 166.9800 (There are some zeros in the end), should we display zeros? Currently, we also display inconsistency in this case

1. If yes, (we need to update how we display rates in the money request flow)

App/src/libs/PolicyUtils.ts

Line 152 in 69483ff

return numValue.toString().replace('.', toLocaleDigit('.')).substring(0, value.toString().length);

Remove .substring(0, value.toString().length);

2. If no, (we need to update how we display rates distance rate page)

App/src/libs/CurrencyUtils.ts

Line 167 in 69483ff

minimumFractionDigits: CONST.MAX_TAX_RATE_DECIMAL_PLACES,

        minimumFractionDigits: 2,
        maximumFractionDigits: 4,

Another problem in the update rate message, the rate only display 2 decimals. But this data is get from originalMessage. If we want to update it, we need to fix on the BE side or make a workaround on FE (detail later if needed)

What alternative solutions did you explore? (Optional)

[melvin-bot]

📣 @thelullabyy! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[melvin-bot]

⚠️ Invalid email. Please make sure to create an Expensify account with this email first here.

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[melvin-bot]

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

[melvin-bot]

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

[parasharrajat]

This seems like a regression from #49773. cc: @DylanDylann @daledah

[DylanDylann]

@parasharrajat Hmm, In #49773, we decided to mirror the Olddot behavior and always use a 4-digit decimal on the rate value.

About this bug, I think this is a new requirement for the update distance rate on the request money flow to use of 4-digit decimals, because this issue also happens on the Olddot

Screen.Recording.2024-10-03.at.10.59.06.mov

[DylanDylann]

I just glanced at proposals and noticed that @thelullabyy mentioned a valuable point

I see one more edge case when rate is 166.9800 (There are some zeros in the end), should we display zeros? Currently, we also display inconsistency in this case

[parasharrajat]

Ok. thanks for the input. let me review the proposals in that case.

[ChavdaSachin]

Edited by proposal-police: This proposal was edited at 2024-10-05 23:59:46 UTC.

Proposal

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

Rate on confirmation page shows 3 decimal value for a 4-digit decimal value rate

What is the root cause of that problem?

• On this PR fix: fixed 4 decimals for distance rates #49773 (comment) we decided to use 4 decimal digits for distance rate(irrespective of currency)
• We need some additional tough up for the change.

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

• First update RATE_DECIMALS: 4
  

  App/src/CONST.ts

  Line 2411 in 99f280b

  RATE_DECIMALS: 3,

• Now update fixedDecimalPoints logic here, based on if we want to hide appending zeroes or not.
  

  App/src/libs/PolicyUtils.ts

  Line 149 in 99f280b

  const fixedDecimalPoints = decimalPart.length > 2 && !decimalPart.endsWith('0') ? 3 : 2;

• An additional problem we face after such update is for currency which do not support decimals.(ex. ALL)

check this video

parameter: currency- ALL, rate-0.6799, distance-74.59mil, from New York to New Jersey.

Screen.Recording.2024-10-06.at.5.07.35.AM.mov

• When we display amount on report page we roundoff the amount according to currency. but when we try to edit the amount, edit amount page actually rips off the digits after decimal points for currencies which do not support decimals. which causes inconsistency between amount displayed on report page and amount displayed on edit amount page.

To solve this problem we need to start rounding off amount on IOUStepAmount instead of ripping of the digits after decimal point.

        setNewAmount(Number(currentAmount).toFixed());

App/src/components/MoneyRequestAmountInput.tsx

Line 236 in 99f280b

setNewAmount(MoneyRequestUtils.stripDecimalsFromAmount(currentAmount));

And some cleanup.

And need some additional changes from BE, the generated message when changing distance rate only has 3 decimal places so BE now need to return amount with 4 decimal places.

Optional
Generally we store amount value by multiplying it with 100 to avoid storing floating values, for the same reason we should start to store rate amount by multiplying it with 10000 and make a workflow around.

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.

[melvin-bot]

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

[kadiealexander]

@parasharrajat bump on the reviews!

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

• fix: unify distance rates display #50783

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

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

• @parasharrajat requires payment through NewDot Manual Requests
• @allgandalf requires payment automatic offer (Contributor)
• @thelullabyy requires payment (Needs manual offer from BZ)

[melvin-bot]

@parasharrajat / @allgandalf @puneetlath / @kadiealexander @parasharrajat / @allgandalf 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]

[allgandalf]

@thelullabyy when can we expect the new PR?

[thelullabyy]

@allgandalf I'll open the PR today.

[thelullabyy]

@allgandalf PR is ready for review.

[allgandalf]

Please remove the hold for payment label, the new PR is still in works

[allgandalf]

Update: New PR should get merged this week

[allgandalf]

Update: PR was merged

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

• fix: apply 4 decimal values for distance rate display #52609

If no regressions arise, payment will be issued on 2024-12-07. 🎊

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

• @parasharrajat requires payment through NewDot Manual Requests
• @allgandalf requires payment automatic offer (Contributor)
• @thelullabyy requires payment (Needs manual offer from BZ)

[melvin-bot]

@parasharrajat / @allgandalf @puneetlath / @kadiealexander @parasharrajat / @allgandalf 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]

[kadiealexander]

Payments due (50% reduction due to regression):

• Contributor: @thelullabyy paid $125 via Upwork (please apply!)
• Reviewer: @parasharrajat owed $62.50 via manual request (agreed to split here)
• Reviewer: @allgandalf owed $62.50 via Upwork (offer) (agreed to split here)

@allgandalf or @parasharrajat please complete the checklist!

[parasharrajat]

Payment requested for #49929 (comment)