delete or not to delete that is the question

Jack ostroffjh at users.sourceforge.net
Thu Dec 17 03:30:44 GMT 2020


Yes - deleting is mainly used to get rid of mistakes - things that 
should not have been created in the first place, or things that were 
created using wrong information where starting over is easier than 
trying to fix things.  I can think of other reasons, but I would 
generally label them as "pathological" (odd, strange cases that are 
definitely not common, and probably reflect other problems.)  Closing an 
account may be similar to archiving, but is different in that all the 
data is still withing the current data file.

It is a discussed issue that KMM has no real concept of archiving (other 
than saving data files every now and then) and also has no way to "clean 
up" old data.  There is an open wishlist" item for this - the basic idea 
(rephrased by me) is that you might want to rid your current data file 
of any data older than N years.  That would take a lot of effort - you 
could just delete all transactions older than that, but then (to keep 
current records accurate) you would also have to adjust the opening 
balances of all accounts to reflect the actual balance on that new 
starting date.  Investment accounts would be even harder, if (as is not 
done currently) you want to know the correct original purchase date and 
value of any equities.


On 12/16/20 8:12 PM, Aaron Mehl wrote:
> 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/20201216/55a1ebf3/attachment.htm>


More information about the KMyMoney mailing list