After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729065 - The Since Last Run Assistant fails with postponed transactions
The Since Last Run Assistant fails with postponed transactions
Status: RESOLVED DUPLICATE of bug 672760
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
2.4.x
Other Windows
: Normal major
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2014-04-27 15:50 UTC by David Carlson
Modified: 2018-06-29 23:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Carlson 2014-04-27 15:50:35 UTC
The Since Last Run assistant does not handle postponed transactions correctly.  
I would expect that a transaction marked postponed in the dialog would simply reappear in the next execution of the dialog with same scheduled entry date, but it actually appears with seemingly random entry dates, some of which are 0/0/00 or thousands of years in the future.  Then there is way to correct the dates.

The best work-around I have found is to stop between Since Last Run sessions and edit the scheduled transactions with adjusted start date and number of remaining transactions since that count is also incorrect if used.  However, this does not always work, and if a transaction is scheduled but only appears with a date of 0/0/00 available to enter in the Since Last Run dialog, that will crash GnuCash.

Ignored entries seem to be gone in the next instance of the Since Last Run, but they do not respect the date scheduled in the dialog. They do seem to reduce the remaining count as expected.

I tested this by entering a transaction dated a month in the past to enter weekly.  I set them with no reminder or automatic entry and 11 total entries.

Then the Since Last Run dialog scheduled an entry for each week before today's date, which I changed to postponed for dates after the first scheduled date.

Re-running S L R produces corrupted dates and incorrect counts remaining.

This is in release 2.4.13 on a Windows 7 system.
Comment 1 Geert Janssens 2015-02-11 10:18:37 UTC
This may be a duplicate of bug 672760 which will be fixed in 2.6.6.

Windowws users could already test this by downloading and installing a recent nightly build from http://code.gnucash.org/builds/win32/maint/

Or if you know how to build gnucash on linux, you can build the maint branch to run the same test.
Comment 2 John Ralls 2015-09-21 23:00:39 UTC
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 672760 ***
Comment 3 John Ralls 2017-09-24 22:47:12 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 4 John Ralls 2018-06-29 23:30:27 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=729065. Please update any external references or bookmarks.