Batch/scheduled transactions

[John Ralls]

On Jan 1, 2014, at 7:22 AM, PK <fourteenone at gmail.com> wrote:

> 
> > > If after entering the data in the TX split row, instead of hitting enter, I click back to the top TX description row, the values stay and I get a new TX split row below and can enter values (after which, hitting enter works fine).
> 
> > I do see that in Windows, and it’s slightly different from OSX, where hitting enter in the first split takes you to the second split, but in general the rule in GnuCash is “don’t hit enter when creating a transaction until you’re done”. You can use the tab key to move between fields and splits so you need not take your hands from the keyboard.
> 
> Noted, thanks. I think I wasn't expecting that since I had 2.4.13 on another computer first and enter moved the cursor to the next split.
> 
> 
> > > However, at this point, if I try to hit 'OK' to save and close it, I get "The Scheduled Transaction Editor cannot automatically balance this transaction. Should it still be entered?”
> 
> > Which is what you’d expect, right?
> 
> Yes, expected as long you understand what it means :) If it shows up the first time using a new piece of software (and the first time using any real accounting software), then it isn't entirely obvious. Perhaps an alternate (or additional) message on that dialog could be "A potential imbalance in debits and credits was found." Or just a short list of some of the potential conditions that can cause that warning. Mostly just benefiting new users (myself). If you've been in and around the software for any length of time, it's probably less of an issue.
> 
> 
> > > If I create the SX without hitting enter (click above the row, then enter the 2nd half of the entry (one row for credit, one row for debit) it'll save and run it, but when looking at the general ledger at that point, it just shows a long hex value in the account field for both rows and the funds in/out and both blank.
> > >
> > > It seems that hitting enter in the SX edit form saves the row, but hides it (creating the imbalance if the second row wasn't entered with the matching credit/debit).
> 
> > It seems that if the transaction isn’t complete, it hides the whole transaction and presents a new, blank transaction, which is why it seems to disappear. I’ve managed to make an SX with three transactions, two of which are single-split and one of which is a proper two-split transaction. Even when I close and reopen the editor the single-split transactions don’t appear, but when the SX runs it creates all three transactions in the normal registers. Everything in those transactions looks normal, including in the GL. This on Win7-64.
> 
> What constitutes a "complete transaction"? A matching credit/debit? If you create a single split transaction that it hides because it's incomplete, is there any way to get to it to edit it and fix it?

I haven't explored that enough yet to know all of the cases that cause the transaction to get hidden, so I'll give the generic answer: In GnuCash, a complete transaction is one that balances. If it doesn't balance, GnuCash will add another split to an imbalance account to complete it. That isn't done for SXes, though; it's done on the "real" TXN that results from running the SX.

Once the transaction is hidden there seems to be no way to get to it, and in my view that's the crux of the bug. It's very strange that that should happen only on Windows, it doesn't seem like
the sort of code that would be special-cased by OS.

Regards,
John Ralls