When manually adding entries (page 'ledgers'), the entry type is displayed incorrectly when there is no associated category. Reproducible: Always Steps to Reproduce: 1. go to 'ledgers' 2. add an entry without a category of type 'withdrawal' 3. save it Actual Results: The entry is shown as type 'transfer'. When editing it jumps back to the correct type.
Fixed in git master: one cannot complete step 2 of your procedure as entering a transaction without an assigned category.
The problem also happens when you import data from a file as not always a category can be found. Was this also fixed?
On 25/04/14 18:40, Yasin Zähringer wrote: > https://bugs.kde.org/show_bug.cgi?id=333875 > > Yasin Zähringer <yasinzaehringer+kde@yhjz.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |UNCONFIRMED > Resolution|FIXED |--- > > --- Comment #2 from Yasin Zähringer <yasinzaehringer+kde@yhjz.de> --- > The problem also happens when you import data from a file as not always a > category can be found. Was this also fixed? > What happens on import depends largely on the input file. For instance, with a QIF file, it would then depend on the source of the file. If it was produced by another personal finance program of yours, then it is possible that the file could include a transfer to another known local account. A file from say a bank will not have any notion of the local account structure, and likely will contain only deposits or withdrawals. OFX and CSV files generally are not produced by personal finance programs, so they too would contain only deposits or withdrawals. The CSV import plugin can now handle categories, but up to now there has not been a requirement for transfers. In the main, then, with imports other than QIF, the transactions are likely to be flagged as missing an assignment. Allan
Thanks for the detailed explanation! Am I correct when I claim that the underlying bug isn't fixed? Only my procedure to reproduce it has to be adapted? If you want, I can write down the test case.
On 26/04/14 12:44, Yasin Zähringer wrote: > https://bugs.kde.org/show_bug.cgi?id=333875 > > --- Comment #4 from Yasin Zähringer <yasinzaehringer+kde@yhjz.de> --- > Thanks for the detailed explanation! Am I correct when I claim that the > underlying bug isn't fixed? Only my procedure to reproduce it has to be > adapted? If you want, I can write down the test case. > As Thomas said, --- Comment #1 from Thomas Baumgart <ipwizard@users.sourceforge.net> --- Fixed in git master: one cannot complete step 2 of your procedure as entering a transaction without an assigned category. If you are still able to reproduce the problem, but now using the latest version, then, yes, please do show your test case. As I see it, too, one cannot save a new transaction without a category. Allan
I think the bug is triggered by transactions without an associated category. As there is no direct way anymore to enter a transaction without a category, I suggest you try the following: 1. Import a transaction from a CSV file, for example the spaces.csv mentioned in https://bugs.kde.org/show_bug.cgi?id=333911 (importing instructions are given in the bug description) 2. Go to ledgers and view the transaction. If it doesn't show the transaction type as 'Transfer', then the bug is indeed fixed.
I just checked the issue with the current git master and it still exists. Import the referenced csv file and select the transaction, then the displayed transaction type is 'Transfer'. When you edit the transaction, the tab switches to the correct type. I attach a screenshot.
Created attachment 86287 [details] Details of a transaction without a category. The wrong tab is displayed.
That is not as easy as it might look in the first place as KMyMoney tries to hide the sign in the amount field: In order to determine a deposit or a withdrawal one thus needs to know, which account type the other side of the transaction references to. In this case here, this essential piece of information is missing. One could certainly argue, that the information could be extracted from what is present and update the display accordingly. One could also argue, in case the program does not know it, it treats it as transfer. We have decided to go the latter route. Since this part of the code has to deal with a bunch of corner-cases, I really don't want to touch it right now as it is otherwise not broken but works as designed. The design might not be in line with your view. Example: what should be done, in case the amount is zero? No way to determine if it's a deposit or withdrawal anymore. And yes, I receive such transactions while downloading from my bank. Plus, these are the only transactions that are allowed to have a single split to balance. I would suggest to mark this one as a wishlist item and set the topic to something like "Unassigned transactions should be displayed as deposit/withdrawal not transfers". BTW, patches are very welcome.
Thanks for the nice explanation! I start to see your point and now I am not sure if I can justify my opinion any longer. Probably we should leave it as is for the moment and see what the future brings.
I've now marked this as CLOSED-WONTFIX. If this should be changed, feel free.