SUMMARY I have noticed that a transaction can be 'reconciled' but not 'accepted'. I would think that the transaction must be accepted before being allowed to be reconciled. Is there a potential reason why a transaction could be reconciled but not accepted? I figured this happened because I imported the transactions and then reconciled. I did not go through and accept each transaction. But the question in my mind is whether this should even be allowed. Maybe the reconciliation program should ask the user to accept all the transactions? Or maybe this does not matter in personal finances? STEPS TO REPRODUCE 1. import transactions but do not accept each one 2. reconcile the account OBSERVED RESULT Account is now reconciled but the transactions are still highlighted as never been accepted. EXPECTED RESULT Account is now reconciled and the transactions are accepted. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Gnome Fedara KDE Frameworks Version 5.95.0 Qt Version 5.15.2 (built against 5.15.2) ADDITIONAL INFORMATION
The reconcile process only changes Confirmed transactions to Reconciled, and only transaction on or before the reconciliation date. If an imported transaction is not yet accepted, it wouldn't be marked Confirmed, and so shouldn't get Reconciled. Note that an account can be reconciled as of a given date, but still have not marked transactions before that date. It can also have confirmed transactions before that date, but they would have been not marked when the reconciliation was done. If you are thinking that reconciling an account also reconciled all transactions prior to the reconciliation date, then you misunderstand how that process works. Please let us know if this explains what you see, or if not, please give some more details about what you see.
Hello, What I see is that there is a transaction that has been imported(not reconciled yet). In the ledger the transaction is highlighted a color to indicate that it is not yet 'accepted' post the import. Then, I reconcile the account, including the date of the transaction. The transaction is now reconciled along with the rest of the dates for the reconciliation period. I agree that a transaction should be cleared/confirmed prior to being reconciled but what I am noticing is that the transaction does not need to be 'accepted'. When you import transactions from an ofx file, for example, you need to accept the transaction. This does not auto clear/confirm the transaction, only Accepts it. In my opinion, an imported transaction should be accepted before it can be 'cleared/confirmed', and thus should definitely be marked accepted before it allows for reconciliation. But that is just my opinion and I realize that I may not be taking all possible issues into account. Let me know if that helps. I may just be way off course.
You do have the right idea. An imported transaction is explicitly noted in the ledger, and needs to be accepted. The real issue here seems to be that you are stating that an unmarked transaction (clear in the status column) gets marked "R" (Reconciled) when you reconcile the account. Again, after reconciling an account, there should be no Cleared transactions prior to the date of reconciliation, they should now be marked Reconciled. However, any unmarked transactions, whether or not the need to be accepted, should remain unmarked after the account is reconciled, and should also show up on the reconciliation report, which is shown in a pop-up. If this is the case, where did you get your version of KMM? Also, can you post a screenshot, showing a Reconciled transaction that still needs to be accepted?
Created attachment 151141 [details] master branch version showing a matched transaction (icon) which is reconciled note: I am referring here to the master branch (5.1 stable might be a little different) There are several pieces of information with regard to transaction import, acceptance and reconciliation. Once a transaction is imported, a flag says that it was imported and it is displayed as such. The reconciliation state is 'not reconciled' and the column in the ledger is blank. Such a transaction can then be accepted or marked cleared. In both cases, the import flag is removed and the reconciliation state is changed to 'cleared (C)'. It is a little different in case the import finds a matching transaction (either in the ledger or as a schedule). In this case, the imported and existing transaction are matched and shown with a different icon. The reconciliation state is automatically changed to 'cleared (C)' as part of the match. In case the match is false, such a transaction can be 'un-matched' which simply reverts the match operation and leaves the two transactions as separate entries in the ledger. One is the original transaction (which is still marked 'cleared (C)' - which is debatable at that point) and the other one shows the import flag and is 'not reconciled (blank)'. In case the match is accepted, the match icon is removed and the reconciliation state does not change. Now if the transaction is still in its original matched state after import (match icon shown, reconciliation state is 'cleared (C)') and the reconciliation process is started, the reconciliation state of the transaction will be changed to 'reconciled (R)' but the match state is not changed and the question what KMyMoney should do here is valid and needs to be defined. Options are a) prevent reconciliation b) automatically accept c) have a global setting to select between the two (auto accept default) d) ask user (either accept or prevent, one question for all transactions to be reconciled) My personal order of decreasing precedence would be b), c), d) and a).
Created attachment 151142 [details] master branch version showing an imported transaction (icon) which is not reconciled
hmm... interesting. At first I did not agree with the order of precedence, so I did not respond immediately until I could think it through a little more. Now that I have, I agree with Thomas. " order of decreasing precedence would be b), c), d) and a). " I would go with that as well.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I don't think we're waiting for more feedback, just need to decide what to do.
Git commit 7f58110ade2b7f2da29005103fe2b6c30a8b7684 by Thomas Baumgart. Committed on 24/08/2022 at 15:03. Pushed by tbaumgart into branch 'master'. Match cleared transactions during reconciliation M +5 -0 kmymoney/views/reconciliationledgerviewpage.cpp https://invent.kde.org/office/kmymoney/commit/7f58110ade2b7f2da29005103fe2b6c30a8b7684
Created attachment 151570 [details] attachment-9871-0.html I suppose it would be worth adding an explanation on how this works to the manual-- Best Regards, Dawid Wrobel