<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.<br>
</p>
<p>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.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 12/16/20 8:12 PM, Aaron Mehl wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1033041114.1621689.1608167541536@mail.yahoo.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div class="ydp74f8ed11yahoo-style-wrap"
style="font-family:Helvetica Neue, Helvetica, Arial,
sans-serif;font-size:16px;">
<div dir="ltr" data-setdir="false">Hi again,</div>
<div dir="ltr" data-setdir="false">It seems to me that since for
now I am only dealing with accounts, I will confine my
questions to them.</div>
<div dir="ltr" data-setdir="false">You said you can close an
account. Is this like archiving an account? </div>
<div dir="ltr" data-setdir="false">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.</div>
<div dir="ltr" data-setdir="false">Yes it is all very helpful. I
am on a short vacation, and next week I will I hope have an
outline ready.</div>
<div dir="ltr" data-setdir="false">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.</div>
<div dir="ltr" data-setdir="false"><br>
</div>
<div dir="ltr" data-setdir="false">This gives me a lots to work
on,</div>
<div dir="ltr" data-setdir="false">thanks again.</div>
<div dir="ltr" data-setdir="false">Aarom</div>
<div><br>
</div>
</div>
<div id="yahoo_quoted_8370502481" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial,
sans-serif;font-size:13px;color:#26282a;">
<div> On Wednesday, December 16, 2020, 07:05:27 PM EST, Jack
<a class="moz-txt-link-rfc2396E" href="mailto:ostroffjh@users.sourceforge.net"><ostroffjh@users.sourceforge.net></a> wrote: </div>
<div><br>
</div>
<div><br>
</div>
<div>On 2020.12.12 18:43, Aaron Mehl wrote:
<div class="yqt6654047791" id="yqtfd86209"><br clear="none">
> Hi all,I want to delete an account. I see that in the
Account menu <br clear="none">
> the is a delete item. The delete item is grayed out,
so I started to <br clear="none">
> fish to see where and how it works. I tried right
clicking the <br clear="none">
> account name in the Home view pane, but there was no
context menu. I <br clear="none">
> when into the Accounts view pane, I highlighted an
account and went <br clear="none">
> into the Account menu and delete was still grayed
out. I next tried <br clear="none">
> to right mouse click on the account name and delete
account was <br clear="none">
> grayed out. <br clear="none">
> So, when, can I delete an account and how do I do it?
This should be <br clear="none">
> a task that is self explanatory as far as I can see,
but I am <br clear="none">
> mightily confused.Help,Aaron</div>
<br clear="none">
<br clear="none">
I'm replying to the original message, and not one of the
replies. <br clear="none">
However, the other replies do raise valid points. I'll
start out with <br clear="none">
some more general observations about KMM, which may provide
a better <br clear="none">
context in which you can read the existing Handbook and
complete your <br clear="none">
short-term writing goal.<br clear="none">
<br clear="none">
The current KMM handbook was first written long ago, and was
not <br clear="none">
updated for many releases of the program. I took primary <br
clear="none">
responsibility for the Handbook over ten years ago, after
making <br clear="none">
similar complaints about how out of date it was. That was
for version <br clear="none">
2. Unless you're really interested, I'll skip all the gory
details of <br clear="none">
trying to keep the Hanbook up to date with changes and
enhancements to <br clear="none">
the program, but even with some help, I am still not fully
caught up. <br clear="none">
Each chapter of the doc indicates the version of the program
for which <br clear="none">
it was most recently updated, and there are still several
chapters for <br clear="none">
version 4.x. I'm slowly working my way through the rest of
it, but I <br clear="none">
end up focusing on areas with major UI changes, and when we
get <br clear="none">
specific questions. I'm always open to suggestions on both
specific <br clear="none">
edits and general improvements.<br clear="none">
<br clear="none">
One of the driving intents of KMM has been to follow good
bookkeeping <br clear="none">
practices, specifically double-entry bookkeeping. There are
probably <br clear="none">
numerous areas where the UI could be made simpler, but only
by dropping <br clear="none">
that restriction. I've put a fair effort into the docs to
try to <br clear="none">
explain some of the logic as to why things are as they are.
No, that <br clear="none">
understanding is not absolutely required to use the program,
but I <br clear="none">
believe it is important and helps to understand and accept
things that <br clear="none">
may not otherwise make sense to the naive user. A major
example of <br clear="none">
that is that Categories and treated internally as Accounts.<br
clear="none">
<br clear="none">
Another point is that there are often multiple ways to
accomplish the <br clear="none">
same task. It might be simpler for there to only be one way
to <br clear="none">
accomplish each task, but some people prefer to use the
keyboard as <br clear="none">
exclusively as possible, and some prefer the mouse. Also,
using the <br clear="none">
KDE frameworks (libraries) and Qt under that as the
foundation of the <br clear="none">
program has an effect on the look and feel. I suppose it's
just an <br clear="none">
extension of these that the same menu item can be found not
only on the <br clear="none">
main menu bar, but also on the context menu for an item on
the screen <br clear="none">
(raised by right-clicking on the item.) Most actions can
also be <br clear="none">
accomplished by clicking a button on the task bar, and the
list of <br clear="none">
buttons displayed is configurable by the user.<br
clear="none">
<br clear="none">
The issue of why some menu items are grayed out was
discussed <br clear="none">
elsewhere, but the philosophy followed here is that the
displayed menu <br clear="none">
items shouldn't change, but some will be disabled (grayed
out) if that <br clear="none">
action is not currently possible. It is a known issue that
figuring <br clear="none">
out WHY a particular action is not currently possible is
sometimes far <br clear="none">
more difficult than it should be, and I believe there are a
number of <br clear="none">
bugs for specific examples of this issue. More directly to
your <br clear="none">
original question, an entity (account or other) cannot be
deleted if it <br clear="none">
is referred to by some other entity in the system. Accounts
are <br clear="none">
referenced not only by transactions, but also by schedules,
and the <br clear="none">
presence of either can prevent the deletion of an account.
Hopefully, <br clear="none">
at least the delete action will be disabled consistently
everywhere it <br clear="none">
could be triggered.<br clear="none">
<br clear="none">
Further discussion on closing vs. deleting an account -
closing an <br clear="none">
account can be done if it has a zero balance. (I forget
whether there <br clear="none">
are other requirements.) It is pretty much the same as
actually <br clear="none">
closing the account with the bank or credit card company.
It prevents <br clear="none">
any further activities for that account, but the records and
history <br clear="none">
still remain available for examination and reporting. It is
also <br clear="none">
possible to control whethe or not closed accounts are shown
or not in <br clear="none">
most displays. Truly deleting an account is a much more
drastic <br clear="none">
action. It leaves no trace that the account ever existed,
which is why <br clear="none">
it is harder to do, requiring deletion of any other
reference to that <br clear="none">
account. I believe there will be users who think they want
to delete <br clear="none">
and account, when closing it is actually more likely to
achieve their <br clear="none">
actual goals.<br clear="none">
<br clear="none">
Enough blathering for now. Hopefully this is of some use.<br
clear="none">
<br clear="none">
Jack</div>
</div>
</div>
</blockquote>
</body>
</html>