Hi,
After a a few months of trial with kMyMoney (V5.0 + Ubuntu) for personal finances, I'm very happy with it, but I have a big issue:
I need to be able to freeze an (approx.) yearly status of all my accounts, in such a way that it is no more possible to do changes that will have impact on this status. For ex.: after the 'end-of-2019 freeze', it should no more be possible to update or remove a transaction recorded with a date < 31-Dec-2019

This freeze is important for me because I want to make year-level compareasons, analysis, tracking .. and, without this freeze capability, the whole dataset is absolutely not robust ! For ex., it could happen that:
- end of 2019: I carefully checked consistency of kMyMoney data wrt bank listings
- during 2020: I inadvertently change or delete an old (eg. 2013) transaction
- end of 2020: kMyMoney listings are not consistent with my bank listings.. due to this error in 2013 transactions (error created in 2020)
- the only way to resolve the issue is to redo consistency checks, year per year, until to find the erroneous year, then month, then transaction.....

As this is definitely not a funny activity, I search a tool with this freeze capability, but :
- kMyMoney 5.0.8 user guide is silent on this topic
- this 2009 post https://forum.kde.org/viewtopic.php?f=69&t=82839&hilit=lock says (for another reason) that there is no such lock,
but this is 10 years old..

I will be very disappointed if there is no such lock:
- from my point of view, it is a must-to-have feature to ensure data robusteness
- kMyMoney would be THE right tool for me .. if shipped with this FREEZE capability.

Thanks for help !
Marc

First of all: your request looks valid and the reasoning explains it. But ....

1. one usually gets a bank statement for accounts on a monthly basis. Using KMyMoney's reconciliation process one can immediately see that something is wrong in case of a former transaction being modified. I agree, finding the root cause of the problem is not easy from there on.
2. In case a transaction is marked as reconciled (R) you can still edit it, but KMyMoney will warn you if at least one split has the reconciled flag. One idea would be to change the state back to Cleared in case you modify it in state Reconciled so that it will be more visible in the reconciliation wizard (needs to be checked).
3. I see a more serious problem in the fact that one can enter additional transactions in the past (e.g. enter a transaction in 2019 erroneously in 2013). Again, the reconciliation process will catch it (and maybe immediately make it visible in the ledger of the wizard) but in case a freeze option exists, one should not be allowed to enter transactions prior to the youngest frozen transaction in the first place, right? BTW, the Frozen state was foreseen from the beginning of development but I believe was never completely implemented, tested or used (i.e. provided by the user interface), and you seem to be the first user actively asking for it.

Even though, the state is available and I see some code that checks for it and prevents certain operations, code that checks against the date of the last frozen transaction is not yet present, though. I did not check the deletion of a transaction. Another corner case is to change the post date of a newer transaction to a date prior of the post date of the last frozen transaction. That must also be prohibited. More checks maybe necessary throughout the code, importers included.

At this point I am not sure, if simply adding the Frozen state to the status combo is enough. Any thoughts are welcome, esp. from other users. I am also interested, if you have ever used the reconciliation process to change state.

Hi !
Thanks for your fast investigations (and sorry for the delay.. but due to your answer, I had some thoughts and had to make some homework..)

point (a): I agree that the hard point is to find the origin of the error. But, from a user point of view, I prefer a tool that prevent my errors, when practically possible, than a tool that let me detect them

point (b): I agree that, in this case (as well as in other relevant ones), the state of the transaction shall be reset !
Note : the green "reconciliation" bar should be also impacted (TBC: removed or marked 'To Be ReChecked' ?)

point (c):
- another possible use case to be considered is a transaction between two accounts and the modification of source or target account ?
- I am aware that kMyMoney is for personal finance, not for a 'world company' finances. NeverthelessI have to manage 25 accounts in 5 banks, with many transactions btw these accounts => I need my data to be robust wrt my errors, as I make errors from time to times ...
An idea could be :
- to implement, at the end of the reconciliation process, a 'freeze' action of the account up to its reconcilation date
- to have a 2-valued configuration option for the handling of relevant cases :
a) 'strict' --> change is not allowed (the user still can do the change, but after having changed the configuration option to 'non-strict')
b) 'non-strict' --> the tool send a warning and let the user decide to cancel or to continue

To answer to your last question : Yes, I used the transactions state and, at least at the begininning, the reconcilation process / wizard, but I came into trouble due to above and below points (and my learning curve..) => by the end, I no more use the reconciliation wizard and change the transactions state transaction per transaction.
Summary of my difficulties / wishes:

A) Transaction state:
A.1) the simple fact that I can set a transaction state to 'reconciled' outside of the reconciliation process & wizard was very confusing for me:
- what are the differences/pro/cons/... between these two ways to use the tool ?
- what does exactly mean 'account X has been reconciliated' if I can change relevant data after ?
- once I have changed data, after a reconciliation process, what is the reason why the green bar 'last reconciliation' is stil displayed ?
- why is it not possible to relaunch the reconciliation process at the same date ?

A.2) the user guide describe a 'Transaction state' (§ 11.9 'Understanding the state of a transaction') but, for a transaction T which is a transfert from account A to B:
- there is NOT a single transaction state, but TWO different states, each one associated to one of the half-transactions
- so, it is possible to have, at the same time: in A account listing : T status = 'reconciled' and in B account listing : T status = 'not reconciled'
This is correct from the reconciliation process point of view, but the user guide should better explain that:
- user guide describe a 'state of a transaction' (eg. § 11.9) and this is not correct/should be clarified
- the only related explanation I have found is § 11.3 'Using the transaction form' : "the actual transaction method is not used directly by KMyMoney but is purely for grouping/reporting purposes", but this is a little bit far away from reconciliation process..
Then, a specific report to find the transactions between 2 accounts and having different status could be useful

A.3) After reconciliation of an account:
- it is possible to change the status of a prior transaction of this account, without any tool warning
- in this case, the green line 'last reconciliation' of this account listing is not removed or tagged as 'TBC'
--> if the change is done (eg. in spite of tool warning, the green bar 'reconciliation' should be removed or tagged as 'TBC'

B) Account reconciliation history :

B.1) The account operation listing only show a single green bar the 'last reconciliation'
--> All reconciliation steps should be displayed.
--> after a change that invalidate a reconciliation step, this step and all the following ones should be removed or (better) tagged as 'TBC'

B.2) if you forget to print or save the 'Reconciliation report', it is definitely lost
--> Reconciliation reports should be automatically stored in the tool data and be retrievable on demand (eg. right click on green bar)

B.3) Reconciliation reports should mention their generation date (unchecked from my side)

C) HMI :

C.1) In the reconciliation wizard :
- right click on transaction X and select on 'Mark operation as "cleared"
- transaction X disappears and can no more be displayed in the wizard, whatever the 'state' selected in the filter field (up right part of the window), inc. 'all states' (Note: configuration option "Do not show reconciled transactions" is UNchecked)

C.2) From the reconciliation wizard, I can go anywhere in HMI, and change anything without exiting the reconciliation process
I understand the interest of this behavior, but I found it confusing due to that:
- the fact that this specific mode is only associated to the account(s) with an on-going reconciliation process
- the absence of obvious visual indication of this very special mode / activity. For ex., in the reconciliation wizard, the absence of obvious visual difference between:
- the (usual) buttons triggering action on operations (edit, delete..)
- the (specific) buttons triggering 'reconciliation process' actions (postpone and terminate)
--> an idea could be to add a rectangle around 'postpone' & 'terminate' with a label 'reconciliation wizard'
- the fact that in this special mode, transactions displayed are not identical to the 'standard mode' (eg. refer to point C.1 above - or is it a bug ) ?

I'll try to answer some of the questions, before continuing the discussion. Note that other than being a long time user of KMM, I'm also the primary keeper of the documentation. The "Q"s below are not directly taken from above, but I've tried to change the order and grouping of topics so I address everything. However, as I see I'm running out of time, and running long, I'll post what I've done so far, and save more for tomorrow.

Q: the simple fact that I can set a transaction state to 'reconciled' outside of the reconciliation process & wizard was very confusing for me:
A: More info below, but I understand this and will be happy to discuss how to improve the docs to avoid this confusion. Unfortunately, I think there is some inherent complexity in the reconciliation process, which sometimes just take time and using it to become more comfortable with it and what it actually does.

Q: what are the differences/pro/cons/... between these two ways to use the tool ?
A: There aren't really two separate ways to use the reconciliation tool/process. Perhaps it is unfortunate (due to the potential confusion) that setting a transaction's state between reconciled or something else can be done outside the reconciliation process. I suppose it could be considered a wishlist to restrict that action, but I would argue against it. Part of the issue would be that the process of changing the status would have to restrict certain state changes but not others. I'll discuss this further below.

Q: what does exactly mean 'account X has been reconciliated'
A: first the simple version. Reconciling an account means only that at the end of the process, The account, as stored in KMM, matches the statement of the account according to the institution, as of the date of that statement, at least in some specific ways. Mainly, the balance of the account must match, and all transactions listed on the statement get marked as reconciled. There is an inherent assumption in the process that when you begin the reconciliation process, that the account is reconciled correctly as of the previous statement. Just as part of use of KMM, when I reconcile an account, the first thing I do is to check the starting balance of the account for that statement. If that does not match, I immediately abandon the reconciliation, until I figure out what it wrong. Sometimes it is simple, sometimes it has taken me an hour. Yes, it is always my own fault, but as I will discuss below, in the long run, I'm not convinced that freezing the account would have helped me.

Q: what does exactly mean 'account X has been reconciliated' if I can change relevant data after ?
A: Just as above. The Reconciled banner in the ledger means that you have run the reconciliation process for that date, and KMM matched the statement. (It is also possible to reconcile against the online account, on a date other than when you receive a statement, but I am not aware of anyone actually doing that.) It means only that - that the account was reconciled as of that date.

Q: once I have changed data, after a reconciliation process, what is the reason why the green bar 'last reconciliation' is stil displayed ?
A: as above - because it only means that you did reconcile the account on that date. It only means the process was completed. It is really not in any other way any indication of the status of the account. [This has now started me thinking, that perhaps rather than changing the meaning or use of "reconciliation" as it currently works, that we can add some additional status indicators in a way very aligned with your requests. More on this below.

Q: why is it not possible to relaunch the reconciliation process at the same date ?
A: It actually IS possible. When you start the reconciliation process, the displayed date is 30 days after the date of the previous reconciliation. You can change it to anything you want. (I do not know if it prevents using a date prior to the previous reconciliation, but for various reasons, that would not make much sense.) In fact, however, trying to re-reconcile on the same date as you already did, might not be reasonable. For example, If it is now the 20th, and I reconcile a credit card account on the 10th, I have many transactions after the 10th already marked as cleared, since I do frequent online updates. However, for any transactions that actually cleared after the statement was generated, I need to change them to not cleared for the reconciliation to complete. Once I complete the reconciliation, I change them back to cleared. Reconciling again would be possible, but I would have to change the status on those same transactions again. Possible, but confusing, and I don't see the use.

Q: several questions/sugggestions about the user manual
A: I am quite happy to entertain suggestions or discussions regarding improving the manual. However, the mailing list or even private email might be a better place for that. The more complete or definitive the suggestions are, the easier it is for me to either just accept, or to make a counter proposal,

Still to be addressed:
- suggestions on what type of features can be added to more directly address the issues you have pointed out (perhaps new ledger banners separate from the existing "reconciled" more automatically added by the program, to help find problems introduced by retrospective changes to transactions.
- transactions disappearing in the reconciliation wizard on changing it's state
- better indication that you are reconciling an account, if you switch to a different account before finishing

Sorry to run on so long, but as has been noted - reconciliation is actually a complex issue.

Jack

I can't keep up with reading This is great! Coincidentally, our friends over at GnuCash are discussing the same topic (reconciliation that is) and present some other/more use-cases. Have not checked any details.