Scope of GNUCash
christopher.lck at gmail.com
Fri Feb 16 23:21:25 EST 2018
Thank you very much for documentation efforts.
FWIW I still prefer virtual transactions which are ridiculously easy to
generate, and to keep up to date. The challenge is not technical, but
it's the mindshare. I've sat through YNAB videos long enough to
understand how it works. It is also a very optional feature that not
everyone needs to use. e.g. I never void transactions nor bother with
clearing balances; for me reconciled balances are sufficient.
Subaccounts will have an unfortunate consequence of being real
transactions in real accounts, which will calculate real balances, need
to match real bank statements, affect real reports.
On 14/02/18 12:46, Matt Graham wrote:
> Not sure why you think I’m one of the “demanding” people... I’m not actually asking for anything – I’m trying to figure out how this all works, what I really need, and how I can contribute to make it happen.... I don’t expect anything specific from the core dev group – I just want to fit in with their plans.
> I am not sure why you think I’m defining the scope for anyone in these emails.... I started this thread asking what the scope is (triggered because you keep telling me that all the stuff I’m interested in is out of scope...). I don’t expect to get a say – I just thought there would be something that states it so that I can admit you are right (and stop focussing on that) or get you to stop saying that things people want to do “isn’t what GNUcash is for”. (Note: “We haven’t had time to implement that and probably wont get time” is a very different statement from “we won’t implement that because that isn’t what GNUCash is for”. The former => no worries I’ll help out if I can to get it to happen. Until then, I’ll make do. The latter => No worries, I’ll figure out a way to do it out of GNUCash and I’ll stop asking about it. Again: I’M NOT DEMANDING ANYTHING – I’M TRYING TO UNDERSTAND.
> So based on the questions I’m asking you (running around in circles?), I’m pretty confident I’m missing a lot of your points. I’ve read through a lot of the text accounting references you gave me a while ago about budgeting.... And it all seems pretty much in line with what Chris L and I were talking about ages ago. I was thinking along the lines of envelope budgeting with sub-accounts and tools to help that. Chris was talking about virtual transactions and how that would work. Both are described in various wiki’s and help docs found off the plain text accounting budgeting area: http://plaintextaccounting.org/#budgeting. So if I understand your point, you are saying that I should be exporting my accounts to text, then using another program to implement such a system?
> 1. I would rather use GNUCash over the plaintext tools if it is an option. Mainly because of the convenience in layout, display and interaction with my data. GNUCash it already gives somewhere between 70-85% of what I would need/want from the ideal.
> 2. I could spend my time learning the command line tools..... or I could spend my time helping out with GNUCash to build in the functionality I want (and evidently lots of other people want – but I don’t say any of this meaning the dev’s should do it for me. I say it to fend off your constant assertion: “that’s not what GNUCash is for!!!”. I’m still confused on what you think GNUCash should be for....).
> 3. If I am supposed to export from GNUcash regularly and then import to the command line tool to do stuff I’ll regularly want to do... then why wouldn’t I just use the command line tool for everything? Based on what you say, why do you use GNUCash at all??? What can it do that the command line tools can’t?
> For David T: What I’m planning to put into the Tut and Concepts at the moment is a description of how to use sub-accounts for envelope budgeting – Similar to the “Poor Postgrad System” in this link (but for GNUCash): https://memo.barrucadu.co.uk/2018-budget.html
> I hope I’m not being unreasonable (or being misunderstood) in all my posts. I am very grateful for the functionality and capability that GNUcash already has, and hopefully people aren’t getting offended when I ask my questions.
> Is it unreasonable to always be looking for a better way of doing things???
> Thanks and regards,
> From: Wm via gnucash-devel<mailto:gnucash-devel at gnucash.org>
> Sent: Wednesday, 14 February 2018 11:35 AM
> To: gnucash-devel at lists.gnucash.org<mailto:gnucash-devel at lists.gnucash.org>
> Subject: Re: Scope of GNUCash
> On 13/02/2018 21:53, Matt Graham wrote:
>> 😊 I think I would love to sit down in a pub with the three of you (Wm, Adrien, and Mike). I think we could have such awesome semi-drunken discussions about the nature of life, the universe and everything!
> I'm in London. Mike is in a Trump voting bit of Merka. Don't know where
> Adrien is and he shouldn't have to say.
> Accounting is a way of measuring life. Happiness is harder to quantify.
> Life should be enjoyable and measuring money shouldn't occupy too much
> of our time.
> Most crass philosophical sayings are also guaranteed to be crap.
>> I think you have basically answered my question, and I think we all basically agree on the rough direction things *should* go in (separate interacting packages).
> I'm the person arguing for stuff to be taken *out* of the basic package
> so the important stuff can more easily be better interpreted or used,
> the important stuff being the data that each of us owns or has
> responsibility for.
> Meanwhile, since I have a good understanding of accounting and databases
> and related stuff, I just do the bits I need that gnc doesn't cover
> using plain text accounting. My point in that regard being that almost
> all the *thought* problems have been solved in the plain text accounting
> universe and plain text accounting has also solved some problems you and
> I didn't even know existed and are way more esoteric than a budget being
> to your specific needs or a report being formatted one column to the
> left for the convenience of your tax accountant.
> The problems have been solved, it is the presentation you are struggling
> > I’m just not sure how to help make it happen (I’m an enthusiastic
> amateur when it comes to programming).
> The gnc code is almost impenetrable in parts. I'm considerably above
> average when it comes to programmings skills but there are, when I drill
> down, bits that simply don't parse. I know exactly what the code is
> meant to be doing but someone has written it in such an obscure way I
> just give up and return to understanding the data.
> It is *this* that the seniors are working on rather than adding a bell
> or a whistle.
> If the code can't be brought into a form where more than a handful of
> people can understand it the project is going to die with the seniors as
> they naturally retire to caring more for their grandchildren than people
> on the internet thing that demand they do this or that.
> You seem like one of the demanding people to me, Matt
>> I think I’ll start by updating the budget part of the tuts and concept guide like I have promised elsewhere, and then start looking into how the C++ modules have been structured (to see what connection will be possible within the 3.0 releases).
> Ufff, you are welcome to try to understand the budgets but you are
> warned, you aren't the first to think it makes sense to contribute
> there. You are also unlikely to succeed in explaining the way the
> existing budgets work to anyone's satisfaction, possibly even your own
> satisfaction. I am not joking, by the time you have figured out how the
> existing budgets work you will already be wondering why they were
> included at all which brings us neatly back to you, Matt, wondering what
> the scope is, remember ?
> I don't think you should be defining the scope for other people any more
> than me ... my wishlist is simple and if I don't get what I want I'm not
> going to cry because I can do my accounting in more than one way.
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel