[GNC] Confusing and inconsistent headers in transaction entry and report forms

Tue Aug 16 15:46:44 EDT 2022

Hi, here is THE ANSWER. It is a Guncash bug.

The previous report was obtained on MacOS 11.6.8 (Big Sur). This gave the
credits and debits mislabeled in the transaction report.

I have access to another mac running 10.16.2 (Catalina). Running the SAME
version of Gnucash (4.11) on the SAME dataset that I used for my single
text transaction, the transaction report, which is attached, is correct.
Debits and credits are reported in the correct columns.

Thus, Gnucash works properly in Big Sur but not in Catalina, at least for
the sub-versions I have access to.

For all I know, in subsequent versions of MacOS, things might again work,
but the two macs I have access to are both at the most recent versions of
MacOS that the respective hardware permits.

-P.

On Tue, Aug 16, 2022 at 1:55 PM Peter S. Shenkin <shenkin at gmail.com> wrote:

> As an experiment, I started a band new Gnucash file for test purposes. I
> entered a single transaction. I am attaching a view of the register, a
> Transaction report and a Balance sheet.
>
> You can see that the same thing is happening that happened before:
>
>    - Register view shows that the checking account was debited.
>    - Balance sheet shows that the checking account, which started at 0,
>    now has a positive balance.
>    - Transaction report shows that the column labeled "Credit" shows
>    debits and the column labeled "Debit" shows credits, which is backwards.
>
> Thus, I think it is clear at the very least that the problem did not arise
> from the switch from 4.6 to 4.11. I also think it shows that I am not doing
> anything wrong, but please correct me if you disagree.
>
> I would look forward to suggestions.
>
> -P.
>
>
> On Tue, Aug 16, 2022 at 1:46 PM Peter S. Shenkin <shenkin at gmail.com>
> wrote:
>
>> Hi, David,
>>
>> On the balance sheet, everything is correct; the sums reflecting the
>> balances of the various real accounts are correct and in agreement with the
>> bank statements; in other words, they reconcile. I also demonstrated this
>> in the very first screen shot I sent when I started the case, the shot of
>> the transaction viewed in the register. In this image, you can see that a
>> debit to a cash account properly increased the cash balance. So I do not
>> see how it is possible to conclude that the transactions were in any way
>> entered incorrectly.
>>
>> It is only in the transaction report where the debits are mislabeled as
>> credits and vice versa.  I do not see how this could be the fault of the
>> way I entered the transactions, which modify the account balances concerned
>> in the proper manner.
>>
>> I understand that there are other ways of entering transactions. But you
>> did say, regarding the way I entered them, that "this works". In fact I
>> think the information in the first paragraph above validates the stronger
>> assertion that "this, in fact, has worked properly for my transactsions." .
>> But if you see a way I could possibly be wrong about that, please do
>> suggest what it might be.
>>
>> I agree that nobody we have heard from has had the same problem. But
>> there it is. If you have a suggestion for anything I might try that could
>> cast light upon this, please do let me know.
>>
>> One more thing. IIRC, I originally created the account using Gnucash 4.6
>> and later switched to 4.11. But I do not know whether the same problem
>> appeared when I was using 4.6. I'm skeptical whether this could be involved.
>>
>> Best,
>> -P.
>>
>> On Thu, Aug 4, 2022 at 3:18 AM <davidcousens49 at gmail.com> wrote:
>>
>>> On Wed, 2022-08-03 at 20:28 -0400, Peter S. Shenkin wrote:
>>> > Adrian,
>>> >
>>> > I do have full account names turned on. I forget where I did that. I
>>> have
>>> > no customized sort that affects the order of accounts within a
>>> transaction
>>> > in either register view nor in the transaction report. (I prefer to
>>> sort
>>> > the transactions by date in the transaction report, but that's just
>>> me.)
>>> >
>>> > You point out correctly that in the register view, where transactions
>>> are
>>> > entered, each line of the transaction (which is shown completely in my
>>> > screen shot) shows the debit first (on the left) and credit second, as
>>> is
>>> > customary. I had the labeling of the columns set to the out-of-the-box
>>> > defaults of Increase and Decrease, respectively. This is highly
>>> misleading,
>>> > because in fact both of these accounts increase as the result of the
>>> > transaction. I later changed the labels to Debit and Credit, an
>>> available
>>> > option, which is less misleading, but other than the labels, the
>>> > transaction looks exactly the same in both the account register and the
>>> > transaction report. That is, the Credit and Debit labels are still
>>> reversed
>>> > in the transaction log.
>>>
>>> Peter,
>>>
>>> This seems to be counter to everyone else's experience with GnuCash and
>>> definitely is not what occurs in the transaction report in GnuCash 4.11
>>> on Linux
>>> Mint 20.3.  I suspect if it was occurring specifically on either a
>>> MacOSX or
>>> Windows systems we would have a large number of experienced users (and
>>> some of
>>> us are accountants and pretty pedantic about such aspects) complaining
>>> pretty
>>> loudly.  So we need to work out why your experience is completely
>>> opposite to
>>> everyone else's or whether it is just a misinterpretation of what is
>>> being
>>> displayed in the transaction report. In the transaction Report options
>>> there is
>>> an option in the Display tab to display one transaction per line or one
>>> split
>>>  per line.  Using the second option one split  per line, both debit and
>>> credit
>>> entries for the transaction will be displayed  but entries not to the
>>> accounts
>>> selected in the transaction report will be in the second(and subsequent
>>> lines
>>> for transactions with more than two splits) and the different selected
>>> account
>>> entries will be listed in sections with the account name at the head. The
>>> transaction report is possibly the most general of the reports and is
>>> highly
>>> customizable from the report options
>>>
>>> >
>>> > You seemed to express uncertainty about the account register. The way I
>>> > enter transactions is to pick an account (for instance, by clicking on
>>> it
>>> > in a balance sheet). That opens the register tab, set to that account.
>>> If I
>>> > am remembering correctly, it will always list that account on the first
>>> > line of the transaction, then you can add your currency total in
>>> either the
>>> > Debit or the Credit column for that account. For the balancing account
>>> or
>>> > accounts (in the case of a split), you similarly enter the currency
>>> total
>>> > for each account on a succeeding line, in either the debit or the
>>> credit
>>> > column, and select the account from a pulldown you can invoke from that
>>> > line.
>>>
>>>
>>> While this works, A balance sheet, depending on the report options may
>>> not show
>>> all the accounts in your chart of accounts so it is limiting in which
>>> accounts
>>> you can choose to open. How you open the register tab for an account
>>> does not
>>> affect the order of display of the lines as it invokes the same routine
>>> to open
>>> the register. Double clicking on the icon for the account (looks a bit
>>> like the
>>> front of a colonial bank) in the Accounts tab will give you access to
>>> all non-
>>> hidden accounts (hidden accounts can be found with the Edit->Find Account
>>> dialogue).
>>>
>>> >
>>> > There is no specified order in the register view for the accounts
>>> involved
>>> > in a transaction; the account you selected to open the tab will always
>>> be
>>> > listed on the first line nd the succeeding lines will appear in the
>>> order
>>> > in which you entered them.
>>>
>>> This is not necessarily the case. If you open an existing transaction in
>>> an
>>> asset register in either Auto-split or Transaction Journal mode if it is
>>> a
>>> credit transaction to the asset register (eg a bank account), the entry
>>> to the
>>> account for the register which is open will appear on the last line not
>>> the
>>> first. On the other hand if it is a transaction which debits an open
>>> asset
>>> account register it will appear first. I.e. the debit components of the
>>> transaction is listed in the lines before the credit components in all
>>> cases.
>>>
>>> When you are entering a new transaction, if you do not specifically
>>> select an
>>> account in the Account column where "Account "is displayed in Italics in
>>> the
>>> first split entry, GnuCash will assume that it is the account of the
>>> register
>>> that is open (but you can explicitly select another account for the
>>> first line,
>>> in which case you have to explicitly select the account associate with
>>> the
>>> currently open register in another line of the transaction to complete
>>> the
>>> transaction. If you leave a subsequent line blank and press enter the
>>> transaction will not be saved in the register.
>>>
>>> You can also actually enter a transaction affecting any set of accounts
>>> from
>>> within a register which is not associated with any of those accounts as
>>> long as
>>> the debits and credits sum to zero just as you can edit the accounts in a
>>> register and change the account in a split to the account of the open
>>> register
>>>  to any other account  which will shift that split of the transaction to
>>> the
>>> other account and it will then display in the register for that account
>>> when it
>>> is opened.  This is quite often used with imported transactions which are
>>> assigned to the wrong account to correct the transaction without
>>> reimporting the
>>> transaction.
>>> >
>>>
>>>
>>> David Cousens
>>> > I'm pretty new to Gnucash (or is it gnu to Newcash?), so maybe there is
>>> > another way of entering transactions, but this is the one I know.
>>> >
>>> > -P.
>>> >
>>> > On Tue, Aug 2, 2022 at 2:51 AM Adrien Monteleone <
>>> > adrien.monteleone at lusfiber.net> wrote:
>>> >
>>> > > I took another look at your initial report screenshot.
>>> > >
>>> > > It is correct and *not* reversed.
>>> > >
>>> > > There are some parts of it missing, but you can see them in my
>>> > > screenshot version.
>>> > >
>>> > > The main difference otherwise in our two reports is that you've
>>> listed
>>> > > the Donations transaction first and the Checking transaction after.
>>> (not
>>> > > sure how that worked out, because I thought they appear in their
>>> order
>>> > > in the Account Tree, but I guess you have a customized reversed
>>> sorting
>>> > > order in Options > Sorting > Primary Sort Order > Descending.
>>> Default is
>>> > > Ascending)
>>> > >
>>> > > The first line then, is from the perspective of the Donations
>>> account.
>>> > > In that account, the amount is a credit and that is what the report
>>> > > shows, with the transfer account being Checking.
>>> > >
>>> > > The second line is from the perspective of the Checking account, and
>>> > > that amount is a debit (also correctly shown) with the transfer
>>> account
>>> > > being Donations.
>>> > >
>>> > > I can't find an option to turn off the Account name. I'm guessing you
>>> > > copy/pasted the lines or blocked out that part resulting in missing
>>> labels.
>>> > >
>>> > > Look at my screenshot again showing both accounts ,and the extra
>>> labels
>>> > > and info, which should make the report more clear.
>>> > >
>>> > > Regards,
>>> > > Adrien
>>> > >
>>> > > On 8/2/22 12:24 AM, Adrien Monteleone wrote:
>>> > > > Peter,
>>> > > >
>>> > > > Yes, I caught all of that.
>>> > > >
>>> > > > I'm referring to default options of the report - not GnuCash
>>> generally.
>>> > > >
>>> > > > If you have the report still open, close it.
>>> > > >
>>> > > > Now, run it again. Note, you shouldn't get anything at first
>>> except a
>>> > > > page telling you that you need to set options first, particularly
>>> to
>>> > > > choose accounts.
>>> > > >
>>> > > > Click the Options button on the toolbar, on the Accounts tab,
>>> select
>>> > > > only the Checking account. Set the date range however you like in
>>> the
>>> > > > General tab, but narrowing it down to the one day of the
>>> transaction
>>> > > > will remove cruft. Do not change any other report options.
>>> > > >
>>> > > > You should now see a list of transactions on that date affecting
>>> the
>>> > > > Checking account.
>>> > > >
>>> > > > Is it correct?
>>> > > >
>>> > > > Note, if you have only that one transaction, you should see only
>>> one
>>> > > > line in the report, not two.
>>> > > >
>>> > > > Now, edit the Options > Accounts again, and this time, select
>>> *both*
>>> > > > Checking & Donations and click Apply.
>>> > > >
>>> > > > Now, you should see separate sections of the report, one for each
>>> > > > account with subtotals and you'll see the same transaction twice,
>>> once
>>> > > > from the perspective of the Checking account, and the other from
>>> the
>>> > > > perspective of the Donation account.
>>> > > >
>>> > > > I've done a sample transaction with similarly named Asset & Revenue
>>> > > > accounts and attached screenshots of the register, the Transaction
>>> > > > Report with just Checking selected, and the Transaction Report
>>> with both
>>> > > > Checking & Donation accounts selected.
>>> > > >
>>> > > > If your report doesn't look exactly like this save for the specific
>>> > > > Description and amount, something is off.
>>> > > >
>>> > > > Regards,
>>> > > > Adrien
>>> > > >
>>> > > > On 8/2/22 12:05 AM, Peter S. Shenkin wrote:
>>> > > > > Hi, Adrian,
>>> > > > >
>>> > > > > My first image shows a single transaction (the "wepay to
>>> checking"
>>> > > > > transaction). But I separately pasted in the Checking balance
>>> from the
>>> > > > > previous transaction, which is not fully shown. I wanted the
>>> reader to
>>> > > > > see
>>> > > > > that indeed the transaction I did show raised the Checking
>>> balance. And
>>> > > I
>>> > > > > also pasted in the header line from the top of the page.
>>> > > > >
>>> > > > > I'm not sure which default/non-default options you are referring
>>> to.
>>> > > > > If you
>>> > > > > mean using Debit/Credit headers as register labels instead of
>>> > > > > Increase/Decrease, I tried it both ways and it didn't change the
>>> > > > > appearance
>>> > > > > of the transaction report.
>>> > >
>>> > > _______________________________________________
>>> > > gnucash-user mailing list
>>> > > gnucash-user at gnucash.org
>>> > > To update your subscription preferences or to unsubscribe:
>>> > > https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> > > If you are using Nabble or Gmane, please see
>>> > > https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>>> > > -----
>>> > > Please remember to CC this list on all your replies.
>>> > > You can do this by using Reply-To-List or Reply-All.
>>> > >
>>> > _______________________________________________
>>> > gnucash-user mailing list
>>> > gnucash-user at gnucash.org
>>> > To update your subscription preferences or to unsubscribe:
>>> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> > -----
>>> > Please remember to CC this list on all your replies.
>>> > You can do this by using Reply-To-List or Reply-All.
>>>
>>> _______________________________________________
>>> gnucash-user mailing list
>>> gnucash-user at gnucash.org
>>> To update your subscription preferences or to unsubscribe:
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> -----
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Transactions, MacOS 10.16.2 (Catalina).png
Type: image/png
Size: 22501 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20220816/96d08561/attachment-0001.png>