I just created a minimal data file with a minimal chart of accounts. I created a Utility Bill for $10, dated it the beginning of the month. After I entered it I scheduled it to recur weekly.

I chose Scheduled Transactions --> Since Last Run

the transaction showed up as "To Create."

I set it to "Postponed."

I chose Scheduled Transactions --> Since Last Run

The transaction showed as Postponed.

I quit the application and restarted it.

In this situation, the transaction still shows up as Postponed, however it shows the effective date as 12/31/1969.



I just noticed messages on the console when I open a copy of my regular data file (where the postponed transactions are missing). I don't get any unusual messages when I open my minimal TEST data file.

For the copy of my regular data file, I get the following messages on the console:


This is a development version. It may or may not work.
Report bugs and other problems to gnucash-devel@gnucash.org.
You can also lookup and file bug reports at http://bugzilla.gnome.org
The last stable version was GnuCash 2.4.10
The next stable version will be GnuCash 2.6

Found Finance::Quote version 1.17
<sx:deferredInstance>
    <sx:rem-occur>160211524</sx:rem-occur>
    <sx:instanceCount>168298164</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>161922732</sx:rem-occur>
    <sx:instanceCount>0</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>1667457325</sx:rem-occur>
    <sx:instanceCount>161677428</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>167353276</sx:rem-occur>
    <sx:instanceCount>161085780</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>1953524082</sx:rem-occur>
    <sx:instanceCount>7237481</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>167611476</sx:rem-occur>
    <sx:instanceCount>161217268</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>161993860</sx:rem-occur>
    <sx:instanceCount>162576068</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>0</sx:rem-occur>
    <sx:instanceCount>169057740</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>161467684</sx:rem-occur>
    <sx:instanceCount>161849396</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>159216948</sx:rem-occur>
    <sx:instanceCount>0</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>155283660</sx:rem-occur>
    <sx:instanceCount>0</sx:instanceCount>
  </sx:deferredInstance><sx:deferredInstance>
    <sx:rem-occur>166798124</sx:rem-occur>
    <sx:instanceCount>0</sx:instanceCount>
  </sx:deferredInstance>

Another data point... I made a FRESH copy of my actual gnucash data file with up-to-the-minute data and the above messages are gone. I suspect that whatever is going on with the missing scheduled transactions gets zeroed out after running the since-last-run and save process more than once. 

I will try to save a copy of the data file that created the messages above in case it's useful.

Sounds to me that you're experiencing the same issue that I had reported in Bug 543212 but your transactions disappear into the past while mine were set to future dates.  As a workaround I never set my TX to 'Postponed' anymore, instead I'm setting them back to 'Reminder' which does work as expected.

@Volker Englisch: the past/future issue may be somewhat of a red herring here -- I am not an experienced programmer but when I see a 1969 date in Linux I believe it indicates a data storage issue -- I believe it means the stored digit representing the date is a small negative number. It might as well be hundreds or thousands of years in the future -- the bits all rolled over to zero or a negative number. Especially if you are running Windows or Macintosh (I couldn't tell immediately from your bug report), the underlying data may be being stored the same way in the data file but what to you is a future date on Windows or Macintosh for Linux could be a 1969 date.

OH and I didn't mention before -- I am using the "standard" XML data file, and you (Volker Englisch) may be using SQLite or another database for your storage. That could explain a difference in the way dates are displayed.

On my "actual" data (as opposed to the clean test file I created that shows the 1969 date) the Postponed items disappear from view on the next application launch, but I get messages on the console that seem to indicate they're still around. Then (apparently) on future launches they get purged, possibly by a separate process. (Possibly there's a sanity check on the XML data that automatically purges garbage data? I really don't know; I'm just speculating.)  

I looked through the sx code enough to see that it would take me a few hours to diagram out how the statuses get set and stored, but mostly because I'm not an experienced C programmer.

(In reply to comment #4)
> OH and I didn't mention before -- I am using the "standard" XML data file, 

So am I running on Ubuntu 11.10.

SO we're both on Ubuntu, so that doesn't explain the date differences! (THAT would be too easy, wouldn't it! There COULD be a library difference between 10.04 and your 11.10, but my next upgrade on that system will be to Ubuntu 12.04 LTS.)

It sounds like there may be serious problems with the SX logic and/or how the data gets stored or represented in memory. Logically there shouldn't be any difference between the scheduled transactions in a newly-created minimal data file versus my gigantic file with transactions going back many years. But there seems to be.

I have not yet dug in to look at the actual XML that's getting stored on disk, but that's next, as soon as I get a chance. I'll also review Bug 543212 and see what I can replicate on mine. 

I suspect you are right and we ARE seeing consequences of the same underlying bug.

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.

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 ***

Reassign version to 2.4.x so that individual 2.4 versions can be retired.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=677651. Please update any external references or bookmarks.