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 
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=02%7C01%7C%7C6e086cdfd2984fb3c09e08d575be09e6%7C84df9e7fe9f640afb435%7C1%7C0%7C636544381431292259=ept42ukh4Oe%2FFGFqBq8QRyeuGwvUlhwuTLTcsQhKmsY%3D=0
>
> I 

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

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

Re: Docs build failure

[Geert Janssens]

Op vrijdag 16 februari 2018 17:56:12 CET schreef Derek Atkins:
> Hi,
> 
> I finally fixed the docs build to properly build doxygen.cfg now that
> the Makefile.am is gone in master, but then last night (the first run
> since I made the fix) I get this error:
> 
> warning: tag INCLUDE_PATH: include path
> `${CMAKE_SOURCE_DIR}/libgnucash/engine/' does not exist
> warning: tag INPUT: input source `${CMAKE_SOURCE_DIR}/libgnucash' does not
> exist warning: tag INPUT: input source `${CMAKE_SOURCE_DIR}/gnucash' does
> not exist warning: tag INPUT: input source `${CMAKE_SOURCE_DIR}/common'
> does not exist warning: tag INPUT: input source
> `${CMAKE_SOURCE_DIR}/bindings' does not exist warning: tag INPUT: input
> source
> `${CMAKE_SOURCE_DIR}/libgnucash/engine/' does not exist
> 
> Looking more closely, it looks like the version variable was changed
> from @-VERSION-@ to @VERSION@, but it also looks like doxygen.cfg uses
> CMAKE_SOURCE_DIR, but I don't see any way to set that:
> 
> # grep -i CMAKE doxygen.cfg.in
> INPUT  = ${CMAKE_SOURCE_DIR}/libgnucash \
>  ${CMAKE_SOURCE_DIR}/gnucash \
>  ${CMAKE_SOURCE_DIR}/common \
>  ${CMAKE_SOURCE_DIR}/bindings \
>  ${CMAKE_SOURCE_DIR}/libgnucash/engine/
> INCLUDE_PATH   = ${CMAKE_SOURCE_DIR}/libgnucash/engine/
> #
> 
> So what's the "correct" way to do this now?  I suppose I can just change
> my sed command from s:@-top_srcdir-@:${top_srcdir}:g to
> s:\${CMAKE_SOURCE_DIR}:${top_srcdir}:g
> 
> I just need to determine how to properly quote it..
> 
> Were these changes necessary?
> 
I think @CMAKE_SOURCE_DIR@ would have worked just fine as well. cmake's 
configure_file command works with both formats. I don't know why John chose 
the shell-like variable notation.

But yes, the changes were necessary to get configure_file to work. It would 
not work with the @-...-@ notation.

You can probably use
sed -es/'${CMAKE_SOURCE_DIR}'/${top_srcdir}/g

The single quotes around ${CMAKE_SOURCE_DIR} will prevent bash from expanding 
it on the spot. bash will still remove them so sed will see
-es/${CMAKE_SOURCE_DIR}//g

Geert


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

Docs build failure

[Derek Atkins]

Hi,

I finally fixed the docs build to properly build doxygen.cfg now that
the Makefile.am is gone in master, but then last night (the first run
since I made the fix) I get this error:

warning: tag INCLUDE_PATH: include path
`${CMAKE_SOURCE_DIR}/libgnucash/engine/' does not exist
warning: tag INPUT: input source `${CMAKE_SOURCE_DIR}/libgnucash' does not exist
warning: tag INPUT: input source `${CMAKE_SOURCE_DIR}/gnucash' does not exist
warning: tag INPUT: input source `${CMAKE_SOURCE_DIR}/common' does not exist
warning: tag INPUT: input source `${CMAKE_SOURCE_DIR}/bindings' does not exist
warning: tag INPUT: input source
`${CMAKE_SOURCE_DIR}/libgnucash/engine/' does not exist

Looking more closely, it looks like the version variable was changed
from @-VERSION-@ to @VERSION@, but it also looks like doxygen.cfg uses
CMAKE_SOURCE_DIR, but I don't see any way to set that:

# grep -i CMAKE doxygen.cfg.in 
INPUT  = ${CMAKE_SOURCE_DIR}/libgnucash \
 ${CMAKE_SOURCE_DIR}/gnucash \
 ${CMAKE_SOURCE_DIR}/common \
 ${CMAKE_SOURCE_DIR}/bindings \
 ${CMAKE_SOURCE_DIR}/libgnucash/engine/
INCLUDE_PATH   = ${CMAKE_SOURCE_DIR}/libgnucash/engine/
#

So what's the "correct" way to do this now?  I suppose I can just change
my sed command from s:@-top_srcdir-@:${top_srcdir}:g to
s:\${CMAKE_SOURCE_DIR}:${top_srcdir}:g

I just need to determine how to properly quote it..

Were these changes necessary?

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Fwd: Gnucash Userlist

[David Carlson]

-- Forwarded message --
From: David Carlson 
Date: Fri, Feb 16, 2018 at 10:25 AM
Subject: Gnucash Userlist
To: Gnucash Users 


to Wm, Gnucash
Wm, this is a GnuCash miallist, not a political forum. If there was any
useful information in that last spate, I didn't even see it.

Liz, you have my permission to cut him off again.

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

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

[Wm via gnucash-devel]

On 14/02/2018 10:58, Mark Haanen wrote:

Wm via gnucash-devel schreef op 13-02-18 om 17:10:

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


- 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. 


Not really, because the value of the portfolio assets (and therefore the 
value of the different asset classes) change over time.


But not as much as you suggest.

Say my target asset allocation is 10%/90% (as above) and that is the 
ratio in which I divide the amount I use buying my assets (say $100).
However, I don't own $90 of stocks, but rather 2 stock units priced at 
$45. The same for my bond assets (e.g. half a bond currently priced at 
$20).


Over time the prices of the underlying assets in my portfolio change.
For instance, during recession and with quantitative easing in place, 
bond prices climbed while equity prices dropped.##


Except they haven't.  you should *not* expect gnc to do predictive 
pricing.  that is an absolute NO NO NO


So now my 2 stock units are only worth $60 total, while my bond category 
assets climbed to $30.


But that is only in your mind.  My stocks and bonds didn't do that!

All that Alen is saying that he wants a report which compares my target 
ratio of 10/90 with my current value ratio of 33/67, as this may lead to 
a rebalancing of the portfolio.


I am able to say that we do not actually give investment advice.  Usual 
reasons.



I'm thinking at 10 stocks and 90 bonds (without knowing the currency or 
market) it is just a rip off or it is a portfolio for a person that is 
about to die.

==
yeah, I know a senior can whack me for this, but it is in conversation, 
so ... 33 / 67 is super conservative I'd check the switching costs. 
That is how the sales person gets their money.

=

If Mark Haanen / Alen Siljak or anyone else related to them is in a 
client / professional relationship I think we should know.


--
Wm

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

Re: trial balance - how to find mismatch question

[John Ralls]

> On Feb 16, 2018, at 12:20 AM, Adrien Monteleone  
> wrote:
> 
> At least on my version of the Trial Balance report, there is no ‘Imbalance 
> entry’ specifically.
> 
> There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed 
> along with the others.
> 
> There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have 
> the latter, even though the report duration was a single day with no price 
> changes, I gave up trying to figure that one out)
> 
> The ‘imbalance’ I’m speaking of trying to resolve, or at least finally 
> attributed to a rounding error with the XAG account, was simply the 
> difference between what the report shows as Total Debits & Total Credits. 
> (note, these aren’t labeled as such on the report - but they appear at the 
> bottom, and that’s clearly what they are) There is no figure on the report 
> that shows this difference. I had to calculate it manually. When I decided to 
> audit the report for each account is when I found the foreign currency 
> account out of whack. The remaining difference was attributable entirely to 
> the ‘unrealized losses’ line.
> 
> So, the full difference between debits and credi is the SUM of the 
> ‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.
> 
> At least in my case.
> 
> So there are two problems with the report:
> 
> 1) There should be no losses or gains if there were no trading transactions. 
> Certainly, this is impossible if there is only one day on the range of the 
> report and the price is the same. If all you have are opening entries and you 
> attempt to run a trial balance for that same day, you can’t have either a 
> gain or a loss, unrealized or not.
> 
> 2) Because the Equity:Opening Balances account is the result of rounded 
> figures for each entry in a foreign currency, the report’s method of taking 
> the foreign currency ending balance as of a date and doing the exchange rate 
> calculation at the end, will always produce a discrepancy. The report would 
> have to sum the book-default currency amounts individually or somehow a 
> book-default currency balance would have to be maintained and that used 
> instead. Alternatively, a foreign currency account could use the same 
> precision as the foreign currency itself, thus removing the potential for 
> rounding errors if not eliminating them.
> 
> Possibly, increasing the decimal places and re-entering the transactions for 
> the XAG account might resolve the rounding issue. (only because now the USD 
> amounts sum correctly to match since they don’t round enough) But then ALL 
> USD accounts would have this extra precision which is not desirable generally.
> 
> The alternative would be to reduce the precision of the XAG account, but 
> again, that is undesirable for accurate tracking of ownership quantities of 
> the actual metal. (or currency if that’s the case)
> 
> The per-account precision setting seems to only affect the default currency 
> for that account, in this case, XAG, not USD, which seems only to be 
> controlled by the book setting.

Adriene,

Pay close attention to the price source on the Trial Balance report. The 
default value of “Nearest in Time” can produce anomalous results. Try “Average 
Cost”, but be mindful of https://bugzilla.gnome.org/show_bug.cgi?id=775368 
.

The default precision (“smallest commodity unit” or SCU) for an account *is* 
the value for the commodity/currency in which it’s denominated. For most 
currencies that’s 1/100. Prices aren’t rounded by GnuCash, but the prices you 
get from Finance::Quote are, so if you have trades from before 2.6.12 (when 
GnuCash started entering calculated prices into the pricedb) or have replaced 
calculated prices with market prices then you’ll get a rounding error.

Regards,
John Ralls

___
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 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

[MAINT] Planned 1-minute network outage today at 0930 EST

[Derek Atkins]

Hi,

There will be a short (approximately 1 minute) network outage around
0930 EST in order to rewire the router and other core network devices
into a UPS.

You should not notice anything, and the network should come up quickly,
but I wanted to give a warning that this was going to happen today.

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: trial balance - how to find mismatch question

[Christopher Lam]

I like the way this is going. Please describe or file minimal data file
cases in Bugzilla. Perhaps I'll be able to decode the trial balance and we
can decide then what it should really do.

On 16 Feb 2018 19:20, "David T. via gnucash-devel" <
gnucash-devel@gnucash.org> wrote:

> David, Adrien,
> I, too, have encountered many discrepancies in my books with the Trial
> Balance report. I was not able to hammer them out. I gave up, and rely on
> brokerage reports for gains, and assume that the imbalance in the report is
> due to my incomplete understanding of the principles behind it.
> Adrien, I mistakenly said that there would be an imbalance entry on the
> report, but you are noting precisely the discrepancy that I found.
>
> David T.
>
>
>   On Fri, Feb 16, 2018 at 15:58, David Carlson
> wrote:   Adrien,
>
> I am glad that you took the time to research how the report works for the
> data you were able to provide to it.
>
> You have found some valid concerns.  I had not looked at that report for
> quite some time.
>
> As another user with a lot of stock trades, I sometimes use that report to
> find an issue, although I have developed a process involving outside
> spreadsheets to calculate realized gains per security account as GnuCash
> calculates them and net gains as the IRS wants them, so I rarely need the
> report now.  The last time that I used the report I found that when I had a
> security account with not-so-simple combinations of lots being traded or
> when I had an account involving reinvested dividends it was still
> problematic whether I actually matched and resolved all the gains
> correctly.  I deliberately avoided going down the Trading Accounts rabbit
> hole at that time, but it may be worthwhile to give that a fresh look.
>
> Today I am using Windows GnuCash release 2.6.18, and I found that the
> report has changed since sometime in the early 2.6 series when I last used
> it.  For all I know, it may be different again in release 2.6.19 and in
> 2.7/3.0 coming out soon.
>
> Having given you my perspective, I did notice that the report currently
> uses the 'nearest in time' estimate of the date to use when extracting
> values from the currency and commodity tables.  That estimate is a poor
> method to use in my opinion because that often points to a future date when
> there is no value for the target date.  This happens frequently when target
> dates fall on weekends or holidays.  It is possible that Adrien's residual
> imbalance may be at least exacerbated by this point.
>
> Also, I want to thank David T for noticing that in my earlier comments I
> was referring to the unrealized gain imbalance value that this report
> produces rather than the Imbalance accounts that get created when
> individual transactions are incomplete as sometimes happens in transaction
> imports.  That difference is critical to this discussion.  I did fail to
> make that point clear then.
>
> For completeness I should also mention that there are other parameters or
> variables available to adjust in this report which may or may not result in
> differences in the final values reported by a certain instance of the
> report operating on a certain set of data.
>
> There is an option section on adjusting entries and closing entries.  How
> does the report identify these?  There are three report variations under
> the general tab and there is a whole new section on merchandising that
> could impact a report in an undesired way for users that accidentally
> format some data incorrectly.  There is no help to let the user ascertain
> how or if these things affect him.
>
> I will stop here.
>
>
> David C
>
> On Fri, Feb 16, 2018 at 2:20 AM, Adrien Monteleone <
> adrien.montele...@gmail.com> wrote:
>
> > At least on my version of the Trial Balance report, there is no
> ‘Imbalance
> > entry’ specifically.
> >
> > There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed
> > along with the others.
> >
> > There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I
> have
> > the latter, even though the report duration was a single day with no
> price
> > changes, I gave up trying to figure that one out)
> >
> > The ‘imbalance’ I’m speaking of trying to resolve, or at least finally
> > attributed to a rounding error with the XAG account, was simply the
> > difference between what the report shows as Total Debits & Total Credits.
> > (note, these aren’t labeled as such on the report - but they appear at
> the
> > bottom, and that’s clearly what they are) There is no figure on the
> report
> > that shows this difference. I had to calculate it manually. When I
> decided
> > to audit the report for each account is when I found the foreign currency
> > account out of whack. The remaining difference was attributable entirely
> to
> > the ‘unrealized losses’ line.
> >
> > So, the full difference between debits and credits is the SUM of the
> > ‘Unrealized Gains/Losses’ line and the 

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

David, Adrien, 
I, too, have encountered many discrepancies in my books with the Trial Balance 
report. I was not able to hammer them out. I gave up, and rely on brokerage 
reports for gains, and assume that the imbalance in the report is due to my 
incomplete understanding of the principles behind it.  
Adrien, I mistakenly said that there would be an imbalance entry on the report, 
but you are noting precisely the discrepancy that I found. 

David T. 
 
 
  On Fri, Feb 16, 2018 at 15:58, David Carlson 
wrote:   Adrien,

I am glad that you took the time to research how the report works for the
data you were able to provide to it.

You have found some valid concerns.  I had not looked at that report for
quite some time.

As another user with a lot of stock trades, I sometimes use that report to
find an issue, although I have developed a process involving outside
spreadsheets to calculate realized gains per security account as GnuCash
calculates them and net gains as the IRS wants them, so I rarely need the
report now.  The last time that I used the report I found that when I had a
security account with not-so-simple combinations of lots being traded or
when I had an account involving reinvested dividends it was still
problematic whether I actually matched and resolved all the gains
correctly.  I deliberately avoided going down the Trading Accounts rabbit
hole at that time, but it may be worthwhile to give that a fresh look.

Today I am using Windows GnuCash release 2.6.18, and I found that the
report has changed since sometime in the early 2.6 series when I last used
it.  For all I know, it may be different again in release 2.6.19 and in
2.7/3.0 coming out soon.

Having given you my perspective, I did notice that the report currently
uses the 'nearest in time' estimate of the date to use when extracting
values from the currency and commodity tables.  That estimate is a poor
method to use in my opinion because that often points to a future date when
there is no value for the target date.  This happens frequently when target
dates fall on weekends or holidays.  It is possible that Adrien's residual
imbalance may be at least exacerbated by this point.

Also, I want to thank David T for noticing that in my earlier comments I
was referring to the unrealized gain imbalance value that this report
produces rather than the Imbalance accounts that get created when
individual transactions are incomplete as sometimes happens in transaction
imports.  That difference is critical to this discussion.  I did fail to
make that point clear then.

For completeness I should also mention that there are other parameters or
variables available to adjust in this report which may or may not result in
differences in the final values reported by a certain instance of the
report operating on a certain set of data.

There is an option section on adjusting entries and closing entries.  How
does the report identify these?  There are three report variations under
the general tab and there is a whole new section on merchandising that
could impact a report in an undesired way for users that accidentally
format some data incorrectly.  There is no help to let the user ascertain
how or if these things affect him.

I will stop here.


David C

On Fri, Feb 16, 2018 at 2:20 AM, Adrien Monteleone <
adrien.montele...@gmail.com> wrote:

> At least on my version of the Trial Balance report, there is no ‘Imbalance
> entry’ specifically.
>
> There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed
> along with the others.
>
> There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have
> the latter, even though the report duration was a single day with no price
> changes, I gave up trying to figure that one out)
>
> The ‘imbalance’ I’m speaking of trying to resolve, or at least finally
> attributed to a rounding error with the XAG account, was simply the
> difference between what the report shows as Total Debits & Total Credits.
> (note, these aren’t labeled as such on the report - but they appear at the
> bottom, and that’s clearly what they are) There is no figure on the report
> that shows this difference. I had to calculate it manually. When I decided
> to audit the report for each account is when I found the foreign currency
> account out of whack. The remaining difference was attributable entirely to
> the ‘unrealized losses’ line.
>
> So, the full difference between debits and credits is the SUM of the
> ‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.
>
> At least in my case.
>
> So there are two problems with the report:
>
> 1) There should be no losses or gains if there were no trading
> transactions. Certainly, this is impossible if there is only one day on the
> range of the report and the price is the same. If all you have are opening
> entries and you attempt to run a trial balance for that same day, you can’t
> have either a gain or a loss, unrealized or not.

Re: Preference question, issue or not?

[Geert Janssens]

Op vrijdag 16 februari 2018 11:54:41 CET schreef Robert Fewell:
> Hi,
> 
> While I was working out why setting 'don't use gnucash color themes' was
> being reset after every restart of Gnucash, I added a print statement to
> gnc_prefs_get_bool which resulted in loads of output related to the
> preference 'show-leaf-account-names'. Used the glib backtrace function to
> work out what is calling this preference with the following results from
> starting Gnucash for a short time and also moving a terminal window over a
> register page...
> 
> 376 calls to gnc_table_get_entry
> 248 calls to gnc_account_foreach_descendent
> 
> to
> 
> 502 calls to gnc_get_account_name_for_register
> to
> 502 calls to gnc_prefs_get_bool for show-leaf-account-names
> 
> My question is whether the register should hold the value and not keep
> asking the preference system for it which I assume to mean gsettings
> calling what ever back end is being used. It could be cached in some way or
> with the fast PC's nowadays it is of no issue. Just asking before I spend
> any more time on this.
> 
> Regards,
> 
>   Bob

Caching the value would probably be better, although a performance test before 
and after is the only sure way to test.

If you cache it, you should also add a watch function that triggers whenever 
the user changes the preference. When triggered it should cause the register 
to redraw.

Geert


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

Re: trial balance - how to find mismatch question

[David Carlson]

Adrien,

I am glad that you took the time to research how the report works for the
data you were able to provide to it.

You have found some valid concerns.  I had not looked at that report for
quite some time.

As another user with a lot of stock trades, I sometimes use that report to
find an issue, although I have developed a process involving outside
spreadsheets to calculate realized gains per security account as GnuCash
calculates them and net gains as the IRS wants them, so I rarely need the
report now.  The last time that I used the report I found that when I had a
security account with not-so-simple combinations of lots being traded or
when I had an account involving reinvested dividends it was still
problematic whether I actually matched and resolved all the gains
correctly.  I deliberately avoided going down the Trading Accounts rabbit
hole at that time, but it may be worthwhile to give that a fresh look.

Today I am using Windows GnuCash release 2.6.18, and I found that the
report has changed since sometime in the early 2.6 series when I last used
it.  For all I know, it may be different again in release 2.6.19 and in
2.7/3.0 coming out soon.

Having given you my perspective, I did notice that the report currently
uses the 'nearest in time' estimate of the date to use when extracting
values from the currency and commodity tables.  That estimate is a poor
method to use in my opinion because that often points to a future date when
there is no value for the target date.  This happens frequently when target
dates fall on weekends or holidays.  It is possible that Adrien's residual
imbalance may be at least exacerbated by this point.

Also, I want to thank David T for noticing that in my earlier comments I
was referring to the unrealized gain imbalance value that this report
produces rather than the Imbalance accounts that get created when
individual transactions are incomplete as sometimes happens in transaction
imports.  That difference is critical to this discussion.  I did fail to
make that point clear then.

For completeness I should also mention that there are other parameters or
variables available to adjust in this report which may or may not result in
differences in the final values reported by a certain instance of the
report operating on a certain set of data.

There is an option section on adjusting entries and closing entries.  How
does the report identify these?  There are three report variations under
the general tab and there is a whole new section on merchandising that
could impact a report in an undesired way for users that accidentally
format some data incorrectly.  There is no help to let the user ascertain
how or if these things affect him.

I will stop here.


David C

On Fri, Feb 16, 2018 at 2:20 AM, Adrien Monteleone <
adrien.montele...@gmail.com> wrote:

> At least on my version of the Trial Balance report, there is no ‘Imbalance
> entry’ specifically.
>
> There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed
> along with the others.
>
> There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have
> the latter, even though the report duration was a single day with no price
> changes, I gave up trying to figure that one out)
>
> The ‘imbalance’ I’m speaking of trying to resolve, or at least finally
> attributed to a rounding error with the XAG account, was simply the
> difference between what the report shows as Total Debits & Total Credits.
> (note, these aren’t labeled as such on the report - but they appear at the
> bottom, and that’s clearly what they are) There is no figure on the report
> that shows this difference. I had to calculate it manually. When I decided
> to audit the report for each account is when I found the foreign currency
> account out of whack. The remaining difference was attributable entirely to
> the ‘unrealized losses’ line.
>
> So, the full difference between debits and credits is the SUM of the
> ‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.
>
> At least in my case.
>
> So there are two problems with the report:
>
> 1) There should be no losses or gains if there were no trading
> transactions. Certainly, this is impossible if there is only one day on the
> range of the report and the price is the same. If all you have are opening
> entries and you attempt to run a trial balance for that same day, you can’t
> have either a gain or a loss, unrealized or not.
>
> 2) Because the Equity:Opening Balances account is the result of rounded
> figures for each entry in a foreign currency, the report’s method of taking
> the foreign currency ending balance as of a date and doing the exchange
> rate calculation at the end, will always produce a discrepancy. The report
> would have to sum the book-default currency amounts individually or somehow
> a book-default currency balance would have to be maintained and that used
> instead. Alternatively, a foreign currency account could use the same
> precision as 

Preference question, issue or not?

[Robert Fewell]

Hi,

While I was working out why setting 'don't use gnucash color themes' was
being reset after every restart of Gnucash, I added a print statement to
gnc_prefs_get_bool which resulted in loads of output related to the
preference 'show-leaf-account-names'. Used the glib backtrace function to
work out what is calling this preference with the following results from
starting Gnucash for a short time and also moving a terminal window over a
register page...

376 calls to gnc_table_get_entry
248 calls to gnc_account_foreach_descendent

to

502 calls to gnc_get_account_name_for_register
to
502 calls to gnc_prefs_get_bool for show-leaf-account-names

My question is whether the register should hold the value and not keep
asking the preference system for it which I assume to mean gsettings
calling what ever back end is being used. It could be cached in some way or
with the fast PC's nowadays it is of no issue. Just asking before I spend
any more time on this.

Regards,

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

Re: trial balance - how to find mismatch question

[Adrien Monteleone]

At least on my version of the Trial Balance report, there is no ‘Imbalance 
entry’ specifically.

There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed along 
with the others.

There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have the 
latter, even though the report duration was a single day with no price changes, 
I gave up trying to figure that one out)

The ‘imbalance’ I’m speaking of trying to resolve, or at least finally 
attributed to a rounding error with the XAG account, was simply the difference 
between what the report shows as Total Debits & Total Credits. (note, these 
aren’t labeled as such on the report - but they appear at the bottom, and 
that’s clearly what they are) There is no figure on the report that shows this 
difference. I had to calculate it manually. When I decided to audit the report 
for each account is when I found the foreign currency account out of whack. The 
remaining difference was attributable entirely to the ‘unrealized losses’ line.

So, the full difference between debits and credits is the SUM of the 
‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.

At least in my case.

So there are two problems with the report:

1) There should be no losses or gains if there were no trading transactions. 
Certainly, this is impossible if there is only one day on the range of the 
report and the price is the same. If all you have are opening entries and you 
attempt to run a trial balance for that same day, you can’t have either a gain 
or a loss, unrealized or not.

2) Because the Equity:Opening Balances account is the result of rounded figures 
for each entry in a foreign currency, the report’s method of taking the foreign 
currency ending balance as of a date and doing the exchange rate calculation at 
the end, will always produce a discrepancy. The report would have to sum the 
book-default currency amounts individually or somehow a book-default currency 
balance would have to be maintained and that used instead. Alternatively, a 
foreign currency account could use the same precision as the foreign currency 
itself, thus removing the potential for rounding errors if not eliminating them.

Possibly, increasing the decimal places and re-entering the transactions for 
the XAG account might resolve the rounding issue. (only because now the USD 
amounts sum correctly to match since they don’t round enough) But then ALL USD 
accounts would have this extra precision which is not desirable generally.

The alternative would be to reduce the precision of the XAG account, but again, 
that is undesirable for accurate tracking of ownership quantities of the actual 
metal. (or currency if that’s the case)

The per-account precision setting seems to only affect the default currency for 
that account, in this case, XAG, not USD, which seems only to be controlled by 
the book setting.


Regards,
Adrien

> On Feb 15, 2018, at 10:55 PM, David T.  wrote:
> 
> I don’t believe I’ve seen anywhere in this thread any attempt to explain that 
> there is a difference between IMBALANCE-XXX (an indication that you have 
> transactions that lacked a balancing split) and the Imbalance entry in the 
> Trial Balance report. This latter most likely indicates (as David C. has 
> hinted) that your books have capital or currency gains or losses that haven’t 
> been entered into the books. If you buy a stock for $100 using a balanced 
> transaction, and later sell that share for $150 (we wish!) in a balanced 
> transaction, GnuCash will wonder where you got an additional $50. Both 
> transactions balance, but the books don’t. That is why you usually have an 
> entry (either as a separate transaction, or as splits in the sell 
> transaction) that account for this gain.
> 
> Of course, it can get complex. 
> 
> David T.
> 
>> On Feb 16, 2018, at 7:31 AM, Christopher Lam  
>> wrote:
>> 
>> Hi Adrien, could you distil this to a minimal test file and submit in a bug
>> report and include relevant report and report parameters? C
>> 
>> On 16 Feb 2018 10:09, "Adrien Monteleone" 
>> wrote:
>> 
>>> How timely.
>>> 
>>> Any way to solve this or do I just chalk it up?
>>> 
>>> Regards,
>>> Adrien
>>> 
 On Feb 15, 2018, at 8:00 PM, David Carlson 
>>> wrote:
 
 If you have multiple currencies  or if you buy and sell commodities or
>>> securities  there is another level of opportunities for issues.
 
 David  C
 
 On Feb 15, 2018 5:55 PM, "Adrien Monteleone" <
>>> adrien.montele...@gmail.com> wrote:
 I just noticed the subject was wrong due to a user-digest error,
>>> re-applying the original.
 
 ———
 
 I’m having a bit of issue understanding the point of the trial-balance
>>> report in modern times. (I generally don’t use it as I mentioned)
 
 If each transaction self-balances, that is, debits = credits, how is