Hi Eric, I see, that you've got many of suggestions related to KMM and the way you presented it might be enough for someone to implement them.
In my opinion, it's better to report them one by one on https://bugs.kde.org as wishes. The best would be to attach simple test cases (kmy files) with a description of expected results. The intent is to create work package, i.e. something easy to work with and accomplish. That's my personal preference. AFAIK entries on kmymoney-devel@kde.org aren't meant to hold long and may be forgotten soon. It's more of a discussion list and not a wishwall, where you can leave your wishes to stay forever :) Regards Łukasz Dnia środa, 28 marca 2018 04:55:01 CEST Eric Struckhoff pisze: > 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. General > > * [New] Navigation history; akin to browser's back and forward buttons. > * [New] Add some level of file-based security, such as password > protection and/or file encryption. 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. * [Change] Add > last-reconciled date to Accounts summary > 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. * [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. * [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. * [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. * [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. 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. 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 > > * 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. Please let me know if I can be of more assistance or if further > clarification is needed. Eric
