Re: Scope of GNUCash
On 16/02/2018 16:19, David Carlson wrote: Wm, this is a GnuCash miallist, not a political forum. If there was any useful information in that last spate, I didn't even see it. Liz, you have my permission to cut him off again. I think David Carlson may also be an unrealistic attributer. David, just because something is in a quote doesn't mean I believe it or said it, OK ? This is social media basics and worked fine before. -- Wm I think if someone is going to play Trump / Putin foolishness they should be put on the watch list not me ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 16/02/2018 16:19, David Carlson wrote: Wm, this is a GnuCash miallist, not a political forum. If there was any useful information in that last spate, I didn't even see it. Liz, you have my permission to cut him off again. David C I presume you do know Liz isn't american ? The sensible response is to curtail David C and to keep on topping and tailing people like myself *and* him until there is no-one left. The point being that if you keep on doing it there won't be anyone left. Is there no-one with a sense of responsibility here any more? I simply do not trust Liz as an arbitrator of a good post versus a bad one. Yes, I am aware this might be shooting the messenger, but I am doing it in public and hoping to clear the air, because if David Carlson has been kissing someone else's rectal opening I'd hope they'd all be open about it. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
90% agree with you Chris! The last 10% is because Im still yet to try it for myself in ledger (probably next weekend). Since GNUCash doesnt implement them, I am thinking Ill just have links to the plain text accounting pages, giving users other reading to do it outside of gnucash Thanks and regards, Matt Original message From: Christopher Lam Date: 17/2/18 15:22 (GMT+10:00) To: gnucash-devel@gnucash.org Subject: Re: Scope of GNUCash Hi Matt 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: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fplaintextaccounting.org%2F%23budgeting&data=02%7C01%7C%7C6e086cdfd2984fb3c09e08d575be09e6%7C84df9e7fe9f640afb435%7C1%7C0%7C636544381431292259&sdata=vgDy3yjfROI78M18qn83rzwvyefWUczMecs48Dfb2XU%3D&reserved=0. > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmemo.barrucadu.co.uk%2F2018-
Re: Scope of GNUCash
Hi Matt 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, Matt From: Wm via gnucash-devel<mailto:gnucash-devel@gnucash.org> Sent: Wednesday, 14 February 2018 11:35 AM To: gnucash-de...@lists.gnucash.org<mailto:gnucash-de...@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. L
Re: Scope of GNUCash
I have always assumed (without purpose or thinking about it) that Gnucash was "supposed" to be a "financial management" program, rather than more strictly an "accounting" program. So my original question was to clarify which it is supposed to be. (And if this has been answered, then I have completely missed it... sorry). However, my question was flawed because the answer doesnt change any action I will do . GNUcash is useful to me, so that is enough. For extending out to the last 20% of what I want, I can either find a way to do it outside of gnc, or I can alter the gnc code to do it. If my stuff is out of scope, then no worries, it just wont go in the releases. Im sorry if any of my posts come across as passive agressive, rude, defensive, angry, or demanding. Despite english being my first and only language, I am easily misunderstood. For the tut guide on budgets, Im only putting in an example of how to use sub-accounts as virtual breakdowns of their money. So not going to mention virtual transactions unless virtual or budget accounts are implemented in gnucash (and Im not worried if they are or arent at this point). If anything in this post sounds arrogant, passive agressive, or demanding, please know I didn't mean it that way. Thanks and regards, Matt Original message From: Wm via gnucash-devel Date: 17/2/18 01:50 (GMT+10:00) To: gnucash-de...@lists.gnucash.org Subject: Re: Scope of GNUCash On 14/02/2018 04: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. > That's a bit passive aggressive, again. > I am not sure why you think I’m defining the scope for anyone in these > emails How about the headline "Scope of GNUCash" as a clue ? > 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”. yes, scope includes time. if the thing you want is 35 years in the future you my want to do something nearer now. > (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. > I am saying if you are prepared to wait a decade you might get what you want. I'm asking if you are a 10 year person or a 10 month person. > 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: > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fplaintextaccounting.org%2F%23budgeting&data=02%7C01%7C%7C12c69052d26a43da4aca08d5754c98ba%7C84df9e7fe9f640afb435%7C1%7C0%7C636543894193512179&sdata=6c8JMa5%2B35IVM7wsPhH3zM3529gUgGpO7VtoEYz0UqI%3D&reserved=0. > 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? Not quite, you only need to export a bit of your accounts. Otherwise, yes >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. Me too! >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 n
Re: Scope of GNUCash
Wm, this is a GnuCash miallist, not a political forum. If there was any useful information in that last spate, I didn't even see it. Liz, you have my permission to cut him off again. David C On Fri, Feb 16, 2018 at 9:17 AM, Wm via gnucash-devel < gnucash-devel@gnucash.org> wrote: > On 14/02/2018 18:07, Adrien Monteleone wrote: > >> >> On Feb 13, 2018, at 8:49 PM, Wm via gnucash-devel < >>> gnucash-devel@gnucash.org> wrote: >>> >>> On 13/02/2018 15:30, Adrien Monteleone wrote: >>> Michael, I agree completely on the separation point, especially with regard to controls. >>> >>> If you agree on that you are an idiot, >>> >> >> I’m not sure why your tone is the way it is. I noticed it changed >> yesterday and I was quite surprised. I’ve seen several threads where you >> are replying in a very negative and rude tone. Direct personal attacks and >> cursing (from another thread on the dev list) are not appropriate. >> > > I reply as I feel fit > > >> Mike's POV is (if I understand correctly over a period of time) mainly a >>> charitable one. >>> >> >> Accounting controls are not just for non-profits, far from it. It’s a >> basic subject taught in accounting classes. If you found an accounting >> textbook that didn’t cover the subject, I’d say that book was incomplete. >> >> There’s even an entire specialty of ‘forensic accounting’ and they don’t >> just work with non-profits. >> > > I have been employed as one of them more than once. > > AT THIS POINT I POINT OUT > > you are out of your depth. > > You're addressing me in terms of words rather than facts. Grow up or get > a hash tag <-- and the associated despicable "I am a man and I need to > defend crap" > > I’ve seen first hand when sales clerks have the ability to void and edit their own transactions from a point of sales system. I can’t imagine the damage that WOULD be done if they also had the ability to access the inventory system AND the general accounting software. (even just the ability to partially close a ticket is dangerous) >>> >>> Why are you blaming the workers rather than the employers? >>> >> >> Blame belongs on those who steal. I’ve experienced both employees and >> employers stealing. I’ve experienced restaurant servers manipulating the >> point of sale system to steal. I’ve experienced managers doing the same. In >> both cases, the control-checks that were in place caught them, but didn’t >> prevent them. So the access to functions was changed as a preventative >> measure and the control-checks were updated. >> >> A manager with access to hide evidence of, or alter transactions in the >> general ledger? That’s begging for trouble. I once caught a manager who >> stole cash. I was only able to catch him because of the control-check we >> had in place. Had he access to that control-check and been able to alter >> its record of our petty-cash flow, we’d have never been able to pin point >> who was responsible. Had we not been using the control properly (as I >> discovered in another unit) we’d have never even realized the cash was >> missing. >> > > > That is interesting but completely out of the "Scope" of what gnc is > likely to do. > > >>> Why do you think a piece of software can help if you are shitting on >>> your employees. >>> >>> Mike, is this what you expected as a response? Adrien appears to be a >>> person that trusts no-one. >>> >>> Welcome to the tacky politics of Trumpian merka :( >>> >>> >>> As for interoperability, the devil is always in the details but I see three main hangups. First, any software should be able to import it’s own exports. >>> >>> Yes, import and export should work but doesn't. I'm not fussed because >>> I know how to make it happen anyway. I'm just not allowed to tell you how >>> because a senior gets upset if I say. >>> >> >> I doubt seriously John, Geert, David or anyone else will be mad if you >> explain to users how to properly manage an export and re-import. (not that >> it matters much now, since this is to be possible with 3.0 anyway) >> > > Indeed, they are waiting for this discussion to go away. > > The answer is to write back using anything you like and check afterwards, > btw. Just don't tell anyone. The closer the db gets to normality the more > things like that work. > > > >>> Second, any software with imports should be able to allow the user an easy way to map fields and save that mapping for future use. >>> >>> Not important, that is usually a one-off and gnc does that anyway. >>> >> >> Somewhat. And I hope this will be improved with 3.0. And it isn’t a >> one-off if you have to repeatedly import data. You’d want to set the import >> mapping one time as long as it hasn’t changed. You wouldn’t want to have to >> re-map each time you import. >> > > Only until you get it right, then you don't care. I have done hundreds of > imports, that is the nature of the beast. > > Third, importing and exporting should be possible to s
Re: Scope of GNUCash
On 14/02/2018 18:07, Adrien Monteleone wrote: On Feb 13, 2018, at 8:49 PM, Wm via gnucash-devel wrote: On 13/02/2018 15:30, Adrien Monteleone wrote: Michael, I agree completely on the separation point, especially with regard to controls. If you agree on that you are an idiot, I’m not sure why your tone is the way it is. I noticed it changed yesterday and I was quite surprised. I’ve seen several threads where you are replying in a very negative and rude tone. Direct personal attacks and cursing (from another thread on the dev list) are not appropriate. I reply as I feel fit Mike's POV is (if I understand correctly over a period of time) mainly a charitable one. Accounting controls are not just for non-profits, far from it. It’s a basic subject taught in accounting classes. If you found an accounting textbook that didn’t cover the subject, I’d say that book was incomplete. There’s even an entire specialty of ‘forensic accounting’ and they don’t just work with non-profits. I have been employed as one of them more than once. AT THIS POINT I POINT OUT you are out of your depth. You're addressing me in terms of words rather than facts. Grow up or get a hash tag <-- and the associated despicable "I am a man and I need to defend crap" I’ve seen first hand when sales clerks have the ability to void and edit their own transactions from a point of sales system. I can’t imagine the damage that WOULD be done if they also had the ability to access the inventory system AND the general accounting software. (even just the ability to partially close a ticket is dangerous) Why are you blaming the workers rather than the employers? Blame belongs on those who steal. I’ve experienced both employees and employers stealing. I’ve experienced restaurant servers manipulating the point of sale system to steal. I’ve experienced managers doing the same. In both cases, the control-checks that were in place caught them, but didn’t prevent them. So the access to functions was changed as a preventative measure and the control-checks were updated. A manager with access to hide evidence of, or alter transactions in the general ledger? That’s begging for trouble. I once caught a manager who stole cash. I was only able to catch him because of the control-check we had in place. Had he access to that control-check and been able to alter its record of our petty-cash flow, we’d have never been able to pin point who was responsible. Had we not been using the control properly (as I discovered in another unit) we’d have never even realized the cash was missing. That is interesting but completely out of the "Scope" of what gnc is likely to do. Why do you think a piece of software can help if you are shitting on your employees. Mike, is this what you expected as a response? Adrien appears to be a person that trusts no-one. Welcome to the tacky politics of Trumpian merka :( As for interoperability, the devil is always in the details but I see three main hangups. First, any software should be able to import it’s own exports. Yes, import and export should work but doesn't. I'm not fussed because I know how to make it happen anyway. I'm just not allowed to tell you how because a senior gets upset if I say. I doubt seriously John, Geert, David or anyone else will be mad if you explain to users how to properly manage an export and re-import. (not that it matters much now, since this is to be possible with 3.0 anyway) Indeed, they are waiting for this discussion to go away. The answer is to write back using anything you like and check afterwards, btw. Just don't tell anyone. The closer the db gets to normality the more things like that work. Second, any software with imports should be able to allow the user an easy way to map fields and save that mapping for future use. Not important, that is usually a one-off and gnc does that anyway. Somewhat. And I hope this will be improved with 3.0. And it isn’t a one-off if you have to repeatedly import data. You’d want to set the import mapping one time as long as it hasn’t changed. You wouldn’t want to have to re-map each time you import. Only until you get it right, then you don't care. I have done hundreds of imports, that is the nature of the beast. Third, importing and exporting should be possible to schedule or trigger without manual user intervention. (so apps can talk to each other reliably without lag) Wrong! I specifically do *not* want importing and exporting to happen without me saying so. Maybe you don’t, and certainly you should always have such control. But others might want to automate some areas of data exchange. Gnucash never has to implement this, but there is a valid use case for it. I've never noticed one. New thread, I think. I think 3.0 is going to partially address the first and second case. I don’t think the third is contemplated yet. The third is also dangerous for
Re: Scope of GNUCash
On 14/02/2018 15:29, Mike or Penny Novack wrote: On 2/13/2018 9:49 PM, Wm via gnucash-devel wrote: Why are you blaming the workers rather than the employers? Why do you think a piece of software can help if you are shitting on your employees? Mike, is this what you expected as a response? Adrien appears to be a person that trusts no-one. Welcome to the tacky politics of Trumpian merka :( Absolutely not, it is your response I find surprising. Problems do not arise just because employers are sh*tting on employees << this is NOT to say that some employers don't do exactly that >> However an auditor should NOT approve use of a system without the sort of controls we are talking about, limiting access to those who have need, etc. One of the organizations where I am on committees, etc. (and have been on the board, and in the aftermath aiding the new treasurer recover) was hit by embezzlement by an office manager, from which a decade later we have not fully recovered in the financial sense*. Trusted with access to which she should not have been trusted. Yikes, OK. I was yelling a bit because you come across as a bit too pure at times. Other people that have read your rationales and pronouncements over time will know what I mean. Everything was perfect when you were in charge, remember? * We agreed to a plea bargain "no jail" in exchange for repayment of what she stole (working over time) as if in jail we wouldn't have gotten even THAT back. But what she directly stole was only about half the damage as payments that should have been made to governmental bodies weren't and though those bodies agreed to waive penalties still had to pay the interest on the amounts owed as well as the amounts. The bank involved agreed to lend us the money no interest for a number of years, but still had to be paid back. The total we had to make up close to a year's budget! :( We had a case like that (I was observing rather than involved) a year or two ago. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 14/02/2018 04: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. That's a bit passive aggressive, again. I am not sure why you think I’m defining the scope for anyone in these emails How about the headline "Scope of GNUCash" as a clue ? > 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”. yes, scope includes time. if the thing you want is 35 years in the future you my want to do something nearer now. > (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. I am saying if you are prepared to wait a decade you might get what you want. I'm asking if you are a 10 year person or a 10 month person. 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? Not quite, you only need to export a bit of your accounts. Otherwise, yes 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. Me too! 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). You're still waiting for us to reveal the secret master plan that has already been revealed but was apparently in a foreign language (it really has been said in this group in the last few days). You probably read it and thought, "nah, they can't mean that" 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? I happen to like gnc. I only need to use the command line stuff occasionally. I use gnc most days. I am very good at scripting, so when I need to get stuff in or out it works for me. 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 gnc doesn't have the concept of virtual accounts in the same way ledger and hledger do. it simply WILL NOT WORK. ledger and hledger allow multiple report views of balances. gnc simply doesn't include that idea or concept at the moment. 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??? Of course not, it is, however, unusual to make a round wheel square and vice versa. What you want is a fine demand if you are happy to wait many years. -- Wm ___ gnu
Re: Scope of GNUCash
On 14/02/2018 03:55, Christopher Lam wrote: Hi Adrien - from someone who jumped head first into scheme, come on in :) the water's warm, and the old guard are very happy to help you implement your wishlist. Meanwhile you'll soon see for yourself what the project needs and can dabble in too. Scheme currently needs lots of refactoring and tests, and this will be independent of C++/GTK3 work. Damn, ChristopherL you make Scheme almost sound yummy :) Have you considered selling Trump Hotels with gold plated wives as a future career ? Obviously everything gets fingered in the fanny by a republican first, hey , hey , hey. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 14/02/2018 15:12, Mike or Penny Novack 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. I am NOT in a "Trump voting bit of Merka". But it worked to draw you out. > Not only in one of the "bluest" of the blue states but in a county of that state where on primary election day Bernie had an absolute majority of all votes cast (for all candidates in all parties). Here, people organized FCCPR (Franklin County Continuing the Political Revolution) BEFORE the general election. Not to oppose Trump (didn't know/expect he would win) but intended to try to keep Hilary's feet to the fire on the program. Of course the focus of FCCPR is now different. My apology. Your conservatism and mine differ. I just think that after Haiti most people that work for non-profits should be checking expenses. I'm lucky, I keep my accounts in gnc. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
> On Feb 13, 2018, at 8:49 PM, Wm via gnucash-devel > wrote: > > On 13/02/2018 15:30, Adrien Monteleone wrote: >> Michael, >> I agree completely on the separation point, especially with regard to >> controls. > > If you agree on that you are an idiot, I’m not sure why your tone is the way it is. I noticed it changed yesterday and I was quite surprised. I’ve seen several threads where you are replying in a very negative and rude tone. Direct personal attacks and cursing (from another thread on the dev list) are not appropriate. > Mike's POV is (if I understand correctly over a period of time) mainly a > charitable one. Accounting controls are not just for non-profits, far from it. It’s a basic subject taught in accounting classes. If you found an accounting textbook that didn’t cover the subject, I’d say that book was incomplete. There’s even an entire specialty of ‘forensic accounting’ and they don’t just work with non-profits. > >> I’ve seen first hand when sales clerks have the ability to void and edit >> their own transactions from a point of sales system. I can’t imagine the >> damage that WOULD be done if they also had the ability to access the >> inventory system AND the general accounting software. (even just the ability >> to partially close a ticket is dangerous) > > Why are you blaming the workers rather than the employers? Blame belongs on those who steal. I’ve experienced both employees and employers stealing. I’ve experienced restaurant servers manipulating the point of sale system to steal. I’ve experienced managers doing the same. In both cases, the control-checks that were in place caught them, but didn’t prevent them. So the access to functions was changed as a preventative measure and the control-checks were updated. A manager with access to hide evidence of, or alter transactions in the general ledger? That’s begging for trouble. I once caught a manager who stole cash. I was only able to catch him because of the control-check we had in place. Had he access to that control-check and been able to alter its record of our petty-cash flow, we’d have never been able to pin point who was responsible. Had we not been using the control properly (as I discovered in another unit) we’d have never even realized the cash was missing. > > Why do you think a piece of software can help if you are shitting on your > employees. > > Mike, is this what you expected as a response? Adrien appears to be a person > that trusts no-one. > > Welcome to the tacky politics of Trumpian merka :( > > >> As for interoperability, the devil is always in the details but I see three >> main hangups. First, any software should be able to import it’s own exports. > > Yes, import and export should work but doesn't. I'm not fussed because I > know how to make it happen anyway. I'm just not allowed to tell you how > because a senior gets upset if I say. I doubt seriously John, Geert, David or anyone else will be mad if you explain to users how to properly manage an export and re-import. (not that it matters much now, since this is to be possible with 3.0 anyway) > >> Second, any software with imports should be able to allow the user an easy >> way to map fields and save that mapping for future use. > > Not important, that is usually a one-off and gnc does that anyway. Somewhat. And I hope this will be improved with 3.0. And it isn’t a one-off if you have to repeatedly import data. You’d want to set the import mapping one time as long as it hasn’t changed. You wouldn’t want to have to re-map each time you import. > >> Third, importing and exporting should be possible to schedule or trigger >> without manual user intervention. (so apps can talk to each other reliably >> without lag) > > Wrong! I specifically do *not* want importing and exporting to happen > without me saying so. Maybe you don’t, and certainly you should always have such control. But others might want to automate some areas of data exchange. Gnucash never has to implement this, but there is a valid use case for it. > >> I think 3.0 is going to partially address the first and second case. I don’t >> think the third is contemplated yet. The third is also dangerous for >> accounting so it should be very carefully implemented and certainly not a >> default condition. > > The third is sufficiently dangerous that I say NO. > > -- > Wm > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 2/13/2018 9:49 PM, Wm via gnucash-devel wrote: Why are you blaming the workers rather than the employers? Why do you think a piece of software can help if you are shitting on your employees? Mike, is this what you expected as a response? Adrien appears to be a person that trusts no-one. Welcome to the tacky politics of Trumpian merka :( Absolutely not, it is your response I find surprising. Problems do not arise just because employers are sh*tting on employees << this is NOT to say that some employers don't do exactly that >> However an auditor should NOT approve use of a system without the sort of controls we are talking about, limiting access to those who have need, etc. One of the organizations where I am on committees, etc. (and have been on the board, and in the aftermath aiding the new treasurer recover) was hit by embezzlement by an office manager, from which a decade later we have not fully recovered in the financial sense*. Trusted with access to which she should not have been trusted. * We agreed to a plea bargain "no jail" in exchange for repayment of what she stole (working over time) as if in jail we wouldn't have gotten even THAT back. But what she directly stole was only about half the damage as payments that should have been made to governmental bodies weren't and though those bodies agreed to waive penalties still had to pay the interest on the amounts owed as well as the amounts. The bank involved agreed to lend us the money no interest for a number of years, but still had to be paid back. The total we had to make up close to a year's budget! ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
😊 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. I am NOT in a "Trump voting bit of Merka". Not only in one of the "bluest" of the blue states but in a county of that state where on primary election day Bernie had an absolute majority of all votes cast (for all candidates in all parties). Here, people organized FCCPR (Franklin County Continuing the Political Revolution) BEFORE the general election. Not to oppose Trump (didn't know/expect he would win) but intended to try to keep Hilary's feet to the fire on the program. Of course the focus of FCCPR is now different. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 2/13/2018 4:53 PM, 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 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 just not sure how to help make it happen (I’m an enthusiastic amateur when it comes to programming). 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). Thanks and regards, Well of course I am not an amateur, it is how I used to make my living. But I can't help out with program design/coding unless/until I can get bandwidth here a home < unwilling to cut down enough large trees to get a "window" for satellite > But besides being a senior systems analyst (programs) also a senior analyst (business -- the part that comes before) A comment on the third part --- HOW the process of feeds and their reception is handled. That can be deferred for now and at the beginning can assume manual because whether "job scheduling" is possible is more or less OS dependent. For example, I haven't a clue how for Windows could have a job submit (other jobs), tell whether other jobs were running or had completed and if so, whether successfully, etc. That I knew very well how to do this under MVS/XA (a mainframe OS) and am pretty sure I could figure it out for a 'nix is besides the point. Remember (an important point) a feed can FAIL. Not only once the program tries to bring it in but it could have failed in "input editing". In the initial project phase we might better assume that a human is running these things and will not start the next step of the process until seeing that predecessor steps worked. How an automated system is stopped part way and resumed after a "fix" is a project in itself. I'm the sort of guy who used to get woken up in the middle of the night when the programmers on standby couldn't fix the problem. Michael ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: Scope of GNUCash
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, Matt From: Wm via gnucash-devel<mailto:gnucash-devel@gnucash.org> Sent: Wednesday, 14 February 2018 11:35 AM To: gnucash-de...@lists.gnucash.org<mailto:gnucash-de...@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&
Re: Scope of GNUCash
Hi Adrien - from someone who jumped head first into scheme, come on in :) the water's warm, and the old guard are very happy to help you implement your wishlist. Meanwhile you'll soon see for yourself what the project needs and can dabble in too. Scheme currently needs lots of refactoring and tests, and this will be independent of C++/GTK3 work. On 14 Feb 2018 11:32, "Adrien Monteleone" wrote: > Not sure what the current POTUS office holder has to do with anything > related, but, whatever… > > I was just in NOLA for a few days, now back home in Lafayette. Happiness > is measured in beer, or something similar, here. I’ve had several beers > today, so my happiness meter is reading high at the moment. > > I have zero demands on the developer team. I hope they accomplish all they > set out to. (and quickly!) But I’m thankful they’ve laid out a road map for > me to decide where (and how) to hop on the train should I manage to chime > in with something useful. (*note, validated code is useful, ideas? not so > much) > > For now, I’m going to attempt to tackle some report issues. Sure, I could > wait till full SQL arrives, but that wouldn’t serve needs NOW. I don’t > ‘want’ to learn scheme, but I’ll take one for the team if it means being > able to offer some out of the box ‘features’ people keep asking for. > > After that, or in the middle of doing so, I might decide to get my feet > wet with GC code. I’d ‘like’ to work on things I want to see implemented, > but I understand certain other tasks have to be taken care of first, most > notably, the move to full C++ and GTK3. Once that is done, lots of legacy > code and ways of doing things can or will be quickly discarded which will > then clear the way for more ‘features’ that users are looking for. So when > I do jump into code, my focus will always be to try to work on what the > project needs, not what I need. If I can squash some bugs in the process, > all the better. > > Happy Mardi Gras, > Adrien > > > On Feb 13, 2018, at 6:34 PM, Wm via gnucash-devel < > gnucash-devel@gnucash.org> wrote: > > > > 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 > with. > > > > > 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 understan
Re: Scope of GNUCash
Not sure what the current POTUS office holder has to do with anything related, but, whatever… I was just in NOLA for a few days, now back home in Lafayette. Happiness is measured in beer, or something similar, here. I’ve had several beers today, so my happiness meter is reading high at the moment. I have zero demands on the developer team. I hope they accomplish all they set out to. (and quickly!) But I’m thankful they’ve laid out a road map for me to decide where (and how) to hop on the train should I manage to chime in with something useful. (*note, validated code is useful, ideas? not so much) For now, I’m going to attempt to tackle some report issues. Sure, I could wait till full SQL arrives, but that wouldn’t serve needs NOW. I don’t ‘want’ to learn scheme, but I’ll take one for the team if it means being able to offer some out of the box ‘features’ people keep asking for. After that, or in the middle of doing so, I might decide to get my feet wet with GC code. I’d ‘like’ to work on things I want to see implemented, but I understand certain other tasks have to be taken care of first, most notably, the move to full C++ and GTK3. Once that is done, lots of legacy code and ways of doing things can or will be quickly discarded which will then clear the way for more ‘features’ that users are looking for. So when I do jump into code, my focus will always be to try to work on what the project needs, not what I need. If I can squash some bugs in the process, all the better. Happy Mardi Gras, Adrien > On Feb 13, 2018, at 6:34 PM, Wm via gnucash-devel > wrote: > > 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 with. > > > 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
Re: Scope of GNUCash
Matt, I again applaud your promise (threat?! ;) ) to update the slim information about the Budget section. As you do, be sure to look through the list archives and the wiki for any information you might draw in to the Tutorial; there have been numerous discussions over the years about how to use them. Personally, I would love an explanation of how the Budget reports can be used; I have never been able to figure them out (beyond a few rudiments). Cheers, David > On Feb 14, 2018, at 2:53 AM, 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 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 just not sure how to help make it happen (I’m an enthusiastic > amateur when it comes to programming). 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). > > Thanks and regards, > > Matt > > From: Adrien Monteleone<mailto:adrien.montele...@gmail.com> > Sent: Wednesday, 14 February 2018 2:31 AM > To: gnucash-devel<mailto:gnucash-devel@gnucash.org> > Subject: Re: Scope of GNUCash > > Michael, > > I agree completely on the separation point, especially with regard to > controls. > > I’ve seen first hand when sales clerks have the ability to void and edit > their own transactions from a point of sales system. I can’t imagine the > damage that WOULD be done if they also had the ability to access the > inventory system AND the general accounting software. (even just the ability > to partially close a ticket is dangerous) > > As for interoperability, the devil is always in the details but I see three > main hangups. First, any software should be able to import it’s own exports. > Second, any software with imports should be able to allow the user an easy > way to map fields and save that mapping for future use. Third, importing and > exporting should be possible to schedule or trigger without manual user > intervention. (so apps can talk to each other reliably without lag) > > I think 3.0 is going to partially address the first and second case. I don’t > think the third is contemplated yet. The third is also dangerous for > accounting so it should be very carefully implemented and certainly not a > default condition. > > Regards, > Adrien > >> On Feb 13, 2018, at 8:10 AM, Mike or Penny Novack >> wrote: >> >> On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote: >> >>> >>>> A couple of times I have noticed that people have said "That's not what >>>> GNUCash is for". It begs the question - where is it defined what GNUCash >>>> is and isn't for? The charter for GNUCash doesn't seem to ever been >>>> formalised. >>> There is a long term plan, we never write it down because people ask us >>> about it :) Is it intended that people should establish a complementary but >>> separate project for functionality they want, but is not included in >>> GNUCash scope? >>> >>> I don't see why not if that is what they want to do. >> >> Since I have been one of the people arguing for "separation" (I think this >> is being misunderstood) I want to clarify the reasons and what I mean when I >> use the term. >> >> a) I do NOT mean that needs to be a separate project. Could be part of a >> PACKAGE (even installed together) but not a single program. >> >> b) The reason for separate "packages" that interact with each other rather >> than a single program (that a user is or is not allowed to use) is so that >> ONE "system" (interacting parts) can be used for all. Those people who are >> running "one man band" businesses do not see the problem, do not see why >> things like (proposed extensions) like "inventory", "point of sales", >> "payroll", etc. cannot be PART of the "general ledger" program. Call these >> "one man band" users businesses of class A. >> >> But there is another sort of business user, call these class B. They have >> employees, they have division of responsibility and authority. They may have >> need of safeguards. I am not meaning JUST businesses sinc
Re: Scope of GNUCash
On 13/02/2018 15:30, Adrien Monteleone wrote: Michael, I agree completely on the separation point, especially with regard to controls. If you agree on that you are an idiot, Mike's POV is (if I understand correctly over a period of time) mainly a charitable one. I’ve seen first hand when sales clerks have the ability to void and edit their own transactions from a point of sales system. I can’t imagine the damage that WOULD be done if they also had the ability to access the inventory system AND the general accounting software. (even just the ability to partially close a ticket is dangerous) Why are you blaming the workers rather than the employers? Why do you think a piece of software can help if you are shitting on your employees? Mike, is this what you expected as a response? Adrien appears to be a person that trusts no-one. Welcome to the tacky politics of Trumpian merka :( As for interoperability, the devil is always in the details but I see three main hangups. First, any software should be able to import it’s own exports. Yes, import and export should work but doesn't. I'm not fussed because I know how to make it happen anyway. I'm just not allowed to tell you how because a senior gets upset if I say. Second, any software with imports should be able to allow the user an easy way to map fields and save that mapping for future use. Not important, that is usually a one-off and gnc does that anyway. Third, importing and exporting should be possible to schedule or trigger without manual user intervention. (so apps can talk to each other reliably without lag) Wrong! I specifically do *not* want importing and exporting to happen without me saying so. I think 3.0 is going to partially address the first and second case. I don’t think the third is contemplated yet. The third is also dangerous for accounting so it should be very carefully implemented and certainly not a default condition. The third is sufficiently dangerous that I say NO. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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 with. > 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. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: Scope of GNUCash
😊 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 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 just not sure how to help make it happen (I’m an enthusiastic amateur when it comes to programming). 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). Thanks and regards, Matt From: Adrien Monteleone<mailto:adrien.montele...@gmail.com> Sent: Wednesday, 14 February 2018 2:31 AM To: gnucash-devel<mailto:gnucash-devel@gnucash.org> Subject: Re: Scope of GNUCash Michael, I agree completely on the separation point, especially with regard to controls. I’ve seen first hand when sales clerks have the ability to void and edit their own transactions from a point of sales system. I can’t imagine the damage that WOULD be done if they also had the ability to access the inventory system AND the general accounting software. (even just the ability to partially close a ticket is dangerous) As for interoperability, the devil is always in the details but I see three main hangups. First, any software should be able to import it’s own exports. Second, any software with imports should be able to allow the user an easy way to map fields and save that mapping for future use. Third, importing and exporting should be possible to schedule or trigger without manual user intervention. (so apps can talk to each other reliably without lag) I think 3.0 is going to partially address the first and second case. I don’t think the third is contemplated yet. The third is also dangerous for accounting so it should be very carefully implemented and certainly not a default condition. Regards, Adrien > On Feb 13, 2018, at 8:10 AM, Mike or Penny Novack > wrote: > > On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote: > >> >>> A couple of times I have noticed that people have said "That's not what >>> GNUCash is for". It begs the question - where is it defined what GNUCash is >>> and isn't for? The charter for GNUCash doesn't seem to ever been formalised. >> There is a long term plan, we never write it down because people ask us >> about it :) Is it intended that people should establish a complementary but >> separate project for functionality they want, but is not included in GNUCash >> scope? >> >> I don't see why not if that is what they want to do. > > Since I have been one of the people arguing for "separation" (I think this is > being misunderstood) I want to clarify the reasons and what I mean when I use > the term. > > a) I do NOT mean that needs to be a separate project. Could be part of a > PACKAGE (even installed together) but not a single program. > > b) The reason for separate "packages" that interact with each other rather > than a single program (that a user is or is not allowed to use) is so that > ONE "system" (interacting parts) can be used for all. Those people who are > running "one man band" businesses do not see the problem, do not see why > things like (proposed extensions) like "inventory", "point of sales", > "payroll", etc. cannot be PART of the "general ledger" program. Call these > "one man band" users businesses of class A. > > But there is another sort of business user, call these class B. They have > employees, they have division of responsibility and authority. They may have > need of safeguards. I am not meaning JUST businesses since even a larger > non-profit (call these class C, they might have other needs too) might need > safeguards making embezzlement more difficult. > > These need separation. They need to be able to have people "log in and use" > things like an inventory system or "point of sales" system WITHOUT being able > to access "general ledger. Does not have to be a very large small business > before it has people waiting on customers, stocking inventory, etc. These > people need to be able to do their jobs without being able to access "general > ledger". > > c) A solution with separated subsystems that feed each other would satisfy > the needs of these entities (class B and C) while at the same time satisfy > the needs of entities of class A. The reverse is not true AND not practical > to "first build what would just work for class A and th
Re: Scope of GNUCash
Michael, I agree completely on the separation point, especially with regard to controls. I’ve seen first hand when sales clerks have the ability to void and edit their own transactions from a point of sales system. I can’t imagine the damage that WOULD be done if they also had the ability to access the inventory system AND the general accounting software. (even just the ability to partially close a ticket is dangerous) As for interoperability, the devil is always in the details but I see three main hangups. First, any software should be able to import it’s own exports. Second, any software with imports should be able to allow the user an easy way to map fields and save that mapping for future use. Third, importing and exporting should be possible to schedule or trigger without manual user intervention. (so apps can talk to each other reliably without lag) I think 3.0 is going to partially address the first and second case. I don’t think the third is contemplated yet. The third is also dangerous for accounting so it should be very carefully implemented and certainly not a default condition. Regards, Adrien > On Feb 13, 2018, at 8:10 AM, Mike or Penny Novack > wrote: > > On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote: > >> >>> A couple of times I have noticed that people have said "That's not what >>> GNUCash is for". It begs the question - where is it defined what GNUCash is >>> and isn't for? The charter for GNUCash doesn't seem to ever been formalised. >> There is a long term plan, we never write it down because people ask us >> about it :) Is it intended that people should establish a complementary but >> separate project for functionality they want, but is not included in GNUCash >> scope? >> >> I don't see why not if that is what they want to do. > > Since I have been one of the people arguing for "separation" (I think this is > being misunderstood) I want to clarify the reasons and what I mean when I use > the term. > > a) I do NOT mean that needs to be a separate project. Could be part of a > PACKAGE (even installed together) but not a single program. > > b) The reason for separate "packages" that interact with each other rather > than a single program (that a user is or is not allowed to use) is so that > ONE "system" (interacting parts) can be used for all. Those people who are > running "one man band" businesses do not see the problem, do not see why > things like (proposed extensions) like "inventory", "point of sales", > "payroll", etc. cannot be PART of the "general ledger" program. Call these > "one man band" users businesses of class A. > > But there is another sort of business user, call these class B. They have > employees, they have division of responsibility and authority. They may have > need of safeguards. I am not meaning JUST businesses since even a larger > non-profit (call these class C, they might have other needs too) might need > safeguards making embezzlement more difficult. > > These need separation. They need to be able to have people "log in and use" > things like an inventory system or "point of sales" system WITHOUT being able > to access "general ledger. Does not have to be a very large small business > before it has people waiting on customers, stocking inventory, etc. These > people need to be able to do their jobs without being able to access "general > ledger". > > c) A solution with separated subsystems that feed each other would satisfy > the needs of these entities (class B and C) while at the same time satisfy > the needs of entities of class A. The reverse is not true AND not practical > to "first build what would just work for class A and then modify that to work > for classes B and C". That would be pretty much a complete rewrite. > > d) However, the IS a common element for all the proposed additions (if > separate). They need a way to FEED (send transactions to) general ledger. So > general ledger (gnucash as it is) would need a way to accept feeds. And that > includes a component to "input edit" feeds (make sure all the transactions > coming in are valid, in balance, accounts they refer to exists, etc.) so that > "general ledger" can reject (hopefully with meaningful explanations of the > problems) a feed. > > e) Not discussing at the present time feeds that might be required between > these proposed extensions. For example, we would want a point of sales system > to feed an inventory system. But things like that would not be "in common". > Likewise not yet discussing safeguards (if a feed was not accepted, how is > the system producing this feed temporarily blocked from adding to it. However > I will say that to start, these systems should be designed to work > "asynchronous batch" and only later consider expanding to supporting "real > time update". Again this is a matter of "would work for all" while small > entities could not safely make the assumption that all parts are up << and
Re: Scope of GNUCash
On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote: A couple of times I have noticed that people have said "That's not what GNUCash is for". It begs the question - where is it defined what GNUCash is and isn't for? The charter for GNUCash doesn't seem to ever been formalised. There is a long term plan, we never write it down because people ask us about it :) Is it intended that people should establish a complementary but separate project for functionality they want, but is not included in GNUCash scope? I don't see why not if that is what they want to do. Since I have been one of the people arguing for "separation" (I think this is being misunderstood) I want to clarify the reasons and what I mean when I use the term. a) I do NOT mean that needs to be a separate project. Could be part of a PACKAGE (even installed together) but not a single program. b) The reason for separate "packages" that interact with each other rather than a single program (that a user is or is not allowed to use) is so that ONE "system" (interacting parts) can be used for all. Those people who are running "one man band" businesses do not see the problem, do not see why things like (proposed extensions) like "inventory", "point of sales", "payroll", etc. cannot be PART of the "general ledger" program. Call these "one man band" users businesses of class A. But there is another sort of business user, call these class B. They have employees, they have division of responsibility and authority. They may have need of safeguards. I am not meaning JUST businesses since even a larger non-profit (call these class C, they might have other needs too) might need safeguards making embezzlement more difficult. These need separation. They need to be able to have people "log in and use" things like an inventory system or "point of sales" system WITHOUT being able to access "general ledger. Does not have to be a very large small business before it has people waiting on customers, stocking inventory, etc. These people need to be able to do their jobs without being able to access "general ledger". c) A solution with separated subsystems that feed each other would satisfy the needs of these entities (class B and C) while at the same time satisfy the needs of entities of class A. The reverse is not true AND not practical to "first build what would just work for class A and then modify that to work for classes B and C". That would be pretty much a complete rewrite. d) However, the IS a common element for all the proposed additions (if separate). They need a way to FEED (send transactions to) general ledger. So general ledger (gnucash as it is) would need a way to accept feeds. And that includes a component to "input edit" feeds (make sure all the transactions coming in are valid, in balance, accounts they refer to exists, etc.) so that "general ledger" can reject (hopefully with meaningful explanations of the problems) a feed. e) Not discussing at the present time feeds that might be required between these proposed extensions. For example, we would want a point of sales system to feed an inventory system. But things like that would not be "in common". Likewise not yet discussing safeguards (if a feed was not accepted, how is the system producing this feed temporarily blocked from adding to it. However I will say that to start, these systems should be designed to work "asynchronous batch" and only later consider expanding to supporting "real time update". Again this is a matter of "would work for all" while small entities could not safely make the assumption that all parts are up << and even some VERY LARGE entities do batch feed to general ledger --- I worked for the 43rd? largest "financial >> Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 13/02/2018 01:42, Matt Graham wrote: IIRC the discussion at the time was about whether gnc should or could be used for trading. the result was "no" I said that. A couple of times I have noticed that people have said "That's not what GNUCash is for". It begs the question - where is it defined what GNUCash is and isn't for? The charter for GNUCash doesn't seem to ever been formalised. There is a long term plan, we never write it down because people ask us about it :) Is it intended that people should establish a complementary but separate project for functionality they want, but is not included in GNUCash scope? I don't see why not if that is what they want to do. === From *my* POV I don't see the point in trying to make gnc something it isn't or can't be. Matt, the seniors definitely have direction, they have a plan, they are going somewhere. I'm hoping they get their work done before I get so old I can't contribute :) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel