delete or not to delete that is the question

[Aaron Mehl]

 Hi again,It seems to me that since for now I am only dealing with accounts, I will confine my questions to them.You said you can close an account. Is this like archiving an account? The rule that it has to have a zero balance is the way it happens in a bank. I can't close a bank account in my bank unless it has a zero balance.Yes it is all very helpful. I am on a short vacation, and next week I will I hope have an outline ready.I also agree that closing and account is the correct approach. And it makes me think that deleting an account would be to get rid of mistakes.
This gives me a lots to work on,thanks again.Aarom
    On Wednesday, December 16, 2020, 07:05:27 PM EST, Jack <ostroffjh at users.sourceforge.net> wrote:  
 
 On 2020.12.12 18:43, Aaron Mehl wrote:
> Hi all,I want to delete an account. I see that in the Account menu  
> the is a delete item. The delete item is grayed out, so I started to  
> fish to see where and how it works. I tried right clicking the  
> account name in the Home view pane, but there was no context menu. I  
> when into the Accounts view pane, I highlighted an account and went  
> into the Account menu and delete was still grayed out. I next tried  
> to right mouse click on the account name and delete account was  
> grayed out. 
> So, when, can I delete an account and how do I do it? This should be  
> a task that is self explanatory as far as I can see, but I am  
> mightily confused.Help,Aaron

I'm replying to the original message, and not one of the replies.  
However, the other replies do raise valid points.  I'll start out with  
some more general observations about KMM, which may provide a better  
context in which you can read the existing Handbook and complete your  
short-term writing goal.

The current KMM handbook was first written long ago, and was not  
updated for many releases of the program.  I took primary  
responsibility for the Handbook over ten years ago, after making  
similar complaints about how out of date it was.  That was for version  
2.  Unless you're really interested, I'll skip all the gory details of  
trying to keep the Hanbook up to date with changes and enhancements to  
the program, but even with some help, I am still not fully caught up.  
Each chapter of the doc indicates the version of the program for which  
it was most recently updated, and there are still several chapters for  
version 4.x.  I'm slowly working my way through the rest of it, but I  
end up focusing on areas with major UI changes, and when we get  
specific questions.  I'm always open to suggestions on both specific  
edits and general improvements.

One of the driving intents of KMM has been to follow good bookkeeping  
practices, specifically double-entry bookkeeping.  There are probably  
numerous areas where the UI could be made simpler, but only by dropping  
that restriction.  I've put a fair effort into the docs to try to  
explain some of the logic as to why things are as they are.  No, that  
understanding is not absolutely required to use the program, but I  
believe it is important and helps to understand and accept things that  
may not otherwise make sense to the naive user.  A major example of  
that is that Categories and treated internally as Accounts.

Another point is that there are often multiple ways to accomplish the  
same task.  It might be simpler for there to only be one way to  
accomplish each task, but some people prefer to use the keyboard as  
exclusively as possible, and some prefer the mouse.  Also, using the  
KDE frameworks (libraries) and Qt under that as the foundation of the  
program has an effect on the look and feel.  I suppose it's just an  
extension of these that the same menu item can be found not only on the  
main menu bar, but also on the context menu for an item on the screen  
(raised by right-clicking on the item.)  Most actions can also be  
accomplished by clicking a button on the task bar, and the list of  
buttons displayed is configurable by the user.

The issue of why some menu items are grayed out was discussed  
elsewhere, but the philosophy followed here is that the displayed menu  
items shouldn't change, but some will be disabled (grayed out) if that  
action is not currently possible.  It is a known issue that figuring  
out WHY a particular action is not currently possible is sometimes far  
more difficult than it should be, and I believe there are a number of  
bugs for specific examples of this issue.  More directly to your  
original question, an entity (account or other) cannot be deleted if it  
is referred to by some other entity in the system.  Accounts are  
referenced not only by transactions, but also by schedules, and the  
presence of either can prevent the deletion of an account.  Hopefully,  
at least the delete action will be disabled consistently everywhere it  
could be triggered.

Further discussion on closing vs. deleting an account - closing an  
account can be done if it has a zero balance.  (I forget whether there  
are other requirements.)  It is pretty much the same as actually  
closing the account with the bank or credit card company.  It prevents  
any further activities for that account, but the records and history  
still remain available for examination and reporting.  It is also  
possible to control whethe or not closed accounts are shown  or not in  
most displays.  Truly deleting an account is a much more drastic  
action.  It leaves no trace that the account ever existed, which is why  
it is harder to do, requiring deletion of any other reference to that  
account.  I believe there will be users who think they want to delete  
and account, when closing it is actually more likely to achieve their  
actual goals.

Enough blathering for now.  Hopefully this is of some use.

Jack  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney/attachments/20201217/504c3d63/attachment-0001.htm>