mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-15 22:54:03 -05:00
[GH-ISSUE #558] [Feature] Reconcilliation to Lock Transactions #69971
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#69971
Reference in New Issue
Block a user
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?
Originally created by @rich-howell on GitHub (Jan 22, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/558
Discussed in https://github.com/actualbudget/actual/discussions/38
Originally posted by bdoherty May 4, 2022
Actual currently allows you to run a reconciliation, but it doesn't appear to lock transactions after you have reconciled.
I think that after running reconciliation, then the cleared tick symbol should change to a padlock, and you shouldn't be able to delete or change the total of the transactions (however you could potentially still be able to change the category and split the transaction)
@MatissJanis commented on GitHub (Jan 23, 2023):
I think we definitely want to do this. I might even consider doing it myself if I get some free time and if someone else doesn't beat me to the punch. I'm a big user of reconciliation.
@github-actions[bot] commented on GitHub (May 1, 2023):
✨ Thanks for sharing your idea! ✨
This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. 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 👍!
@jnimmo commented on GitHub (May 17, 2023):
Very much looking forward to someone getting a chance to work on this - my current reconciliation status is not great!
@rich-howell commented on GitHub (May 17, 2023):
Fundamentally weather we lock or don't lock your own process is flawed, your budget is now un reliable if the reconciliation is so far out it can't be managed, no amount of locking of transactions is going to fix that unless you perform a reconciliation.
@jflattery commented on GitHub (May 17, 2023):
This likely deserves its own ticket, but along with locking reconciled transactions, there should also be a way to filter/ hide them.
@DigisHub commented on GitHub (Jul 11, 2023):
IIRC in old YNAB you can still edit locked transactions, but a warning is displayed that it will affect the reconciliation.
Additionally, on entering reconciliation state, the locked transactions should automatically get filtered out.
@jnimmo commented on GitHub (Jul 11, 2023):
Correct, but at least I then know that my error is in the last month rather than potentially being anywhere in the whole history of the budget :)
@Rick-Thomas commented on GitHub (Jul 11, 2023):
For me the reconciliation process is important so's to be able to make sure my balances are OK and up to date... The way I would like to use it is in a 3 step process, as YNAB and other apps have:
Actual lets me do 1. and 2. with no problem, but 3. is missing... Having my Bank reconciled till the end of last month, any differences that come up are current... As Actual stands today this Step 3. does not happen and I could have a difference popping up today causes by accidentally having modified an amount in an old and reconciled account, and finding that difference could be VERY cumbersome!!!
Hope this Feature comes to Actual soon!!!
@JavaDogWebDesign commented on GitHub (Aug 31, 2023):
I would also love to have this feature. It locks in the cleared transactions so that it can't be accidentally modified or uncleared.
@zachwhelchel commented on GitHub (Sep 11, 2023):
Currently
clearedis a boolean in the schema for a transaction. Best I can tell YNAB uses an enum forclearedwith the options being "cleared", "uncleared", and "reconciled". Here is their API endpoint: https://api.ynab.com/v1#/Transactions/getTransactionByIdSimilarly when you download your data from YNAB it corroborates the above.
Any reason to not set this up the same way? I guess we could add an extra boolean for
reconciled = truebut there would never be a case whereclearedwould be needed oncereconciledis true.Not sure how heavy a migration would be. Is there a guide or good example somewhere for how to do data migrations? @MatissJanis @rich-howell
@zachwhelchel commented on GitHub (Sep 11, 2023):
Currently just setting
notesto "reconciled" upon a successful reconciliation in order to build out the other functionality (until the schema change decision is settled). I have the icon showing, next up is adding a warning before you try to edit it.@zachwhelchel commented on GitHub (Sep 12, 2023):
Looked over YNAB's docs to make sure there weren't any other implications for locked transactions I hadn't thought of (https://support.ynab.com/en_us/reconciling-accounts-a-guide-BJFE3fHys). The only one I'm seeing that we haven't already considered is this:
Moving forward, YNAB will only import transactions dated up to three days prior to your last reconciled transaction. This is good news, as it helps to prevent duplicates from importing!
So here is our path forward:
clearedto enum or addreconciledboolImport decision: limit imports to three days prior to last reconciled transaction or leave as isUpdate importers to handle reconciled transactions being importedFor the two decisions... I would lean toward switching cleared to an enum and matching YNAB's three day prior rule.
@Rick-Thomas commented on GitHub (Sep 12, 2023):
I'm not a technical guy but YES I am a big user of the three steps (Not Reconciled, Marked and Reconciled) for a couple of reasons:
So for whatever it's worth, I'm all for this feature implementation, together with the Hiding Reconciled Transactions one...
@zachwhelchel commented on GitHub (Sep 12, 2023):
Errors are now showing when you try to edit a reconciled transaction. There is some weird behavior in the differences between the following:
Working through handling all these cases.
@JavaDogWebDesign commented on GitHub (Sep 12, 2023):
This is how the reconcile feature works on Financier. When I click on Reconcile, the popup will confirm whether the transaction is correct:
If I click on no, it'll ask for the correct amount (if i click on yes, it'll just lock up all cleared transactions):
Then it'll ask if I'd like to add or remove a certain amount to bring it to the current balance:
Then it auto-creates the transaction:
Is this something that you're working towards? I use the reconcile feature and click on "no" and auto create to bring to the current balance a lot with investment accounts and cash.
@zachwhelchel commented on GitHub (Sep 13, 2023):
@JavaDogWebDesign that concept is already included in Actual. This issue is for making sure that the transactions appear as "locked" once you've reconciled.
@JavaDogWebDesign commented on GitHub (Sep 13, 2023):
Ah, got it. Have you tried asking for a follow-up on discord? Helpful bunch of folks there may be able to answer the question.
@MatissJanis commented on GitHub (Sep 13, 2023):
Sorry for the slow response @zachwhelchel . I try to prioritize PRs over discussions on issues or discord, so it takes a bit of time to respond.
I would recommend to add a new column. Historically we've had problems when renaming/altering existing columns (sync breaking for some folks). Obviously it won't be as clean as switching to an enum, but it will be more stable and secure.
What's easier? To leave as-is or to implement this new logic? I'd go with the path of least resistance for the initial version and then see if we get some feedback from the community.
Let me know if there's anything else I can help with! Super exciting to see all the work you're doing and I can't wait to review it.
@jflattery commented on GitHub (Sep 13, 2023):
@MatissJanis I think this could cause issues further down the line. Should a transaction that hasn't cleared yet ever be reconciled? I would adamantly argue no, that is only going to cause frustration for the user down the road when that transaction clears and its final value is off from the original amount. Having these as two separate fields means more checks and complexity need to be added.
@Rick-Thomas commented on GitHub (Sep 14, 2023):
I agree... Not to mention valuable monitor real estate it would require...
@youngcw commented on GitHub (Nov 22, 2023):
Feature has been added. Will be included in the next release
@jnimmo commented on GitHub (Nov 22, 2023):
Awesome, thanks for your effort @zachwhelchel & reviewers! Look forward to trying it out :)
@Rick-Thomas commented on GitHub (Nov 23, 2023):
Wowwwww... great incorporation to Actual!!!! Eagerly waiting to trying it in the next release!!! Tks for the effort...