Scheduled transaction issue

John Ralls jralls at ceridwen.us
Tue May 1 11:31:57 EDT 2012


On May 1, 2012, at 4:30 AM, Donald Allen wrote:

> On Mon, Apr 30, 2012 at 10:41 PM, John Ralls <jralls at ceridwen.us> wrote:
>> 
>> On Apr 30, 2012, at 7:18 PM, Donald Allen wrote:
>> 
>>> On Mon, Apr 30, 2012 at 5:25 PM, Donald Allen <donaldcallen at gmail.com> wrote:
>>>> On Mon, Apr 30, 2012 at 3:57 PM, John Ralls <jralls at ceridwen.us> wrote:
>>>>> 
>>>>> On Apr 30, 2012, at 8:20 AM, Donald Allen wrote:
>>>>> 
>>>>>> My gnucash data is sitting in postgres on a Linux system. I normally
>>>>>> access it by running gnucash (2.4.10) on the same system. I have a
>>>>>> number of scheduled transactions that are set up to happen near the
>>>>>> end of every month. A number of those transactions got recorded
>>>>>> yesterday, as a result of my running gnucash.
>>>>>> 
>>>>>> My wife runs Windows 7 on her laptop, and I've installed gnucash
>>>>>> 2.4.10 on her machine. I've pointed it at the postgres server on the
>>>>>> Linux machine mentioned above. This setup is new (I had previously
>>>>>> been working with .xml files). She and I were just working on her
>>>>>> machine, looking at some financial matters with gnucash. But when I
>>>>>> started gnucash on her machine, it offered to enter the same scheduled
>>>>>> transactions that had happened yesterday when I ran gnucash on my
>>>>>> Linux box. I declined the offer, of course, and then verified that I
>>>>>> was seeing the transactions that had been entered yesterday on the
>>>>>> Linux system. They were there. This feels like a bug, a serious one.
>>>>>> 
>>>>>> Thinking about what might cause this incorrect behavior makes me
>>>>>> wonder where the information about what scheduled transactions have
>>>>>> been run is stored. Is it stored in the database itself, as I would
>>>>>> expect, since the fact that the transactions have been entered is a
>>>>>> property of the data, not of a particular user or gnucash instance. Or
>>>>>> is it stored in individual home directories in, say, ~/.gnucash
>>>>>> directories (or whatever the analogous place is in the Windows world)?
>>>>>> If the latter, that would explain this behavior, but there are other
>>>>>> possible explanations, so I'm indulging in speculation here. So I'll
>>>>>> stop and turn this question over to people who actually understand the
>>>>>> code.
>>>>> 
>>>>> Odd indeed. The last-run date is stored in a normal table in the database and on my main accounts (kept in SQLite), it appears to be posted correctly.
>>>>> 
>>>>> Does "select name, last_occur from schedxactions;" produce sensible results?
>>>> 
>>>> Yes. Two transactions that it offered to enter today were entered on
>>>> 2012-04-28. Bizarre. I just tried it on another Windows 7 laptop and
>>>> got the same result as I did with my wife's machine -- it asked me to
>>>> allow it to enter transactions that were entered on 4/28. This is is a
>>>> bug. I will try this with a Gnucash instance running on Linux, but
>>>> pointed at the same database server as the Windows machines, to see if
>>>> this is Windows-specific.
>>> 
>>> I just repeated the experiment on the same laptop I referred to in the
>>> above paragraph (it's setup dual-boot), and running gnucash 2.4.10
>>> pointed at the same remote database on Linux does *not* produce the
>>> symptom I reported, i.e., it does not incorrectly offer to enter
>>> scheduled transactions that have already been entered. This appears to
>>> be a Windows-specific problem.
>>> 
>>> Any ideas?
>> 
>> Interesting. That's two M$Win-only  SQL problems in a week. That's a major PITA just because debugging in M$Win is 10 times harder than on unix.
>> 
>> No, no ideas at the moment. You'd better file a bug so that I don't forget about it.
> 
> I did some more on this this morning, and I now believe this is not a
> problem. I think it was a combination of my not reading carefully
> enough and what, in my opinion, is a questionable bit of UI design.
> 
> As I mentioned previously, I have a number of monthly scheduled
> transactions that get tripped towards the end of the month. Because
> they represent occurrences that don't all happen at exactly the same
> time, the dates on which they fire are not exactly the same in all
> cases. What fooled me was that gnucash presents *all* the scheduled
> transactions in the pop-up, with an additional annotation (which is
> what I failed to read, several times, I'm embarrassed to say) that
> indicates the particular transactions that it wants to enter. In fact,
> it was not offering to enter transactions that had already been
> entered.
> 
> Clearly this was mostly my error. But I think it does call into
> question the wisdom of displaying all scheduled transactions in the
> pop-up. Why not just display only those that are scheduled for entry
> at that moment? The rest is irrelevant and can confuse a user, which
> is exactly what happened to me.
> 
> Anyway, one less debugging task for you, John. Sorry for the spam.
> I'll close the bug report I entered.

Ah, I wondered about that. I have the schedxes set to just happen -- in my case they don't need adjustment -- so the "since last run" box is purely advisory for me.  I think it's useful for the user to be informed that schedxes have fired, but that part is a preference, so you can turn it off. I agree that if there are decisions to be made that they should be set apart in some way from the transactions which have already fired.

Thanks for following through and sorting out the problem. 

Regards,
John Ralls




More information about the gnucash-user mailing list