[GH-ISSUE #1185] [Bug]: When adding a new transaction by clicking the on the "Add" button, the payment/deposit amount doesn't get set correctly on the created transaction #7391

New Issue

GiteaMirror · 2026-04-10T17:12:19-05:00

GiteaMirror commented

2026-04-10 17:12:19 -05:00

Originally created by @joel-jeremy on GitHub (Jun 25, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1185

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

When adding a new transaction by clicking on the Add button, the payment/deposit amount doesn't get set correctly (it's set to 0) on the created transaction.

What error did you receive?

No error but newly creating creating transaction has its amount set to 0.

Where are you hosting Actual?

Fly.io

What browsers are you seeing the problem on?

Chrome

Operating System

Mobile Device

Originally created by @joel-jeremy on GitHub (Jun 25, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/1185 ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? When adding a new transaction by clicking on the `Add` button, the payment/deposit amount doesn't get set correctly (it's set to 0) on the created transaction. ### What error did you receive? No error but newly creating creating transaction has its amount set to 0. ### Where are you hosting Actual? Fly.io ### What browsers are you seeing the problem on? Chrome ### Operating System Mobile Device

GiteaMirror added the bug label 2026-04-10 17:12:20 -05:00

GiteaMirror closed this issue

2026-04-10 17:12:20 -05:00

GiteaMirror commented

2026-04-10 17:12:21 -05:00

@Kidglove57 commented on GitHub (Jun 26, 2023):

I am using Safari mobile set to 85% zoom. This does occasionally happen to me but usually the transaction is created with the correct transaction amount. Occasionally I have had a duplicate transaction also created but with 0 amount.

@Kidglove57 commented on GitHub (Jun 26, 2023): I am using Safari mobile set to 85% zoom. This does occasionally happen to me but usually the transaction is created with the correct transaction amount. Occasionally I have had a duplicate transaction also created but with 0 amount.

GiteaMirror commented

2026-04-10 17:12:21 -05:00

@joel-jeremy commented on GitHub (Jun 28, 2023):

This only seems to be present in mobile not in desktops.

@joel-jeremy commented on GitHub (Jun 28, 2023): This only seems to be present in mobile not in desktops.

GiteaMirror commented

2026-04-10 17:12:22 -05:00

@MatissJanis commented on GitHub (Aug 26, 2023):

@joel-jeremy is this on the responsive transaction entry page or the desktop view?

@MatissJanis commented on GitHub (Aug 26, 2023): @joel-jeremy is this on the responsive transaction entry page or the desktop view?

GiteaMirror commented

2026-04-10 17:12:23 -05:00

@joel-jeremy commented on GitHub (Aug 26, 2023):

I encounter this on the desktop view

@joel-jeremy commented on GitHub (Aug 26, 2023): I encounter this on the desktop view

GiteaMirror commented

2026-04-10 17:12:23 -05:00

@MatissJanis commented on GitHub (Aug 26, 2023):

Given we now have mobile transaction entry for mobile users - I'd say this is no longer applicable. What do you think?

@MatissJanis commented on GitHub (Aug 26, 2023): Given we now have mobile transaction entry for mobile users - I'd say this is no longer applicable. What do you think?

GiteaMirror commented

2026-04-10 17:12:24 -05:00

@kyrias commented on GitHub (Aug 26, 2023):

There's still the problem of split transactions not being implemented in the mobile view yet.

@kyrias commented on GitHub (Aug 26, 2023): There's still the problem of split transactions not being implemented in the mobile view yet.

GiteaMirror commented

2026-04-10 17:12:24 -05:00

@MatissJanis commented on GitHub (Aug 26, 2023):

There's still the problem of split transactions not being implemented in the mobile view yet.

That's a separate issue (please open a new issue). Lets not scope creep.

@MatissJanis commented on GitHub (Aug 26, 2023): > There's still the problem of split transactions not being implemented in the mobile view yet. That's a separate issue (please open a new issue). Lets not scope creep.

GiteaMirror commented

2026-04-10 17:12:25 -05:00

@Cldfire commented on GitHub (Aug 26, 2023):

Issue for split transactions in the mobile add transaction view is here: https://github.com/actualbudget/actual/issues/1352

@Cldfire commented on GitHub (Aug 26, 2023): Issue for split transactions in the mobile add transaction view is here: https://github.com/actualbudget/actual/issues/1352

GiteaMirror commented

2026-04-10 17:12:26 -05:00

@joel-jeremy commented on GitHub (Sep 2, 2023):

I think we should still address this. Some mobile users might still use desktop view since some desktop features are not yet available in mobile.

@joel-jeremy commented on GitHub (Sep 2, 2023): I think we should still address this. Some mobile users might still use desktop view since some desktop features are not yet available in mobile.

GiteaMirror commented

2026-04-10 17:12:27 -05:00

@LarsStegman commented on GitHub (Jan 6, 2024):

I also run into this. Notes are also not always included. I am using an iPad with iOS 17.2

@LarsStegman commented on GitHub (Jan 6, 2024): I also run into this. Notes are also not always included. I am using an iPad with iOS 17.2

GiteaMirror commented

2026-04-10 17:12:28 -05:00

@rich-howell commented on GitHub (Jan 19, 2024):

Given we now have mobile transaction entry for mobile users - I'd say this is no longer applicable. What do you think?

It depends what you mean by Mobile if you are talking about hand held devices then you are correct, however iPads are still very much a problem, blank transactions get entered more often than not when creating a new transaction, which I did raise in #2105 I think this needs addressing, it plagues my workflow and really puts me off using the iPad at all for data entry into Actual.

This isn't restricted to iPads though, I am able to replicate the problem in the dev tools on Edge by setting the device to iPad, screenshots below

Steps to replicate

Go to accounts register
Press add new transaction
Complete required fields
Fill in payment value
Press enter

If you press Add again the transaction is added a second time but this time with the value.

@rich-howell commented on GitHub (Jan 19, 2024): > Given we now have mobile transaction entry for mobile users - I'd say this is no longer applicable. What do you think? It depends what you mean by Mobile if you are talking about hand held devices then you are correct, however iPads are still very much a problem, blank transactions get entered more often than not when creating a new transaction, which I did raise in #2105 I think this needs addressing, it plagues my workflow and really puts me off using the iPad at all for data entry into Actual. This isn't restricted to iPads though, I am able to replicate the problem in the dev tools on Edge by setting the device to iPad, screenshots below Steps to replicate - Go to accounts register - Press add new transaction - Complete required fields - Fill in payment value - Press enter ![image](https://github.com/actualbudget/actual/assets/22135084/e2e2a863-7419-4b77-b2ec-8f7a1f08cefc) If you press Add again the transaction is added a second time but this time with the value. ![image](https://github.com/actualbudget/actual/assets/22135084/9d5c432a-5953-456c-9caf-48bfb6b49233)

GiteaMirror commented

2026-04-10 17:12:28 -05:00

@LarsStegman commented on GitHub (Feb 10, 2024):

I looked into the code a little bit and it looks like the field that is in focus does not update its state before the onAdd logic runs, which causes the state to be set to null. Either the field should update its current value constantly or the focus should be removed from the current focussed field before the addTransaction logic is run.

I didn't manage to completely understand how the code works though, so I haven't been be to fix it yet.

@LarsStegman commented on GitHub (Feb 10, 2024): I looked into the code a little bit and it looks like the field that is in focus does not update its state before the onAdd logic runs, which causes the state to be set to `null`. Either the field should update its current value constantly or the focus should be removed from the current focussed field before the addTransaction logic is run. I didn't manage to completely understand how the code works though, so I haven't been be to fix it yet.

GiteaMirror commented

2026-04-10 17:12:29 -05:00

@ionothanus commented on GitHub (Oct 11, 2025):

I don't see this workaround in the thread here, so I'll add: in my experience, if you change focus to another field after your last entry, without making any further changes, you can press Add and the transaction will reliably be created correctly with all fields set. I tend to work left to right, so once I've added the amount to Payment/Deposit, I'll tap the other amount field and confirm focus has changed before tapping Add.

@ionothanus commented on GitHub (Oct 11, 2025): I don't see this workaround in the thread here, so I'll add: in my experience, if you change focus to another field after your last entry, without making any further changes, you can press Add and the transaction will reliably be created correctly with all fields set. I tend to work left to right, so once I've added the amount to Payment/Deposit, I'll tap the other amount field and confirm focus has changed before tapping Add.

GiteaMirror commented

2026-04-10 17:12:29 -05:00

@matt-fidd commented on GitHub (Mar 23, 2026):

@joel-jeremy, finally a fix for this! Up at https://github.com/actualbudget/actual/pull/7268 if you're still suffering...

@matt-fidd commented on GitHub (Mar 23, 2026): @joel-jeremy, finally a fix for this! Up at https://github.com/actualbudget/actual/pull/7268 if you're still suffering...