Difficulty reporting split transactions filtered by description?

[Greg Skelhorn]

On 16/01/30 10:00, Mike or Penny Novack <mpnovack at mtdata.com> wrote:
> 
> On 1/29/2016 6:21 PM, Greg Skelhorn wrote:
> >On 16/01/29 12:27, "R. Victor Klassen" <rvklassen at gmail.com> wrote:
> >>Here is what I wound up doing to solve the same problem:
> >>
> >>All of my payroll entries have splits like:
> >>...
> >>
> >>Time to make T4s, I created a transaction report, restricted to dates within 2015, and including all the accounts listed above.
> >>At that point I’ve got as much help from GNUCash as I can (without learning Scheme). So I copy the report into a spreadsheet,
> >>save as CSV, go into an editor to remove the C$ at the front of every number, save back to CSV, and pull into OpenOffice (Excel would work too).
> >>
> >>
> >>Makes sense Victor. No reason to expect gnucash to do it all. Thanks!
> >>
> >>Greg
> Back when I first began using gnucash for organizational books I asked a more experienced accountant should I write customized reports. Unlike most of you, I wrote software for a living, and could at least read LISP, and when you already are fluent in half a dozen languages, no big deal to add another (SCHEME is a LISP dialect). He said "Don't bother Mike. Just export the data and we'll use a favorite editor to put it all into final pretty form, with all the necessary added annotations and text. That is how any accountant would choose to do it."
> 
> To give you an example from the full year report I will be presenting to the Board on Sunday. Because a reimbursement check from a grant arriving near the end of the year was made out incorrectly and had to be sent back for voiding and reissue, income that should have arrived in 2015 did not in fact arrive until a few days into 2016 (and the organization keeps its books on the "cash" basis). Now that required a whole bunch of annotations and explanatory text because the amount more than a quarter of yearly income! You can imagine the distortion cased to the "gain or loss for the year" and the balance sheet. Since at this meeting the board would be making plans budgetary decisions for the rest of 2016, obviously the report they are given, besides the actual figures for 2015, needed to provide in the annotations the approximate "real" amounts.
> 
> Really too much to expect gnucash itself to provide that much general purpose editor capability. Especially when general purpose editors already exist. When you look at the problem (report directly out of gnucash needs editing) it isn't the usual small amount of editing needed that should determine whether that little bit should be a facility of the software but what are the potential worst case scenarios. If sometimes you will need the full power of a general purpose editor, might as well always use it and just ask for the DATA out of gnucash, not the final formatting.
> 
> Michael D Novack
> 
> 

Makes sense. Once I have an established work flow I like to keep it as uniform as possible also.
I am currently facing several new tasks and choosing the tools and work flows for them. I am finding gnucash pretty easy to learn for my routine needs. It will take me some time to become comfortable with the portions best suited to another tool.
This group is proving most helpful. Thanks

Greg