Bug 443551 - Default reconciliation state not used for new entries
Summary: Default reconciliation state not used for new entries
Status: REPORTED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 5.0.6
Platform: Other Other
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-10 14:16 UTC by rogerpackman
Modified: 2021-11-17 19:06 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rogerpackman 2021-10-10 14:16:49 UTC
SUMMARY


STEPS TO REPRODUCE
1. Default reconciliation state not used for new entries
2. Default reconciliation state not used for new entries
3. 

OBSERVED RESULT
Default reconciliation state not used for new entries

EXPECTED RESULT
New transactions should have default reconciliation state per Settings/Ledger of "Reconciled", but they are "Not reconciled"

SOFTWARE/OS VERSIONS
Windows: Windows 10
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Thomas Baumgart 2021-10-17 11:24:22 UTC
Well, this option is meant to be active only during entry of new transactions during reconciliation. The description does not mention that, but it behaves that  way since the feature made it on board. I traced that back at least 12 years in version 3.95.0. A proper way would be to enhance the description in the dialog and  the manual to make that clear.

Or should we change the feature? Opinions, suggestions please.
Comment 2 Brendan 2021-10-17 18:27:14 UTC
I always thought it meant the default state no matter how the transaction is entered so clearing that up would probably help. I never enter transactions while reconciling, so it appears that setting does nothing for me.

I guess it might help some to have that setting or a new setting define the default state of transactions enter manually or when imported. I want everything unmarked (not reconciled) so I'm okay with the current behavior.

I may be nitpicking, but "Default reconciliation state" seems a like it should be "Default transaction state". Technically "Cleared" and "Not reconciled" are both "Not reconciled". Seems like reconciliation state is binary.

This discussion of settings reminds me of an ongoing problem that I have with matching when I import transactions. While the next tab over lets you set the time frame for matching imported transactions, it does not work the way I expect it to. There seems to be no limit on how far back matching to match the transaction with the closest value which frequently screws up all of the splits on paychecks. At the very least, the description should clarify what this setting does. Ideally it would work on all imported transaction, or an additional setting should be added to work on whatever this does not work on. Maybe the ideal solution is to add this on a per payee basis since limiting the time frame may only make sense on some payees.
Comment 3 rogerpackman 2021-10-17 19:43:39 UTC
I'm not sure if us ordinary mortals are allowed to comment and I just receive updates as I reported the bug, or if comments are restricted just to tekkies. But if we can comment, I would welcome this being available for all new transactions, as I never reconcile (shame on me!), though I do look into it if the balance does not appear to be correct. So a default state of reconciled is well suited to people like me. I moved to the excellent KMyMoney from Money Manager EX, as I prefer it, but that does allow a default state of reconciled for all new transactions.
Thank you very much to you guys who are sorting this out!
Comment 4 jesse 2021-10-18 17:17:51 UTC
On the surface, I do not think we should allow transactions to be automatically entered as reconciled. However, let us consider what reconciliation was intended for. 

My understanding, it was intended to say that the user has compared the ledger in the program to their bank statements and accepts them as being in sync. Now, in 2021, when many people, not all, import transactions from a download provided by the institution, would we still reconcile? It almost seems like that step is no longer necessary. Back in the day when check writing was very normal still, it may have made sense. 

Maybe not now?
Comment 5 Jack 2021-10-18 17:37:18 UTC
I download all (or almost all) of my transactions using OFX direct connect, and I still find reconciliation an absolutely necessary process.  Not for all my accounts, but for my investment accounts, the downloaded transactions very often do not exactly match the transactions as printed in the monthly statement.   Some have rounding errors (very minor, but still there) and some transactions simply never get downloaded.  Also, don't exclude those users (I have no idea what percent) do NOT download transactions online.  Those users also need to be supported.
In the context of the original design, I agree, there is no reason to have the default state be reconciled.  However, given that everyone has their own use case, we need to consider that.  But - given the use case presented above, I would suggest that if a user never performs reconciliation, then there is no real reason to ever mark a transaction as reconciled.  In the end, though, it is up to the user how they want to use the program.
Comment 6 Bug Janitor Service 2021-11-02 04:35:17 UTC
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!
Comment 7 Bug Janitor Service 2021-11-17 04:39:13 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now 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

Thank you for helping us make KDE software even better for everyone!
Comment 8 Dawid Wróbel 2021-11-17 11:53:18 UTC
Was this supposed to be closed? From the discussion itself, doesn't look like it.
Comment 9 rogerpackman 2021-11-17 12:08:49 UTC
Totally agree with the previous comment. Nothing has happened! I can't be the only person who doesn't formally reconcile, just periodically look to confirm that my balances in KMyMoney are the same as online at the bank, which they nearly always are. In which case I consider the balances reconciled. So default reconciled state works for people like me. Equally a default unreconciled state works for people who wish to formally reconcile.
Comment 10 Jack 2021-11-17 14:34:54 UTC
Thomas changed the status to WAITINGFORINFO and nobody changed it back to REPORTED, so it was automatically closed.  I prefer to leave it closed and leave the current behavior,  If someone doesn't perform the reconciliation process, fine, but marking transactions reconciled would imply they did so, which is misleading.  I suppose someone could reopen this as a wishlist, and someone could create an MR even without the bug being open.
Comment 11 rogerpackman 2021-11-17 14:46:14 UTC
Sorry, no offence intended, but the above comment is madness! The person not formally reconciling would know they hadn't done so and would not be misleading his or herself. Why not just give people a choice, instead of trying to censor others behaviour, even if you don't agree with it? KMyMoney is a great program, but please just let people choose for themselves how they prefer to use it.
Comment 12 Jack 2021-11-17 14:54:25 UTC
Patches gratefully accepted.  I wouldn't object to this being done, but I believe their are lots more important needs to be addressed by the limited developer time  available.  Do you understand how this bug tracker works?  You opened the ticket.  When Thomas responded, he set the status to NEEDSINFO, because he requested additional input  When you replied next, you should have reset the status back to REPORTED.  The system automatically closes bugs in the NEEDSINFO status for more than thirty days, since that most commonly means the person who posted it  no longer cares about it.  If you do, I suggest setting the priority to wishlist, as I see this as a request for change in behavior, not truly a bug.  Simply complaining isn't going to get you anywhere.
Comment 13 rogerpackman 2021-11-17 15:32:20 UTC
Thank you for the explanation. I indeed had no idea how the bug tracker worked or even if I was supposed to be commenting at all, as I'm not part of the developer community. If the entry in Settings/Ledger had not been so misleading (there is no indication the default reconciliation state is restricted to when entering new transactions whilst reconciling), I would not have reported this as a bug anyway. So I won't pursue further and will just keep doing what I've done till now, which is to change the reconciliation state every time I enter a new transaction. Hopefully no offence caused to anyone and thanks to you all for all your hard work as developers.
Comment 14 Jack 2021-11-17 17:25:43 UTC
No offense taken at all, and yes, non-developers are absolutely welcome to comment here.  Most bugs are reported by non-developers, since they will likely test pathways through the program the developers have not.  In addition, this bug tracker is also used for enhancement requests, which are indicated by changing the second importance dropdown from "normal" to "wishlist."  This can be useful, even for something unlikely to be implemented, just to remember it was a valid request, and to let others comment and possibly suggest alternate approaches (either workarounds or different possible implementations.
Comment 15 rogerpackman 2021-11-17 18:42:16 UTC
Thank you!  Unfortunately despite that advice I cannot find where to change this from normal to wishlist, so hopefully someone else can do that if this is being closed.
Comment 16 Jack 2021-11-17 18:50:12 UTC
I've reopened and changed to wishlist.  The priority setting is near the top of the page, and the status is near the bottom.  

My take is that the request is to allow the user to set a default state (not marked, cleared, reconciled) for all new transactions, not just during the reconciliation process.  I'll add possible additional options of making this per-account, and possibly distinguish manually entered vs. imported transactions.

I'll also point out one additional issue with this, and that it would have transactions marked as reconciled, but without any reconciliation having been done, and thus no reconciliation records present for the account.  This might cause difficulties if the user did later try to reconcile the account, but I'm not absolutely certain about that.
Comment 17 rogerpackman 2021-11-17 19:06:12 UTC
Thank you again. Yes, the request is to be able to set a default state for all new transactions, not just whilst reconciling. That option has been available in other finance software I have used in the past. And in my case, as an example, would save me having to change the reconciliation status every time I enter a new transaction. Although I don't formally reconcile every transaction, I do check the account totals in KMyMoney against those at the bank online, which for me passes as a sort of reconciliation, as they are rarely different.