I want to sort the information with the newest data at the top (ie July transactions at top and January at the bottem). The dates and payee information invertes correctly but the payment, deposit, and balences do not. I can't determine what they do. Reproducible: Always Steps to Reproduce: 1. I import bank data. It puts the information in oldest at top and newest at bottem. All information at this point is corect. Date, Number, type,payee,payment,amount,total. 2. Right click on details bar and get sort options. 3. Uncheck default and change post date to up leaving other options at default. 4. Transactions will change but the amounts do not change correctly. Actual Results: Transactions will change but the amounts do not change correctly. Expected Results: I would think the amounts would stay with the transactions. This could be operator. I may be missingg something. Thanks for your help.
Seems to work OK for me. Could you attach a screenshot of how the sort options appear?
As far as I remember (I have not tried again at this time) the sorting actually does work correctly. However, the balance column is always created from top to bottom, so it only makes sense if the sort is by ascending date first. I believe this has actually been discussed in the past on the developers mailing list. I probably should have filed a wishlist, but do not remember doing so.
Which column(s) do you mean by amounts? Please keep in mind, that the balance column is calculated by taking the current sum of all balances and the subtracting from the end of the ledger (no matter what date sort option is used).
The balance column, as Thomas said, is always computed from top to bottom. This is not a bug, at most it could be wish but it would have to be properly specified. Does the balance makes sense in any other sort order than the date?
I think there are really two underlying issues here - first is the actual sort order, and separately, whether the resulting list is presented top to bottom or bottom to top. I would describe the current behavior as allowing the user to specify the sort order, which is always presented top to bottom, and balances are only displayed if the sort is primarily by date. (That may not be quite exact, but I think close enough for this discussion. Display of balance also depends on the presence of any filter.) If that is all correct, then this bug is really describing the designed behavior. We can either turn this into a wish list, or I can file a separate one, which I planned, but have not done. Summary of the wish: Separate whether to display the ledger from top to bottom or bottom to top from the actual sort order. Switching the direction is not the same as simply reversing the sort order: balances would still only be calculated by ascending date, but they could be displayed in either order.
*** Bug 393319 has been marked as a duplicate of this bug. ***
393319 also mentioned that the Group Headers in the ledger are not present when not sorting in the default order. Does anyone know if this can be converted to a Wishlist?
In my view, the balance column should always be available. The balance has to be calculated in chronological order. That is, for a row with a newer date, the balance column must refer to the row with the most recent earlier date, and the amount has to be calculated from that balance and the amount entered on the current row. It makes no sense to calculate the balance from top to bottom irrespective of sort order because then one row can show a date and a balance that does not match. There is an issue on how to calculate the balance when there are multiple rows with the same date. I suggest that, here, it makes sense to calculate it from top to bottom. I.e., here's my suggestion: 1. Sort order can be customized and the rows on the sheet are sorted in that way. 2. For calculation of the balance only, rows are sorted by (a) removing the "Date" sort key from the sort list if present, (b) if "Date" is sorted as descending, then reverting the order on each of the other sort keys, (c) making "Date" the first sort key, ascending or descending as specified in the sort (1), (d) then calculating the balance from the first row to the last row (if the Date key is ascending) or from the last row to the first row (if the Date key is descending). (e) The balance that is obtained in this way is shown in the rows that are sorted as in (1). I think we get the correct balances this way. The inversion of the other sort keys in (2.b) is so that the balance column is as sensible as possible when reading it in the final order. Alternatively, we could get rid of the balance column and show the balance on the separator headers. Then it would make sense (I think) to show the balances only if the sort order is with Date as the first key. Note that the balance has to be calculated from oldest to newest even if the sort order is from newest to oldest.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I'm reopening this, but changing it to a wishlist and updating the title to be more reflective of the actual issue. I think Comment 8 is still a good starting point for any discussions, if this ever does get implemented.
Created attachment 126491 [details] testcase > Transactions will change but the amounts do not change correctly. With the appended testcase I cannot reproduce this issue (tested with 4.8.4)
> With the appended testcase I cannot reproduce this issue The resulting balance is always the same ascending date sort order 23.11.2018 -50 01.01.2019 -100 29.02.2020 -333 balance:-483 descending date sort order 29.02.2020 -333 01.01.2019 -100 23.11.2018 -50 balance:-483
> The resulting balance is always the same >Jack wrote: However, the balance column is always created from top to bottom, Adding the balance column there is ascending date sort order date amount balance 23.11.2018 -50 -50 01.01.2019 -100 -100 29.02.2020 -333 -483 balance:-483 This looks correct if I expect the balance column to be calculated by adding the individual amounts from top to bottom. descending date sort order date amount balance 29.02.2020 -333 -333 01.01.2019 -100 -433 23.11.2018 -50 -483 balance:-483 This looks correct if I expect the balance column to be calculated by adding the individual amounts from top to bottom. But it does not look correct if I expect that the values in the balance column will not change and which is shown as mentioned below. date amount balance 29.02.2020 -333 -483 01.01.2019 -100 -150 23.11.2018 -50 -50 balance:-483
(In reply to Ralf Habacker from comment #14) > Adding the balance column there is > > ascending date sort order > date amount balance > 23.11.2018 -50 -50 > 01.01.2019 -100 -100 > 29.02.2020 -333 -483 > balance:-483 This need to be: ascending date sort order date amount balance 23.11.2018 -50 -50 01.01.2019 -100 -150 29.02.2020 -333 -483 balance:-483
Created attachment 126532 [details] testcase for same dates > There is an issue on how to calculate the balance > when there are multiple rows > with the same date This is a test case for this issue
In only get a stable ascending and descending ordering by using the following sort fields: 1. post date 2. entry number
(In reply to Ralf Habacker from comment #17) > In only get a stable ascending and descending ordering by using the > following sort fields: > > 1. post date > 2. entry number This corresponds to the sort keys and the order the transaction report uses by date in the ascending case. Sorting the transaction report by date in descending case (start date after end date) does not work.
Git commit 080f9fbe3803763ddeac9d8a3e0a64a6a18118ef by Ralf Habacker. Committed on 02/04/2020 at 17:26. Pushed by habacker into branch '4.8'. Only display balances in the ledger view if the primary sort order is ascending by date, to avoid incorrect values M +13 -1 kmymoney/widgets/register.cpp M +2 -0 kmymoney/widgets/register.h https://commits.kde.org/kmymoney/080f9fbe3803763ddeac9d8a3e0a64a6a18118ef
Git commit f7157642ff2e16def6dad4c20c791c642a44d9cb by Ralf Habacker. Committed on 02/04/2020 at 17:33. Pushed by habacker into branch '4.8'. Correction of the balance display when sorting by date in descending order M +3 -2 kmymoney/views/kgloballedgerview.cpp https://commits.kde.org/kmymoney/f7157642ff2e16def6dad4c20c791c642a44d9cb
Git commit c1fffaff3f0f356c26db10db81cfd2f9d69f7ff7 by Ralf Habacker. Committed on 02/04/2020 at 17:33. Pushed by habacker into branch '4.8'. Display the balance only if the primary sort sequence is the post date Other combinations are not yet checked. M +5 -1 kmymoney/views/kgloballedgerview.cpp https://commits.kde.org/kmymoney/c1fffaff3f0f356c26db10db81cfd2f9d69f7ff7
There are also collisions with the display of scheduled transactions when enabled. I have scheduled transactions with a post date of 2021-01-01. A transaction has been submitted to the bank on 2020-31-12-17:30. On the bank statement it is displayed to be processed at 2021-01-04 Ordering by date will give the following display 2021-01-01 scheduled transaction 1 2021-01-01 scheduled transaction 2 2021-01-01 scheduled transaction 3 2021-01-04 transaction submitted at 2020-12-31-17:30 with an incorrect balance.
Git commit 8895aa06d8fcf9e2457e3f9598fc9db3ab2a433a by Ralf Habacker. Committed on 24/10/2021 at 21:22. Pushed by habacker into branch '4.8'. Revert partial commit 080f9fbe3803763ddeac9d8a3e0a64a6a18118ef It breaks transaction display in payee and tag view. M +1 -6 kmymoney/widgets/register.cpp https://invent.kde.org/office/kmymoney/commit/8895aa06d8fcf9e2457e3f9598fc9db3ab2a433a