Batch/scheduled transactions

PK fourteenone at gmail.com
Wed Jan 1 10:22:52 EST 2014


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


------
Any sufficiently advanced bug is indistinguishable from a feature.


On Tue, Dec 31, 2013 at 3:16 PM, John Ralls <jralls at ceridwen.us> wrote:

>
> On Dec 31, 2013, at 11:06 AM, PK <fourteenone at gmail.com> wrote:
>
> > Follow-up to #3
> > I reinstalled 2.6 and I do not see the issue when using the General
> Ledger. I do still see the issue when creating SX.
> >
> > Open Scheduled Transaction Editor. Click New. Enter name "Test SX 001",
> leave default options on Overview and Frequency. On Template Transaction
> tab, there are two green rows (with Date, Num, Description, Tot Funds In,
> Tot Funds Out {no fields are editable}) and the cursor is in the yellow
> rows just below (with Scheduled, Num, Description, Tot Funds In, Tot Funds
> Out, and Notes). I can enter values into the Num, Description, and Notes
> fields. I click into the blank TX split row below and the top green rows
> change (to Action, Memo, Account, R, Debit Formula, Credit Formula) and I
> can enter values into the (now yellow, single row I clicked in). I enter
> values for Memo, Account, Debit and hit enter and the values are cleared
> blank again (on the whole panel).
> > 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.
>
> > 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?
>
> > 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.
>
> >
> > Let me know if that's enough info to go on or if you need more info or
> want me to try something else.
>
> I think that does it. I’ve opened
> https://bugzilla.gnome.org/show_bug.cgi?id=721290 to keep track of the
> problem.
>
> Regards,
> John Ralls
>
>


More information about the gnucash-user mailing list