Created attachment 154026 [details] System info and problem screenshots SUMMARY *** I am trying to print out an account transaction list that INCLUDES future transactions that are listed in gray due to the scheduler. No current report template seems to have that ability. Even if I choose a date range like "next 3 months" all report transactions stop at today. I would prefer to not "enter next transaction" because it hasn't entered yet, which is the point of the scheduler. Again: - not a list of scheduled transactions - not a forecast *** STEPS TO REPRODUCE 0. Use AppImage file for application 1. Have transactions entered for the past 3 months and "confirmed." Not sure what term to use here, but "Cleared" or "Reconciled" doesn't matter here. 2. Have scheduled transactions that fall within the next 3 months, but DO NOT add them (enter next transaction function). They should remain gray from the scheduler, not turn white as if they were cleared entries. 3. Open any transaction report (ex: transactions by account) 4. Configure the report filters for the relevant account and date range "Last 3 to Next 3 months" 5. Run the report OBSERVED RESULT Filtered transactions listed STOP at today's date. Nothing scheduled beyond today appears in the report. EXPECTED RESULT Scheduled transactions beyond today's date (within the specified date range) should be listed in the transaction list. OR have a flag in the report config to include scheduled transactions or not. SOFTWARE/OS VERSIONS Linux Mint, info in attached doc KDE Plasma Version: N/A KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION I have attached a document with an example. It shows the end of my account with a few transactions from today and scheduled ones as well. Then it shows the transaction report that stops. There are 3 items listed beyond today (Nov 25) because they are "confirmed" entries, but the others do not.
This is a valid wishlist. The underlying issue is that scheduled transactions in the future are not really transactions until they are entered into the ledger. They are shown in the ledger due to special handling which is only used in the ledger, not anywhere else. I'm not sure how much effort it would be to include these transactions in reports, but I suspect it is far from trivial, and thus unlikely to be implemented in the near future. It would not only require generating the "pseudo-transactions" (I just invented that term) but also finding a way to differentiate them from "real" transactions. Depending on the report, you then also have to be careful if they might affect any totals shown.
Created attachment 154245 [details] attachment-10203-0.html Hi Jack, Hoping that replying on my phone gets to you. Will check later. Suggestion for implementation: what about tagging those "ghost" transactions with a new status code "S" for Scheduled to go along with Cleared and Reconciled? Hopefully it would reduce the overall reporting rework as it's just an additional option to an already existing field. Just a suggestion. Thanks for getting back to the inquiry. Jesse Geiger From an Android's Outlook ________________________________ From: Jack <bugzilla_noreply@kde.org> Sent: Friday, December 2, 2022 5:19:09 PM To: JesGeiger@outlook.com <JesGeiger@outlook.com> Subject: [kmymoney] [Bug 462246] Report Future Transation LIST https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.kde.org%2Fshow_bug.cgi%3Fid%3D462246&data=05%7C01%7C%7C3dbb0a237e8f4e92560608dad4b33ce8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638056163549711708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y8HnS7EmywPzMFpJXZLUoQNYg9AvFvZPGFwsGgRsVus%3D&reserved=0 --- Comment #1 from Jack <ostroffjh@users.sourceforge.net> --- This is a valid wishlist. The underlying issue is that scheduled transactions in the future are not really transactions until they are entered into the ledger. They are shown in the ledger due to special handling which is only used in the ledger, not anywhere else. I'm not sure how much effort it would be to include these transactions in reports, but I suspect it is far from trivial, and thus unlikely to be implemented in the near future. It would not only require generating the "pseudo-transactions" (I just invented that term) but also finding a way to differentiate them from "real" transactions. Depending on the report, you then also have to be careful if they might affect any totals shown. -- You are receiving this mail because: You reported the bug.
The suggestion to mark the transaction with an S is a good idea, nevertheless the problem lies in the fact that they don't exist as such in the journal which is the reason they don't show up in the reports. Adding them to the reporting engine would be a larger change.