SOLVED! double clicking DURING RECONCILE goes to split ledger

[Tommy Trussell]

On Tue, May 3, 2016 at 11:14 PM, Ed Love <ed65love at gmail.com> wrote:

> Despite solving this, I'm wondering if the behaviour is ideal under the
> conditions that 'caused' my issue.
>
> What does the list think?
>
>         Ed
>

Ed:

I suspect very few folks are interested in this, so I apologize to those
who consider this "noise"... because I am about to tear this apart in
excruciating detail. I also apologize if I accidentally use the wrong
terminology; I try to be careful but I miss stuff.

I am not a GnuCash developer, but I do have some experience with software
development, and a few years of experience using GnuCash.

I believe there's a reason for the described situation, even if has an
undesirable side-effect. I also ended up with a suggested "wish list" item
(at the very end). See the "TL; DR" section there. Smarter folks than I
probably would have been able to jump straight to that conclusion, but I
had to think this through systematically in more detail. Oh, well.

Please, anyone, please free to correct any errors of fact; I welcome that
sort of criticism.

To reiterate --

---------------

When you reconcile an account in GnuCash,

IF, when you started the process, you checked the "Include subaccounts"
checkbox in the Reconcile information window (the one with the starting and
ending account balances), and

While reconciling that account, IF you double-click a transaction in the
"Funds in / Funds out" window, and

THEN when GnuCash displays the transaction, instead of displaying and
scrolling to the transaction in the register tab that's already open (as
would happen if "include subaccounts" checkbox is un-checked), GnuCash
opens a NEW tab with an "account + subaccounts" as a "Transaction Journal"
style register (whose view you cannot change in the View menu) with the
transaction ready to edit.

The primary indication that this is a different kind of Transaction Journal
register is a "+" character trailing the parent account name in the
register tab, and the fact that you cannot change its view.

[To summarize Ed Love's complaint: I believe his frustration stems from
having to look through more detail than necessary AND having to type each
corrected transaction amount twice in the Transaction Journal view when
editing a transaction while reconciling the account.]

----------------

Here is my analysis --

Yes, I agree with Ed that this behavior is not consistent with the
"ordinary" GnuCash Reconcile account behavior. However I believe I can show
how the register view behavior IS consistent in some other circumstances:

A) Select a "parent" account in the Accounts window, and choose "Open
SubAccounts." In this case you get a new Transaction Journal view register
with the tab labeled with the parent account's name followed by a "+"
symbol.

B) Choose Find, and the search results get displayed in a new Transaction
Journal view register with the tab labeled "Search Results."

C) When starting GnuCash (or after choosing Scheduled Transactions -->
Since Last Run...) if you check the "Review created transactions" checkbox
in the "Since Last Run" window, you get a new Transaction Journal view
register with the tab labeled "Created Transactions."

D) When reconciling an account having subaccounts, if you choose to include
the subaccounts in the reconciliation, and if you double-click a
transaction, you get a new register with the parent account's name followed
by a "+" symbol. [The scenario we have been discussing.]

E) There are probably others! [GnuCash has many features I have never
tried, including the "business" features, for instance. And in the decade
I've been using GnuCash I have never used scenario "A" (above) before
today.]

 In an email response, Geert called what we're seeing in scenarios A and D
an "accounts + subaccounts window."

I just tried all of these in GnuCash 2.6.12, and in all of the cases A - D
above, the new register is described (looking under the View menu) as a
"Transaction Journal," and GnuCash does not allow the user to change the
display type.

[Note my analysis here is based upon my observations and opinion; I have
not looked at the code.]

The register behavior in these cases has always suggested to me that
GnuCash might be doing a similar thing "behind the scenes" in all the
listed scenarios -- displaying the results of some kind of transaction
search. Much of the time, that search might include transactions from the
perspective of more than one parent account. Because the transactions might
have more than one parent, the window cannot follow the same rules as an
"ordinary" account register window, which has been streamlined to display
transactions efficiently from the view of a single account only.

Description of a Basic (or Auto Split) view: When you select and open the
display of a GnuCash account, the context of that register is transactions
from the perspective of that single account. All its transactions contain
an amount in either a debit or credit column. If a transaction contains a
"simple" or "single-split" transaction, GnuCash shows the split account's
name for the "other side" of the transaction. However, if the transaction
has more than one split, GnuCash shows "--Split Transaction--" until the
user chooses to "open" the split, then the transaction register expands
vertically into a special mini-register showing the split details for that
transaction. This behavior has been optimized to show as much detail as
possible in the smallest area of the screen by selectively omitting
information coming from other parts of each transaction split. The
arrangement also mimics the appearance of a paper register many folks are
already familiar with.

Description of a Transaction Journal view: In a Transaction Journal window
(or tab), GnuCash shows all the available details of each transaction,
grouped together in a fixed format (it doesn't change the arrangement of
the display for simple vs. multiple-split transactions). The arrangement is
somewhat standardized in the form of a "General Ledger" view in other
accounting systems. The disadvantage of the "complete" Transaction Journal
view is that for someone attending to transactions from a single account,
the extraneous detail and less-efficient usage of screen space make seeing
details from multiple transactions more difficult.

The Transaction Journal's lack of efficiency and unfamiliar arrangement of
information are the primary reasons many users prefer a simplified "Basic"
register view.

When GnuCash displays transactions in a window (or tab) as the result of
some sort of a search, the search doesn't necessarily respect a single
"parent" account the user is attending to, so the "safest" course is to
show as much detail as possible in the Transaction Journal view, because a
simplified model can be ambiguous or misleading, because it may not be
possible to anticipate what information is essential and which is
extraneous.


Why can't GnuCash show (or default to) a simplified Basic register view
when reconciling subaccounts?

Here's a use-case demonstrating where a simplified Basic register display
model breaks down:

I could have a bank checking account in which I created some subaccounts in
GnuCash to "protect" some restricted funds (so I don't unintentionally
spend them). We'll call one subaccount "mad money." To fund it, I created a
scheduled transaction that transfers $30 per month into the "mad money"
subaccount, so the subaccount increases monthly (and the checkbook balance
decreases at the same rate) but I never see the subaccount's funds in the
ordinary check register display.

Every time I reconcile the parent account against the monthly bank
statement, if I check the "use subaccounts" checkbox, the reconciliation
totals reflect the correct amount. To reconcile I can either ignore the
subaccount transfers or mark both sides reconciled. (It's easier if I mark
them reconciled so they won't show up again when I reconcile the next
month.)

Today I saw the widget of my dreams offered at the radically discounted
price of $999. Assuming I have been stashing away $30 per month into the
"mad money" subaccount for at least 34 months, I can afford to buy it, so I
pay for the widget by writing a check.

Now I turn to GnuCash. In addition to creating the transaction for the $999
check I wrote, I create a transaction to transfer $999 from the "mad money"
subaccount to the checking account so the checking register's balance won't
go negative. (Alternatively I could write the check USING the mad money
subaccount, but if I do, that check won't appear in the checking account
register. I suppose if I'm intent on hiding such a check from casual
inspection, maybe I could also use an unnumbered "counter check" or write
the check on the inside of a coconut shell instead of using a numbered
check from the checkbook....) ;-)

In a few weeks, the monthly bank statement arrives. While I am reconciling
the checking account against the statement, I can double-click the transfer
transaction I created, to move $999 from "mad money" to "checking account."

If GnuCash were to show the details of that transaction using a "simple"
register, what would it show? It could display a register that shows only
the "mad money" transactions, but that might be confusing because the
register wouldn't include any "actual" checking account transactions that
the bank account statement shows. I probably want to see the "parent"
checking account transactions in context with the "mad money" transfers,
because I might want to change the date of a transfer to the day before I
bought the widget, so the checking account register never shows negative.
(From the bank's perspective there have been no "mad money" transfers
because they have no knowledge of my GnuCash "mad money" account. It exists
only in GnuCash.)

If GnuCash combined the checking account and "mad money" subaccount
transactions together into a "Basic Ledger" account, what would it show for
the transfer account information? From a Basic Register perspective,
transfers between the checking account and "mad money" subaccount would
look like TWO transactions (even though they are the same transaction),
because GnuCash would be showing "both sides" of the transaction from two
different accounts at once.

SO using the display models available in GnuCash, It's easiest and clearest
to show a Transaction Journal when looking at multiple parent accounts,
because its display shows each unique transaction grouped together with its
splits.

------------------

It's likely you or I could think of a way to preserve a simplified
transaction display AND also suppress the display of confusing double
transactions, but I suppose it probably isn't a pressing issue for a huge
number of folks.

Someone had to make these design decisions when coding GnuCash, and they
may appear in a GnuCash design document (which I haven't seen). However I
just looked and I am fairly certain none of the descriptions above appears
in the user documentation.

This and other parts of GnuCash I use every day certainly cry out for a bit
of help, either in the UI design or better user documentation. Because of
my own background, I want to see an application's expected behavior
described somewhere, because then I know how it's supposed to do what I
need to accomplish.

SO (as suggested at the beginning of this message) here's a "wishlist" idea
for GnuCash... call it the "TL; DR" section, if you like. ;-)

--------

When editing a simple single split transaction in Transaction Journal view,
when finished editing an existing amount, the register could automatically
overwrite the existing amount on the "other side" of the split. This way
the new amount doesn't have to be typed more than once. (If a transaction
contains more than a single split, the current behavior should apply --
after changing the amount on a split line, a new blank split line appears
at the bottom of the split register containing an amount sufficient to
balance the remaining newly-unbalanced splits.)

This behavior seems obvious, so there may be a usability reason the
developers decided GnuCash should not behave this way already.