KyMyMoney feedback - offer of assistance

Thomas Baumgart thb at net-bembel.de
Thu Mar 29 06:38:47 UTC 2018


Hi all,

On Mittwoch, 28. März 2018 02:55:01 CEST Eric Struckhoff wrote:

> Hello KMM development team,
> Thank you for all of your hard work in providing this great application to
> the community! This email is in response to the posting:
> https://forum.kde.org/viewtopic.php?f=69&t=151615&sid=739d46f85c0ef7cbb5edf
> 6a3992b2d08 I'm using KMM 4.8.1 on Win 10 Pro x64 (build 10.0.16299) as of
> this writing: 27 MAR 2018.  Admittedly I've not used KMM on Linux, and thus
> am not on the current release.  Therefore, I'll apologize up front if some
> if this was already addressed or not-applicable. 

I have to admit, that I sent Eric to the mailing list not knowing that he 
already has such a detailed list of things. If it would have known clear to 
me, I would have suggested bugs.kde.org right away. Sorry 'bout that.

To get some feedback nevertheless,  I will comment on a few entries.

> General
> 
>   *   [New] Navigation history; akin to browser's back and forward buttons.

That might exist, as we have talked about it. But that could also be on the 
old SF tracker.

>   *   [New] Add some level of file-based security, such as password
> protection and/or file encryption. 

We do have strong encryption using GPG working transparently on *NIX flavored 
systems for a long time. Don't know if that does not work on Windows or if 
only a few things are missing.

> Accounts
> 
>   *   [Change] Ability to change account type after creation.  I ran into
> this need during initial setup; as imports were having problems, so this
> may be more of a problem solved via documentation.

There might exist a wishlist item already.

> *   [Change] Add last-reconciled date to Accounts summary

This is already available (at least in master), so don't worry. See https://
phabricator.kde.org/D10001 or https://cgit.kde.org/kmymoney.git/commit/?
id=68ac2fe9a737dc58e4bfc81e43df7f744ccb0a90

> Schedules
> 
>   *   [Documentation] Establishing the scheduling frequency using the two
> combo boxes wasn't intuitive.  Fortunately, through trial and error, I was
> able to figure it out using the text of the Frequency column on the
> Scheduled transactions list view. In plain language 2 WEEK was displayed
> Every other week.
> *   [New] Scheduled transactions for credit card payments
> should grab the balance of the credit card's account ledger at the date of
> the transaction; or at least the current balance.

I think you mean the compensation payment towards the credit card, right?

> *   [Documentation/New]
> Transactions that buy shares are clunky (Bank -> Brokerage -> Investment)
> in that it takes twice as many scheduled tasks to transfer the funds, plus
> it leaves at one of these accounts never getting reconciled.  Documentation
> improvement is definitely required; but it may be helpful to make it so a
> composite transaction can address moving the funds to all appropriate
> accounts in one entry. Also, there doesn't seem to be an easy way to make
> payroll deductions for investments.  The split only permits category
> assignments.  More on that in the Ledger recommendations. 

The whole investment part may require some major rework.

> *   [personal note for follow-up] 
> The behavior and settings required to auto-enter
> scheduled transactions don't work as I expect; but I'm not yet able to
> articulate the concern.

> Ledger/Transactions
> 
>   *   [New] Create a paycheck form for entering transactions.  Create
> tabs/sections for wages, pre-tax deductions, taxes and post-tax deductions.
>  Include the ability to make transfers to other accounts, such as savings
> and investments.  Much of this can be done with additional transactions;
> but adding this feature would greatly streamline the process and improve
> accuracy. 

MS-Money had such a dialog. I think I have entered a wish list item for it 
many years ago, but don't know, on which tracker that sleeps. 

> *   [New] Option to swap keystrokes used to edit [Enter] or add
> [Ctrl+Ins] a transaction.  Data entry would be must faster using the enter
> key to create new transactions and reduces the likelihood of accidental
> edit of committed transactions. 
> *   [Fix] Selected tab is not clearly
> identified and leads to incorrect transaction types.  This is likely a
> rendering issue in windows. 

With the new ledger code this tab mechanism to select the type of transaction 
will be history.

> *   [Documentation] I don't recall the
> documentation mentioning that a double click in the number field will enter
> the next check number; assuming the last number was set in account settings
> first. 
> *   [Change] Tab-order on transaction form, although correct in
> field order (top/down, left to right), it is not intuitive or efficient for
> data entry.  For repeated transactions based on last entry, once the payee
> is selected the most likely thing to change are date and amount. Currently
> it takes 5-6 extra tabs to get there.  Over the course of a month's worth
> of entries, that adds up to lots of keystrokes.  For all transactions the
> split needs to come after the amount or the user will get errors on
> mismatched amounts.  Yes, you can update the total when exiting the
> sub-form; but entering the total up front would segue into the next topic:
> Splits.

The tab order can be controlled via a (I admit) hidden setting. We may just 
have to add a UI for it.

> Splits
> 
>   *   [New] If the amount of a transaction was entered before creating a
> split, provide the option to auto-divide remaining balance after splits are
> entered proportionally as taxes against each line in the split.  This
> assume the user doesn't want/need to track sales taxes as a separate
> category and wanted to track each category as the cost of goods with taxes.
> Example:
> 
>      *   Transaction gross is entered as 50.00
>      *   The split was two entries.  Line A for 10.00 and line B for 30.00.
>      *   The taxes on the receipt would be the remaining 10.00.
>      *   Upon exit, total 40 != 50, therefore KMM asks if user wants to
> split the rest as taxes, go back to correct, update total with new value or
> leave as-is. 
> *   Selecting to add taxes would re-calculate each split line
> as: 
> *   Line amount += (Transaction gross - current sum of splits ) * (
> Line amount / current sum of splits ) A follow-on feature to this would be
> enabling categories with individual taxable rates (for those that want to
> get very granular with their personal finances).
> 
>   *   [Change] Inside a split, pressing a number key should default to
> updating the amount not the category. 
> *   [Change] Permit transfers to
> other accounts.  The paycheck feature would require this; but it would also
> enable users of debit cards with auto-save features to direct debit their
> 'virtual change' to a savings account.

That is available. What is missing from your point of view? Simply select the 
account as category and you're set? Or am I missing something here?


> Importing/Matching/Reconciling
> 
>   *   [New] During reconciliation only, is it possible to perform a match
> AND accept at the same time. 
> *   [Fix] Matching transactions is
> inconsistent.  If you want to keep the details in transaction A when
> matching to B, sometimes you have to click A then perform the match command
> while over B and other times the complete inverse is true.  I'm not sure
> what Documentation

Yes, that is a bug. Matching may need another round and possibly better GUI 
support also.

>   *   Several key procedures deserve a sample walk-through.  The
> documentation does a decent job of explaining settings and other functions,
> but sometimes that is not enough to complete a process from start to
> finish.  It took a lot of trial and error (IE: Skipping saving the file and
> repeating several times) to get it right.  In particular, I had substantial
> difficulty in the following tasks: 

> *   Migrating data to KMM and getting a clean configuration to work with.
> 
> Some manual prep in the export file and inside KMM were required to get
> clean imports.  Using the raw QFX/QIF/CSV led to odd settings that couldn't
> be changed once created, such as incorrect account types.
> 
>      *   Reconciling the imported data to establish a baseline.
>      *   Importing bank statements and monthly reconciliation
> (accept/match/clear). 
>      *   Defining a paycheck transaction.
>      *   Configuration of investments, stock quotes and scheduling
> investment transactions. 

> Thank you for the opportunity to contribute my feedback. 

You're welcome. As you can see, some of the stuff is already known but time is 
usually the limiting factor. And then, the devs usually scratch where it 
itches. If you want to dive in, let us know. We can certainly give a helping 
hand and guide you through the source jungle.

> Please let me know if I can be of more assistance or if further
> clarification is needed. 


> Eric

-- 

Regards

Thomas Baumgart

https://www.telegram.org/       Telegram, the better WhatsApp
-------------------------------------------------------------
The person who says it cannot be done
should not interrupt the person doing it!
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 846 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20180329/6b5a9a78/attachment.sig>


More information about the KMyMoney-devel mailing list