Extracting useful information for tax returns (David T.)

J. Alex Aycinena alex.aycinena at gmail.com
Sat Apr 11 18:50:29 EDT 2009


David,

On Wed, Apr 8, 2009 at 12:51 PM, David T. <sunfish62 at yahoo.com> wrote:
>
> Alex--
>
> I'll check out the options for accounts to include; I hadn't thought of that! :O
>
> As for the Notes, it seems to me that the notes that are being included are a different set of notes than I get to see in the typical register window. I'd have less objection to including the regular notes, rather than these hidden import transaction notes. Regardless, one should be able to toggle them on or off.
>
> As an aside, I wonder where these technical notes are stored, and how a user could choose to see them in other contexts; it's a little weird to have data that is so hidden from the user.
>
> David
>

When you refer to 'regular notes', I'm assuming you refer to the
'description' field. Actually, at the transaction level, there are two
fields for storing information.

If, in Edit->Preferences->Register Defaults, you set 'double line
mode', you will see two lines per transaction (not to be confused with
any data stored at the split level discussed a bit below). The second
line shows the 'notes' field in which you can enter additional useful
information in addition to what is in the description field (for
example, your accounting practice could be to use the description for
'who' is involved in the transaction and the notes for 'what' is
involved in the transaction: description 'Best Buy', notes 'new
computer', or description 'IBM', notes 'Cash Dividend'). It sounds
like when you import transactions, some of the data is placed in the
notes field (I'm not personally familiar with importing). If you want
to see that data, and maybe modify it, this is how you could get to
it.

At the split level, there is also information that can be stored in
the 'action' and 'memo' fields, one each per split, two splits minimum
per transaction.

So all told, there is quite of bit data that can be kept for each
transaction. Each user needs to establish his/her own rules for how to
use all these fields (e.g., if description is 'who' and notes is
'what', action for each split is '???' and memo for each split is
'???'). The actions have a drop down list that varies by account type,
I think, but you can put in other values and I don't know if you can
add to or modify the drop down lists. The memo is free form. There are
no fixed rules for this; everyone needs to establish accounting
practices that use these fields in a way that meets their
requirements.

You can only see all this in the register if you set 'double line
mode' and show the splits. In the reports, in general, it probably
varies quite a bit as to which fields are shown in which report. Since
different user's accounting practices with respect to the use of all
these fields may vary quite a bit, I wanted to make sure that the Tax
Report could show all relevant information.

Speaking of all this data, there are a couple of things that I find to
be peculiar in the register:

1. The 'number' field is at the transaction level. So if you enter a
check number in the check register for a check that is deposited in
another account, the check number of the first account shows up in the
number field of the second account where it doesn't make any sense.
The 'number' field should be at the split level, but displayed exactly
the same in the register (that is, at the transaction level even
though it would be split-level data) and used in the same manner for
reconciliation as it is now. This way, each side of a transaction
could have its own 'number' to use for reconciliation or other
tracking purposes.

2. The 'action' field, which is at the split-level, is shown as
transaction-level data when you have 'double line mode' set and no
split data displayed. It then disappears from the transaction level
and moves to the split level when you show the split data. (This is
exactly the same concept that I think should be used for the 'number'
field, as explained above.) While this may appear strange when first
encountered, it actually makes a lot of sense and the fact that it
'moves around' serves as a visual clue to the user.

I guess these last two points are wandering off the topic a bit.

Alex


More information about the gnucash-user mailing list