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.
Yes.
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.
Yes.
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
work.
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
--
Wm
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
