github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 15:12:35 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #3053] [Feature] Show the full decimal places when editing regardless the "Hide decimal places" setting, and defer rounding decimal amount when editing/adding transactions when using "Hide decimal places" #15469

New Issue
Closed
opened 2026-04-14 18:28:15 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-14 18:28:15 -05:00
Owner
Copy Link

Originally created by @andriantoeff on GitHub (Jul 14, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/3053

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

To my knowledge, decimal amounts along with its fractional part are saved fully to the database (to a limited precision length).

Rounding happens when (but not limited to):

  • you go beyond the precision length limit
  • you enable "Hide decimal places" setting

The scope of this feature request is the handling of decimal places when using the "Hide decimal places" setting.

When using "Hide decimal places", editing rows with Payment/Deposit value that is originally stored with significant fraction value (e.g. 5.5) should reveal the original decimal value instead of the rounded value (e.g. should show 5.5 instead of 6). The user then should be able to edit the amount to another fraction value if needed. And the displayed rounding should only happen after Adding/Saving the row (for viewing back the add/edit result), not just after the field goes out of focus.

For consistency, adding rows (while still in the add/edit mode) should also behave the same.

Rationale:

  • Rounding the value just after it goes out of focus, or when editing the row, may confuse the user that the value will be/is saved as a whole number--unless if the saved value will be the rounded version (e.g. when user keyed in 4 fraction digits and the saved value in the database will only have 2 fraction digits).
  • Users in countries with a high number of digits in their currency system (1 digit in USD translates to 5-6 digits in my country) may want to reduce the number of displayed digit, but may still want to have the fractional digits for precision tracking (particularly for interests and discounted amounts).

Describe your ideal solution to this problem

The web app may need to track the real amount and the rounded amount for each transactions (in memory). The rounded amount is primarily used for displaying, while the real amount is used for saving to database, editing, sorting, aggregating/summing up/reporting.

In the future (I hope), the rounded amount may also be used to store a more shortened version of the amount, e.g. display 123456.78 as "123K".

Teaching and learning

The behavior should be a standard with no or minimal explanation to end users.

But, behavior regarding rounding should be documented for future developers' guide:

  • generally, where does the rounding should happen
  • how many decimal places is stored in the database
  • what is the rounding strategy used in front end and back end
  • about separation between real amount and displayed amount (if implemented this way)
Originally created by @andriantoeff on GitHub (Jul 14, 2024). Original GitHub issue: https://github.com/actualbudget/actual/issues/3053 ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [X] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? To my knowledge, decimal amounts along with its fractional part are saved fully to the database (to a limited precision length). Rounding happens when (but not limited to): - you go beyond the precision length limit - you enable "Hide decimal places" setting #### The scope of this feature request is the handling of decimal places when using the "Hide decimal places" setting. When using "Hide decimal places", editing rows with Payment/Deposit value that is originally stored with significant fraction value (e.g. 5.5) should reveal the original decimal value instead of the rounded value (e.g. should show 5.5 instead of 6). The user then should be able to edit the amount to another fraction value if needed. And the displayed rounding should only happen after Adding/Saving the row (for viewing back the add/edit result), not just after the field goes out of focus. For consistency, adding rows (while still in the add/edit mode) should also behave the same. #### Rationale: - Rounding the value just after it goes out of focus, or when editing the row, may confuse the user that the value will be/is saved as a whole number--unless if the saved value will be the rounded version (e.g. when user keyed in 4 fraction digits and the saved value in the database will only have 2 fraction digits). - Users in countries with a high number of digits in their currency system (1 digit in USD translates to 5-6 digits in my country) may want to reduce the number of displayed digit, but may still want to have the fractional digits for precision tracking (particularly for interests and discounted amounts). ### Describe your ideal solution to this problem The web app may need to track the real amount and the rounded amount for each transactions (in memory). The rounded amount is primarily used for displaying, while the real amount is used for saving to database, editing, sorting, aggregating/summing up/reporting. In the future (I hope), the rounded amount may also be used to store a more shortened version of the amount, e.g. display 123456.78 as "123K". ### Teaching and learning The behavior should be a standard with no or minimal explanation to end users. But, behavior regarding rounding should be documented for future developers' guide: - generally, where does the rounding *should* happen - how many decimal places is stored in the database - what is the rounding strategy used in front end and back end - about separation between real amount and displayed amount (if implemented this way)
GiteaMirror added the feature label 2026-04-14 18:28:15 -05:00
GiteaMirror commented 2026-04-14 18:28:17 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 14, 2024):

✨ Thanks for sharing your idea! ✨

This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

<!-- gh-comment-id:2227377018 --> @github-actions[bot] commented on GitHub (Jul 14, 2024): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don’t forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
GiteaMirror commented 2026-04-14 18:28:17 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 5, 2025):

🎉 This feature has been implemented in #5808 and will be released in the next version. Thanks for sharing your idea! 🎉

<!-- gh-comment-id:3369056872 --> @github-actions[bot] commented on GitHub (Oct 5, 2025): :tada: This feature has been implemented in #5808 and will be released in the next version. Thanks for sharing your idea! :tada: <!-- feature-implemented-comment -->
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#15469
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?