[GNC-dev] GnuCash 3 on Linux

Wm wm_o_o_o at yahoo.co.uk
Sun Feb 24 08:11:20 EST 2019

On 24/02/2019 09:11, Geert Janssens wrote:
> Op zondag 24 februari 2019 05:05:21 CET schreef David Cousens:
>> Adrien,
>> You beat me to it. I was about to also suggest making it a user preference
>> to be able to store the report configurations either with the book or as a
>> user location. Then the user could choose what suits their circumstances and
>> configuration.
>> David Cousens
> Well, for me each reference to "a new user preference" triggers the question
> "can't we solve it in another way".

I don't think we can solve this easily, Geert.

is there a way?  Yes.
Is there another way? Always.
Is there a good or right way?  Yes.

> For starters the user preference is an all or nothing thing, either all
> reports are in a book or in a common location. 

This simply is not true, Geert, I don't understand why you, who I 
respect so much, would say this when it is not true.

> That's not very fine-grained.
> Perhaps you consider some reports common and some reports book-specific. This
> could be solved by making it a per report option of course.


> It also doesn't solve the issue of sharing those common reports with other
> users (like your accountant).

My accountant is me, I am also other people's accountant.  I don't lie 
about money.

To some extent Geert is making a jurisdictional argument, major 
commercial accounting applications are failing to provide what 
governments want.  I think
Reports / Tax Schedule etc
should be removed for incompetence and trial balance reporting improved.

> And yet another issue: reports are only suitable for multiple books if these
> books have the exact same base as required per report. 

Yup, therefore it makes no sense for the reports to be stored per user. 
Do we know who came up with this stupid idea yet?

> take the transaction report. The user selects a set of
> transactions to display. Now suppose you select some accounts that are
> exclusively to this particular book. If you save this preset, and use it in
> another book that doesn't have these accounts there will be an issue.

Geert, the saved report will most likely be useless with another book.

Who was the fucking idiot that decided to use one set of saved reports?
Tell us that, please!  Be a man, Geert.

> I
> haven't tested, though at best the account is ignored, at worst the report
> throws errors. That's the best scenario. The other way around is worse:
> suppose you saved the report configuration with all asset accounts selected in
> one book. You then try to use this report on a  book that has an additional
> asset account. As this account is not part of the initial selection it won't
> appear in the transaction report in the second book. Of course for a
> transaction report it's fairly easy to spot. There are other reports where
> this is much more subtle though. And this is not limited to account selections
> though I suspect that's the most important one.

I'm seeing support for my concept, I like someone that thinks things 
through, eventually.

> So my conclusion is that report configurations are essentially book specific
> and should be treated as such to avoid unexpected accounting mistakes.


> On the other hand I understand it takes time to carefully configure reports to
> your preference and there's a wish to reuse this effort across books.

That is easy, you just copy and paste a file.  I have no time for cheap 
and lazy accountants that want to charge people lots of money for little 

> I have done this thought exercise in the past. At that time the best I could
> come up with was to provide gui functions to manage report presets. In
> particular some form of import/export functionality. The configurations would
> remain per book. But one could explicitly export a configuration from one book
> and import it in another.

My problem, Geert, is why you allowed what we have now to happen. 
Surely you, a respected person, a monitor, should have noticed it was 
wrong when the 2.x to 3.x code was settling in?

I *did* talk about this!  You (pural) ignored me at the time.

> It's not ideal as it doesn't solve the subtle errors issue. The user will
> still have to verify the imported configuration works for the book it's
> imported in. Improving on that will require smarter report options (like ways
> to specify "select all asset accounts" or "select all children from account
> xyz" instead of a dumb list of account ids). I'm pretty sure that would
> increase internal option complexity a lot and I'm not convinced the benefit in
> this case is worth the trouble.

Geert, I don't get the complexity you're describing.  If something 
ordinary that involves money happens in my life I add an account for 
that, this is how accounting is meant to work.

You seem to think adding an account is something to be thought about by 
a panel of wise men and women, that isn't how modern accounting works.

> All brainstorming of course. No implementation in sight...

Why no implementation change?  The retrograde step happened in 2.x to 3.x


More information about the gnucash-devel mailing list