Re: Scope of GNUCash

[Wm via gnucash-devel]

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

[Wm via gnucash-devel]

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

[Matt Graham]

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 <christopher@gmail.com>
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=02%7C01%7C%7C6e086cdfd2984fb3c09e08d575be09e6%7C84df9e7fe9f640afb435%7C1%7C0%7C636544381431292259=vgDy3yjfROI78M18qn83rzwvyefWUczMecs48Dfb2XU%3D=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-budget.html=0

Re: Scope of GNUCash

[Christopher Lam]

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.
   Life should be enjoyable a

Re: Scope of GNUCash

[Matt Graham]

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 <gnucash-devel@gnucash.org>
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=02%7C01%7C%7C12c69052d26a43da4aca08d5754c98ba%7C84df9e7fe9f640afb435%7C1%7C0%7C636543894193512179=6c8JMa5%2B35IVM7wsPhH3zM3529gUgGpO7VtoEYz0UqI%3D=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 not what GNUC

Re: Scope of GNUCash

[David Carlson]

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 

Re: Scope of GNUCash

[Wm via gnucash-devel]

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 

Re: Scope of GNUCash

[Wm via gnucash-devel]

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

[Wm via gnucash-devel]

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


___

Re: Scope of GNUCash

[Wm via gnucash-devel]

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

[Wm via gnucash-devel]

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

[Mike or Penny Novack]

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

[Mike or Penny Novack]

 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

[Mike or Penny Novack]

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

[Matt Graham]

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't cover
using plain text 

Re: Scope of GNUCash

[Christopher Lam]

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 

Re: Scope of GNUCash

[Adrien Monteleone]

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 

Re: Scope of GNUCash

[David T. via gnucash-devel]

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 <matt_graham2...@hotmail.com> 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 
>> <stepbystepf...@dialup4less.com> 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 
&

Re: Scope of GNUCash

[Wm via gnucash-devel]

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

[Wm via gnucash-devel]

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

[Matt Graham]

 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 
> <stepbystepf...@dialup4less.com> 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 

Re: Scope of GNUCash

[Adrien Monteleone]

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 

Re: Scope of GNUCash

[Mike or Penny Novack]

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

[Wm via gnucash-devel]

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