Thank you for your response; my responses are inline.
On Wed, Jun 1, 2016 at 4:09 PM, Wm wrote:
> In article <
> cadu-kvf_qyg5vntvh4ddjkezevgxy2hx_yjarl5houezzeo...@mail.gmail.com>
> Aaron Laws wrote:
> >
> > >
> > > > On May 18, 2016, at 6:19 PM, Stephen Torri wrote:
> > > >
> > > > How is the data stored presently? If it is already in a database we
> > > should be able to query things. The only part I an intimated by is how
> to
> > > present it. A.k.a make the data look pretty.
> > >
> >
> > Strategies for getting data from the "book" are well in place, and a
> report
> > like this would be pretty similar to other reports. The report builder
> > would be a bit more elaborate and flexible than existing reports, but
> > getting data from the application would be done in the same way.
>
> Not quite. There are any number of generalist SQL report writing
> tools available for those interested.
>
> I have done the SQL homework that means that anyone that wants a
> Trial Balance, Income Statement or Balance Sheet can get them in
> pretty much any form they want if they have sufficient clue to play
> SQL and given the level of query I've used a text or csv file after
> that. Here in the UK we expect (many not all) school children in
> their early teen years to be able to do stuff with a text or csv
> file in a spreadsheet. Do you have a problem with doing your
> specific asset de-allocation in a spreadsheet?
>
I give my full assurance that I, not unlike those early-teen UK scholars,
am able to work with CSV files and spreadsheets. I think I'm also capable
of preparing all the reports offered in gnucash using a spreadsheet. The
complete workflow for getting the report I'm describing into a spreadsheet
involves quite a few steps; it would be much tidier within gnucash. Other
users requesting odd reports come to mind as well. While it is certainly
accurate to tell users that they can generate their reports with whatever
SQL reporting tools they like, it is nice to be able to ask gnucash itself
about its own data.
>
> The basi gnc data structures mainly work, I've kicked the tyres and
> not found anything obviously wrong yet (there are edge bits but you
> haven't addressed one of them).
>
> The presentation and interpretation are up to you.
>
> Other people have done interesting work too, look up
> Gregory Gincley rollenwiese at fastmail.net
> and his more personal work with Jasper. Superb but probably more
> than most people need.
>
> Given that ... I don't get to read everything on the user list
> (which is where this should be) and have probably missed the best
> solution of all as people do offer *their* solutions over time.
>
> More practically, I agree with MikeN up thread that you may have
> misunderstood what you were asking for, it looks to me like a limit
> on the stuff you report on when doing asset (i.e. point in time)
> reports is approprite advice.
>
> I find a report as follows useful
>
> Reports / A & L / Net worth bar / then use the unfortunately fiddly
> but still useable accounts tab to exclude non current stuff (in my
> case assets of pension and government owing me money not expected
> soon, etc and liabilities of some money I owe my father payable
> when I can, etc; I don't have a mortgage but that would be the sort
> of obvious liability to exclude if you have one of them) and you
> should have a nice view.
Yes, this is exactly the sort of information I'm seeking. I accidentally
looked over that report in my search because I'm looking for a text-based
report rather than a graph, but the information is certainly there.
> I add two graphs below that for Assets
> Over Time and Liabilities Over Time so I can see my position
> exactly, that involves Custom Multicolumn Reports ... but I can
> assure you that the fiddling involved is way simpler than getting
> everyone to agree on a new generic report model (I hope sql based)
> and then there is the effort of translating the existing reports to
> any ne model coz everyone wants continuity, after all? Thought
> about that?
>
I don't have any design to remove or replace existing reports, and I
wouldn't suggest anything like that without being quite confident that a
new solution would be not just equally good, but better than the existing
solution.
>
> May I gently suggest you have requested a reporting mechanism
> without a full eploration of those extant?
>
This is why I have posted here. I don't trust that I'm fully familiar with
the reporting capabilities of gnucash, and I'm looking for the community's
response to the suggestion. It seems like the response has been gently
positive, but I'm ready to accept a response of, "A feature like this would
be superfluous with the extant capabilities."
> --
> Wm ... who did the SQL reports just to understand to begin with
>
All that said, my suggestion is tentative: I'm not prepared to begin work
on such a feature at this time. I think it's a *vastly* higher priority to
do the work curr
