#165 In jGnash 1.x, "Debit" and "Credit" tabs mislabeled

Tom Edelson

In jGnash 1.x (at least), every account register window (except for accounts of type Investment or Mutual Fund) has a set of tabbed panes at the bottom: the user selects one of the tabs in order to specify the type of transaction to be created (or more precisely, the type of entry to be made to this account by the new transaction to be created). In accounting terms, you are selecting whether the transaction will create a debit or a credit to this account.

The program has an option called "use accounting terms";l if this option is selected, then the tabs will actually be labeled "Debit" and "Credit" (as will the two columns for debit or credit transaction amounts, at the top of the register), rather than something more specific to the account type, such as "Deposit" and "Withdrawal" for bank accounts.

The problem is that with "use accounting terms" selected, and for accounts of type Liability, Credit (meaning credit card), Equity, and Income, the tabs for the different entry panes are mis-labeled: the "Credit" tab is to the left of the "Debit" tab. This is wrong for two reasons:

1, Visually, it looks wrong because the tabs are not in the same order as the column headings above: for the latter, "Debit" is always to the left of "Credit", as is apparently usual in accounting practice.

2. More fundamentally, if you create a transaction after clicking on the "Debit" tab, it actually creates a credit entry to this account, and vice versa. Which means that the tabs to create debit and credit entries actually are in the same order as the column headings (debit on the left); it is only the labels on the selection tabs which are wrong.

This problem used to be present in jGnash 2.x also, but it has already been fixed there (at least for Liability, Credit, and Income accounts: it may still be wrong for Equity accounts).

For Liability and Credit accounts, this problem was fixed in a commit dated 2009-10-23, which created revision 1843, and which fixed bug number 2,770,638.

For Income accounts, it was fixed in a commit dated 2010-02-24, which created revision 2077, and which apparently had no Tracker artifact associated with it.


  • Tom Edelson

    Tom Edelson - 2010-05-17

    The fix is in method "getCreditDebitTabNames (Account account)" of class jgnash.ui.register.RegisterFactory.

    The fix actually simplifies the code for this method: now, once it has been determined that accounting terms are being used for labels, it is not necessary to have any more conditionals based on the AccountType: after all, the tab labeled "Debit" should *always* be on the left.

    The difficulty was in convincing myself that the fix actually could be this simple. This was difficult because the Javadoc for the method was wrong (or, at least, misleading). Before the fix, it said:

    @return tab names with increase at 0 and decrease at 1

    which I took to mean that the label in position 0 (of the array of strings returned by the method) needed to be the one for creating a transaction which would increase the balance in this account. In other words, I thought that the ordering of the strings, in the result from this method, would actually determine which tab would create a debit entry, and which a credit entry.

    By looking at the places where this method is called, I convinced myself that this is not true. The result from this method has no effect on what the left and right tabs actually do: only on the labels given to the tabs themselves. The @return tag in the Javadoc for the method should have said, and now does say:

    @return tab names as array of two strings;
    the one at position 0 will appear on the left, the one at position 1 on the right

  • Tom Edelson

    Tom Edelson - 2010-05-17
    • status: open --> closed
  • Tom Edelson

    Tom Edelson - 2010-05-17

    P.S. This bug was fixed by the commit which created revision 2130 in the Subversion repository for jGnash.
    This commit was done today.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks