Re: price.date, transaction.post_date and neutral time

[Sébastien de Menten]

On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> On 12/02/2018 21:00, Sébastien de Menten wrote:
>
>> When I enter a new price for a given day for a security on the NASDAQ via
>> the price editor, it is stored in the date column the UTC time for that
>> day
>> at 00:00:00 local time (CET=Europe, not EST=New-York). Which is weird
>> because across timezone, the day of the price will be interpreted
>> differently.
>>
>
> Are you entering the prices by hand ?
>
> indeed, "via the price editor" (source=user:price-editor in the prices
table)


> But John R says "that's an absolute time anchored in the market's time
>> zone, not the user's. " which leaves me puzzled as for the example above
>> on
>> the NASDAQ it uses European time (i.e.my local time) not NASDAQ time. But
>> maybe when using the Perl finance quote program, there is a more complete
>> time information (incl the correct market timezone).
>>
>
> If you are entering the prices yourself then it seems sensible to me the
> time is when you made the entry rather than the market's time.
>
> yes, indeed. John's comment made me doubt ...
if I use the price editor for today (source=user:price-editor), I get as
date 2012/02/12 23:00:00 (because I am in UTC+1)
if I edit a transaction for today on that commodity
(source=user:xfer-dialog), then I get as date 2012/02/13 10:59:00 (which is
the post_date of the transaction which uses GnuCash "neutral time" concept.
I haven't tried yet via the Finance:Quote as it doesn't install easily
under my setup (windows, non admin) but I would be curious to see what ends
up in the date column in this case.



> Also, unless you have a special arrangement with a broker, most people
> don't get a market price, it will be a bit under or over so the market
> price is just for reference once you include tx costs, etc.
>
> Anyway, my question was to understand the reasons of the encoding of a
>> day/date as an instant/datetime, reasons that are still a bit obscure
>> (except legacy issue)
>>
>
> For most purposes it shouldn't matter.  The prices db is independent of
> the actual transactions, it is used for working out the value of stuff and,
> as I am sure you are aware, the value of commodities changes every minute
> and second ... gnc is *never* going to keep up with that sort of price
> change.
>
> In retrospect it may be thought that the design mistake was including a
> time in the price db at all :)


That's exaclty my point ;-)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Alen Siljak]

> Sent: Tuesday, February 13, 2018 at 8:13 AM
> From: "Wm via gnucash-devel" 
> To: gnucash-de...@lists.gnucash.org
> Subject: Re: price.date, transaction.post_date and neutral time
>
> That is interesting.  There has been quite a lot of enthusiasm for 
> mobile / gnc interaction.  Have you written about this before and I 
> missed it ?  If MMEX for Android is working well with gnc I think you 
> should make a wiki entry and ignore my view on MMEX as an accounting app.

Done. https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices

> Aside: I am completely confused how MMEX for Android could be used for 
> Asset Allocation, MMEX doesn't understand Assets and Liabilities and 
> Equity!  Looking at the forums, the dev's of MMEX haven't realised that 
> prices aren't available from Y! any more, etc.  Crazy.  If the MMEX for 
> Android app is moving beyond MMEX itself and may be working better with 
> gnc then please let us know,

It's very simple really. MMEX schema supports Asset and Investment accounts. 
For me, AA is really very simple: 

- we set the allocation. I.e. 10% stocks, 90% bonds.
- we enter the investments we own, i.e. Stocks Fund, Bonds Fund, Direct Bond, 
favorite company ABC stock, etc. 
- we link the investments (by symbol) to the allocation classes above.
  Stocks Fund => stocks
  Bonds Fund => bonds
  Direct Bond => bonds
  ABC => stocks
- we get the latest prices

All that computer software needs to do (and, deep into 21st century this is the 
least I'd expect my personal finance app to do) is to calculate the current 
value of the holdings, therefore asset classes, and say:
"you have 50K in investments, out of which 30% is in stocks and 70% in bonds, 
while your allocation is 10%/90%".

> Asset Allocation is indeed simple, the problem is that no two people 
> agree on how to do it :)
> 
> Further, most AA models are USA biased, I don't think gnc needs any more 
> USA bias and any model that includes a stock allocation along the lines 
> of "domestic / foreign" is rubbish if you live outside of the USA so 
> let's not go there! [1]

OK. This is an interesting distinction. Are we talking about AA as a concept or 
a concrete AA implementation (values)? This is kinda class/instance 
relationship. I'm strictly interested in providing a tool that allows working 
with AA as a concept, and leave the actual implementation to the user. They can 
work out their allocations in any way they prefer but the tool should be 
accessible and use the portfolio data from a GC book.
Just like a text editor, it does not tell you how to write but lets you write 
some text, save it, view/edit it later, and share it with someone else.

> for a sanity check, I am certain the good people that maintain the code 
> that allows us to get prices do *not* try to maintain a complete db of 
> prices themselves.  there is, quite simply, too much information.

Nobody mentioned a complete db of prices but separating Price information from 
the rest of the book. Prices are expendable and, as you say, can be retrieved 
independently. As they are independent of a book, they can be shared across 
multiple books and/or applications. Which is where I'm coming from. And price 
information is pretty much the same for any application. It has basic 
properties of Date(/Time), Symbol, and Value.

> you haven't been looking, there are hundreds of AA implementations, 
> maybe you mean you haven't found many that agree with your 
> preconceptions ? AA is often about preconceptions.

Good advice. I see a few implementations, thanks to Python being so accessible. 
However, it seems that most of them are dealing with calculating an optimal 
allocation rather than letting the user manage it, the way ledger-cli (or MMEX 
4 Android) does.

> Heh, you just outed yourself as a bad trader :)  A "good" trader doesn't 
> care about capital gains :)

I don't really. But I have to report on it to the tax authorities every year. ;)

On a side note, I'm pretty amazed how few people are interested in AA 
considering that they are the masters of their own fortune in countries with 
private pension funds. In countries like Australia, each person is responsible 
for choosing their superannuation fund, including the asset allocation.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 13/02/2018 09:12, Alen Siljak wrote:


Done. https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices


sweet


Aside: I am completely confused how MMEX for Android could be used for
Asset Allocation, MMEX doesn't understand Assets and Liabilities and
Equity!  Looking at the forums, the dev's of MMEX haven't realised that
prices aren't available from Y! any more, etc.  Crazy.  If the MMEX for
Android app is moving beyond MMEX itself and may be working better with
gnc then please let us know,


It's very simple really. MMEX schema supports Asset and Investment accounts. 
For me, AA is really very simple:

- we set the allocation. I.e. 10% stocks, 90% bonds.


wow, you're a lot older than I expected if your stock / bond allocation 
is usual, damn near dead or very unforgiving about the world's economies



- we enter the investments we own, i.e. Stocks Fund, Bonds Fund, Direct Bond, 
favorite company ABC stock, etc.
- we link the investments (by symbol) to the allocation classes above.
   Stocks Fund => stocks
   Bonds Fund => bonds
   Direct Bond => bonds
   ABC => stocks
- we get the latest prices


That's looking self referential to me as your plan allows for a 1.75% 
government bond to be called a stock and a stock to be called a bond.


all a bit pointless.


All that computer software needs to do (and, deep into 21st century this is the 
least I'd expect my personal finance app to do) is to calculate the current 
value of the holdings, therefore asset classes, and say:
"you have 50K in investments, out of which 30% is in stocks and 70% in bonds, while 
your allocation is 10%/90%".


Isn't that just back referencing ?

I own a dog, I check my dog ownership and find I own a dog.

Neither I or the dog should be surprised.


Asset Allocation is indeed simple, the problem is that no two people
agree on how to do it :)

Further, most AA models are USA biased, I don't think gnc needs any more
USA bias and any model that includes a stock allocation along the lines
of "domestic / foreign" is rubbish if you live outside of the USA so
let's not go there! [1]


OK. This is an interesting distinction. Are we talking about AA as a concept or a concrete AA implementation (values)? 


I think reality is preferable, I have actual money and presume you do too.


This is kinda class/instance relationship. I'm strictly interested in providing 
a tool that allows working with AA as a concept, and leave the actual 
implementation to the user.


hmmmn.  why?


They can work out their allocations in any way they prefer but the tool should 
be accessible and use the portfolio data from a GC book.
Just like a text editor, it does not tell you how to write but lets you write 
some text, save it, view/edit it later, and share it with someone else.


If you aren't really interested in doing stuff how about you fuck off 
and stop bothering people ?  Has it occurred to you that AA is a real 
thing for real people ?



for a sanity check, I am certain the good people that maintain the code
that allows us to get prices do *not* try to maintain a complete db of
prices themselves.  there is, quite simply, too much information.


Nobody mentioned a complete db of prices but separating Price information from the rest of the book. 


gnc does that anyway.


Prices are expendable and, as you say, can be retrieved independently. As they 
are independent of a book, they can be shared across multiple books and/or 
applications. Which is where I'm coming from. And price information is pretty 
much the same for any application. It has basic properties of Date(/Time), 
Symbol, and Value.


that isn't a discovery.


you haven't been looking, there are hundreds of AA implementations,
maybe you mean you haven't found many that agree with your
preconceptions ? AA is often about preconceptions.


Good advice. I see a few implementations, thanks to Python being so accessible. 
However, it seems that most of them are dealing with calculating an optimal 
allocation rather than letting the user manage it, the way ledger-cli (or MMEX 
4 Android) does.


nope, I think you misunderstand AA models entirely


Heh, you just outed yourself as a bad trader :)  A "good" trader doesn't
care about capital gains :)


I don't really. But I have to report on it to the tax authorities every year. ;)

On a side note, I'm pretty amazed how few people are interested in AA 
considering that they are the masters of their own fortune in countries with 
private pension funds. In countries like Australia, each person is responsible 
for choosing their superannuation fund, including the asset allocation.



Alen, I think someone is going to say "get a room, you two" fairly soon 
as we are definitely drifting off topic.  I think I still have a MMEX 
forum account from a while ago so maybe we can meet there.  They won't 
have a clue what we are talking about but do you care?


--
Wm

___
gnucash-devel mailing list

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: price.date, transaction.post_date and neutral time

[Wm]

On 13/02/2018 12:47, Sébastien de Menten wrote:

On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel <
gnucash-devel@gnucash.org> wrote:


On 12/02/2018 21:00, Sébastien de Menten wrote:


When I enter a new price for a given day for a security on the NASDAQ via
the price editor, it is stored in the date column the UTC time for that
day
at 00:00:00 local time (CET=Europe, not EST=New-York). Which is weird
because across timezone, the day of the price will be interpreted
differently.



Are you entering the prices by hand ?

indeed, "via the price editor" (source=user:price-editor in the prices

table)


OK, I'm not seeing the problem.  Isn't gnc behaving as expected ?


But John R says "that's an absolute time anchored in the market's time

zone, not the user's. " which leaves me puzzled as for the example above
on
the NASDAQ it uses European time (i.e.my local time) not NASDAQ time. But
maybe when using the Perl finance quote program, there is a more complete
time information (incl the correct market timezone).



If you are entering the prices yourself then it seems sensible to me the
time is when you made the entry rather than the market's time.

yes, indeed. John's comment made me doubt ...

if I use the price editor for today (source=user:price-editor), I get as
date 2012/02/12 23:00:00 (because I am in UTC+1)
if I edit a transaction for today on that commodity
(source=user:xfer-dialog), then I get as date 2012/02/13 10:59:00 (which is


Oh, ffs.  Sebastien are you really entering prices from 5 years ago ???
by hand ???
and wondering about the fucking time ???

I have respect for you.  Please have some respect for yourself and how 
other people regard you.



the post_date of the transaction which uses GnuCash "neutral time" concept.
I haven't tried yet via the Finance:Quote as it doesn't install easily
under my setup (windows, non admin) but I would be curious to see what ends
up in the date column in this case.


If I look at my raw xml file F::Q gives me
===

  2018-02-09 12:00:00 +

===
which is correct, does everyone get something different ?

I say, if you are entering by hand it *should* be the entry time not the 
market time.



Also, unless you have a special arrangement with a broker, most people
don't get a market price, it will be a bit under or over so the market
price is just for reference once you include tx costs, etc.

Anyway, my question was to understand the reasons of the encoding of a

day/date as an instant/datetime, reasons that are still a bit obscure
(except legacy issue)



For most purposes it shouldn't matter.  The prices db is independent of
the actual transactions, it is used for working out the value of stuff and,
as I am sure you are aware, the value of commodities changes every minute
and second ... gnc is *never* going to keep up with that sort of price
change.

In retrospect it may be thought that the design mistake was including a
time in the price db at all :)



That's exaclty my point ;-)


OK, Mr SdM are you saying the point is that there shouldn't be a time at 
all ?


If so I think John said he'll get around to fixing that as and when.  I 
don't see the point in arguing about an hour or two 5 years ago which 
seems to be what you started :(


--
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 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: price.date, transaction.post_date and neutral time

[Sébastien de Menten]

r/2012/2018/ (it was a typo)
My point is that a price entered via the price editor (manually) is handled
differently than a price generated via a transaction and may be (haven't
tested) different than a price downloaded via the Finance:Quote module.
And indeed, as the time component is meaningless (yet different in function
on the price creation method), it shouldn't be stored OR, if for legacy
reason it should be kept, it could at least be stored consistently (across
price creation method) using for instance the "neutral time" approach used
for the post_date.
If not, any extract of price data (direct SQL, XML, piecash, ...) is
complex to use.

On Feb 13, 2018 15:47, "Wm"  wrote:

> On 13/02/2018 12:47, Sébastien de Menten wrote:
>
>> On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel <
>> gnucash-devel@gnucash.org> wrote:
>>
>> On 12/02/2018 21:00, Sébastien de Menten wrote:
>>>
>>> When I enter a new price for a given day for a security on the NASDAQ via
 the price editor, it is stored in the date column the UTC time for that
 day
 at 00:00:00 local time (CET=Europe, not EST=New-York). Which is weird
 because across timezone, the day of the price will be interpreted
 differently.


>>> Are you entering the prices by hand ?
>>>
>>> indeed, "via the price editor" (source=user:price-editor in the prices
>>>
>> table)
>>
>
> OK, I'm not seeing the problem.  Isn't gnc behaving as expected ?
>
> But John R says "that's an absolute time anchored in the market's time
>>>
 zone, not the user's. " which leaves me puzzled as for the example above
 on
 the NASDAQ it uses European time (i.e.my local time) not NASDAQ time.
 But
 maybe when using the Perl finance quote program, there is a more
 complete
 time information (incl the correct market timezone).


>>> If you are entering the prices yourself then it seems sensible to me the
>>> time is when you made the entry rather than the market's time.
>>>
>>> yes, indeed. John's comment made me doubt ...
>>>
>> if I use the price editor for today (source=user:price-editor), I get as
>> date 2012/02/12 23:00:00 (because I am in UTC+1)
>> if I edit a transaction for today on that commodity
>> (source=user:xfer-dialog), then I get as date 2012/02/13 10:59:00 (which
>> is
>>
>
> Oh, ffs.  Sebastien are you really entering prices from 5 years ago ???
> by hand ???
> and wondering about the fucking time ???
>
> I have respect for you.  Please have some respect for yourself and how
> other people regard you.
>
> the post_date of the transaction which uses GnuCash "neutral time" concept.
>> I haven't tried yet via the Finance:Quote as it doesn't install easily
>> under my setup (windows, non admin) but I would be curious to see what
>> ends
>> up in the date column in this case.
>>
>
> If I look at my raw xml file F::Q gives me
> ===
> 
>   2018-02-09 12:00:00 +
> 
> ===
> which is correct, does everyone get something different ?
>
> I say, if you are entering by hand it *should* be the entry time not the
> market time.
>
> Also, unless you have a special arrangement with a broker, most people
>>> don't get a market price, it will be a bit under or over so the market
>>> price is just for reference once you include tx costs, etc.
>>>
>>> Anyway, my question was to understand the reasons of the encoding of a
>>>
 day/date as an instant/datetime, reasons that are still a bit obscure
 (except legacy issue)


>>> For most purposes it shouldn't matter.  The prices db is independent of
>>> the actual transactions, it is used for working out the value of stuff
>>> and,
>>> as I am sure you are aware, the value of commodities changes every minute
>>> and second ... gnc is *never* going to keep up with that sort of price
>>> change.
>>>
>>> In retrospect it may be thought that the design mistake was including a
>>> time in the price db at all :)
>>>
>>
>>
>> That's exaclty my point ;-)
>>
>
> OK, Mr SdM are you saying the point is that there shouldn't be a time at
> all ?
>
> If so I think John said he'll get around to fixing that as and when.  I
> don't see the point in arguing about an hour or two 5 years ago which seems
> to be what you started :(
>
> --
> 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

[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
Sent: Wednesday, 14 February 2018 2:31 AM
To: gnucash-devel
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 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 

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 13/02/2018 18:12, Sébastien de Menten wrote:

r/2012/2018/ (it was a typo)


ok


My point is that a price entered via the price editor (manually) is handled
differently than a price generated via a transaction 


Isn't that a good thing ? I shouldn't have to say again that the price 
db is just for reference, it doesn't change the tx just their valuations 
at a point in time for reporting purposes.  From a strict accounting POV 
gnc doesn't need the price db at all because you are allowed to value 
your assets at however much you want.  The tax lady may disagree, of 
course :)


> > and may be (haven't

tested) different than a price downloaded via the Finance:Quote module.


It will almost certainly be different, different exchanges have 
different prices, there are people that make a lot of money noticing the 
small differences between exchanges and trading based on those differences.



And indeed, as the time component is meaningless (yet different in function
on the price creation method), it shouldn't be stored OR, if for legacy
reason it should be kept, it could at least be stored consistently (across
price creation method) using for instance the "neutral time" approach used
for the post_date.
If not, any extract of price data (direct SQL, XML, piecash, ...) is
complex to use.


I don't see the complexity. Why don't you just discard the time 
component as it is essentially meaningless after 24 or 48 hours ?


Isn't your typo a good observation in that it shows that time isn't the 
significant part of the price record ?


P.S. I don't like arguing with you, Sebastien, it is better when we agree :)

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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  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
> Sent: Wednesday, 14 February 2018 2:31 AM
> To: gnucash-devel
> 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 

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: price.date, transaction.post_date and neutral time

[David T. via gnucash-devel]

Wm, Sebastien,

I profess to not paying too much attention to this thread, but IIRC, there was 
a time when the price entered into transactions was NOT entered into the price 
DB, which meant that users would often get useless reports on commodities, 
since the reports use price DB entries to calculate figures. The workaround was 
to add transaction-generated prices to the Price DB as well, thus (seemingly) 
killing two birds with one mouse click. I suspect that when John did work to 
decide on a new timezone neautral solution to the timestamp issue, he didn’t 
adjust this code as well.

Given the nature of these entries (i.e., added from the transaction to document 
a price that was valid at some arbitrary point in the past), I don’t see how a 
specific time could be added (as it might be with F::Q prices). Ditto 
manually-added prices.

Cheers,
David


> On Feb 14, 2018, at 3:19 AM, Wm via gnucash-devel  
> wrote:
> 
> On 13/02/2018 18:12, Sébastien de Menten wrote:
>> r/2012/2018/ (it was a typo)
> 
> ok
> 
>> My point is that a price entered via the price editor (manually) is handled
>> differently than a price generated via a transaction 
> 
> Isn't that a good thing ? I shouldn't have to say again that the price db is 
> just for reference, it doesn't change the tx just their valuations at a point 
> in time for reporting purposes.  From a strict accounting POV gnc doesn't 
> need the price db at all because you are allowed to value your assets at 
> however much you want.  The tax lady may disagree, of course :)
> 
> > > and may be (haven't
>> tested) different than a price downloaded via the Finance:Quote module.
> 
> It will almost certainly be different, different exchanges have different 
> prices, there are people that make a lot of money noticing the small 
> differences between exchanges and trading based on those differences.
> 
>> And indeed, as the time component is meaningless (yet different in function
>> on the price creation method), it shouldn't be stored OR, if for legacy
>> reason it should be kept, it could at least be stored consistently (across
>> price creation method) using for instance the "neutral time" approach used
>> for the post_date.
>> If not, any extract of price data (direct SQL, XML, piecash, ...) is
>> complex to use.
> 
> I don't see the complexity. Why don't you just discard the time component as 
> it is essentially meaningless after 24 or 48 hours ?
> 
> Isn't your typo a good observation in that it shows that time isn't the 
> significant part of the price record ?
> 
> P.S. I don't like arguing with you, Sebastien, it is better when we agree :)
> 
> -- 
> 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

[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

[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

[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]

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
Sent: Wednesday, 14 February 2018 11:35 AM
To: 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 accounting.  My point in that regard