Re: [GNC-dev] Windows Wiki page

[David Carlson]

I am very happy to see that you are looking critically at this page.  My
only comment would be that even recently there was a comment in the user
maillist from a user that was still using release 2.4.something, so I think
some history should be kept that such users can easily find.  Of course it
should be marked as deprecated and segregated in some way from current info.

I am a windows user, so I can take a look at that section, but I have not
migrated to release 3.2, so my experience is slightly dated.

David C

On Thu, Aug 16, 2018 at 2:26 PM, David T. via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> Hello,
>
> I had reason to click on the Windows wiki page (https://wiki.gnucash.org/
> wiki/Windows ), and I think that
> there is a lot of information parked there that should be placed elsewhere
> or removed. I am hesitant to edit this page in part because I do not use
> Windows, and cannot speak from personal experience. Furthermore, I would
> like to get input from the group before I undertake a major edit on the
> page.
>
> Information that should placed elsewhere includes sections 1.3, 1.4 and
> 1.7. These sections explain general functionality that should be available
> to all GC users through the FAQ. Windows-specific notes could be
> incorporated into the resulting pages.
>
> In addition, I think the Q/A format is stilted and not helpful on this
> page. I would rewrite it as straightforward prose.
>
> Finally, I see a lot of elements that are dated (F::Q, sections 2 and 3),
> and I see mention that issues related to older versions are moved to an
> Older issues page. They underscore the fact that such structures lend
> themselves to obsolescence, since information gets added to these
> structures, but is rarely pruned or updated. Perhaps the older issues could
> simply be deleted, and the wiki focus on providing information on the
> currently-supported versions?
>
> Cheers,
> David T.
> ___
> 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

[GNC-dev] Wiki Proposal

[David T. via gnucash-devel]

Sorry to bombard the list with so many messages!

As you’ve no doubt surmised, I am back to digging into the various 
documentation for GnuCash, including the Guide and the wiki. 

In reference to editing the "XML Format” wiki page, Geert mentioned preferring 
that the wiki cover information about the current release and one or two 
previous releases. 

I personally agree with that idea; it would give a clear guideline for what 
should stay, and what should be removed.

However, determining what those versions should be might be difficult for some 
of us (like me!). I think it would be useful to have a simple, public, 
statement (on the home page?) of the currently-supported versions. This 
statement could be autoupdated as new versions are released.

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

[GNC-dev] Windows Wiki page

[David T. via gnucash-devel]

Hello,

I had reason to click on the Windows wiki page 
(https://wiki.gnucash.org/wiki/Windows 
), and I think that there is a lot of 
information parked there that should be placed elsewhere or removed. I am 
hesitant to edit this page in part because I do not use Windows, and cannot 
speak from personal experience. Furthermore, I would like to get input from the 
group before I undertake a major edit on the page.

Information that should placed elsewhere includes sections 1.3, 1.4 and 1.7. 
These sections explain general functionality that should be available to all GC 
users through the FAQ. Windows-specific notes could be incorporated into the 
resulting pages.

In addition, I think the Q/A format is stilted and not helpful on this page. I 
would rewrite it as straightforward prose.

Finally, I see a lot of elements that are dated (F::Q, sections 2 and 3), and I 
see mention that issues related to older versions are moved to an Older issues 
page. They underscore the fact that such structures lend themselves to 
obsolescence, since information gets added to these structures, but is rarely 
pruned or updated. Perhaps the older issues could simply be deleted, and the 
wiki focus on providing information on the currently-supported versions?

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

[GNC-dev] Main WIki Page edit

[David T. via gnucash-devel]

Hello,

I was reviewing the Wiki today to try to figure out where a page on the SQL 
formats might get attached, and I noticed a change to the Glossary section that 
makes for awkward English.

As currently entered, the section reads:

Above GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
[https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html Released] or 
[https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html Maintainer] 
version.

However, it used to say:

The GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
[https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html Released] or 
[https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html Maintainer] 
version.

I would like to ask that someone with edit permissions on the wiki home page to 
please change the word “Above” back to “The” to make the section read more 
idiomatically.

David T.

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

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[David T. via gnucash-devel]

Hi,

I admit that I haven’t been following the details of thsi thread that closely, 
but it would seem to me that if a user has selected price source “Latest,” then 
the report will of necessity include an Unrealized Gains line in order to 
balance, as John said. I agree with his suggestion that Unrealized Gains might 
not belong in a Balance Sheet report, but I note that as a personal user of 
GnuCash, I am rather interested in the current value of my empire, ephemeral 
though it may be. I’m eager to see how rich I am Right Now! Bwa Ha Ha Ha!

Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
accounting to refer to a particular general type of report and content (I base 
this on the fact that Googling “Balance Sheet report definition” yields 
numerous accounting websites with explanations of what a balance sheet is and 
does), perhaps there could be a separately-identified and named report to give 
the armchair trader the putative value of their holdings as of a given date. 
Then the Balance Sheet could be dedicated to the real world situation (i.e., no 
need for the PriceDB at all—just use the transaction prices), while the new 
report could include unrealized gains explicitly. A descriptive name (“Trade 
Value”? “Speculative Value”? “Castles in the Sand”?) could help make clear the 
difference between the two.

David

> On Aug 16, 2018, at 7:30 AM, John Ralls  wrote:
> 
> Chris,
> 
> That’s because you used price source = “latest” which uses the most recent 
> price in the pricedb for the purchase as well as the valuation.
> 
> Regards,
> John Ralls
> 
>> On Aug 16, 2018, at 12:58 AM, Christopher Lam  
>> wrote:
>> 
>> Hi John
>> 
>> Just to be a pain again... I found a small discrepancy - (This is different 
>> from the previously noted missing-capital-gains situation)
>> 
>> if trading-accounts are enabled,
>> a single 100AAPL purchase @ $100 each dated 01/01/18
>> a new increased price $200 on 01/06/18 is recorded, 
>> price-source is 'latest' to pick up the new price
>> There's no trade sale yet -- this means 'trading gains' is $0 -- indeed the 
>> book will not have any Trading accounts yet.
>> 
>> I'd expect the balance-sheet to record the increased price as 'unrealized 
>> gain'.
>> 
>> Yet the balance-sheet just displays an increased FUNDS valuation at $20,000 
>> (i.e. total assets = $2) without a corresponding increase in 
>> right-hand-side (ie total equity+liability=$1).
>> 
>> I'd think the 'correct' balance sheet with trading-accounts enabled, 
>> *should* still report Unrealized Gains, no?
>> 
>> 
>> On 13/08/18 22:51, John Ralls wrote:
>>> 
>>> 
 On Aug 12, 2018, at 10:04 PM, Christopher Lam >>> > wrote:
 
 Hi Jralls
 
 So just wish to double check my understanding of gnucash's data format for 
 a balance-sheet on date X
 
 There are two possibilities for displaying the right-hand-side
 
 Liabilities + Equity + Retained Earnings + Trading Balances
 Liabilities + Equity + Retained Earnings + Unrealized Gains
 "Retained Earnings" should be NULL if the user has properly closed the 
 books on the balance sheet date X.
 
 In my understanding, "Trading Balances" and "Unrealized Gains" are one and 
 the same -- in balance-sheet.scm the unrealized-gain-collector is only 
 populated if book->trading-accounts setting is disabled. (btw this causes 
 a 'bug' whereby a book with 'enable-trading-accounts', but was later 
 switched to 'disable-trading-accounts' will then add both the 
 unrealized-gain-collector and the trading-balance the right-hand-side).
 
 This seems to be deconstruct current balance-sheet?
 
 (I can't seem to find any unrealized-gain issue... from using different 
 price-sources... perhaps this is beyond my understanding.)
 
 
 On 11/08/18 22:41, John Ralls wrote:
> Chris,
> 
> Remember that we’ve long advised users that they need not close their 
> books, they can run a balance sheet report for any day. IMO removing that 
> capability would be a major breakage.
> 
> I suspect that you needed to use trading accounts because you didn’t book 
> the trading gains and losses as income. Users should do that regardless 
> of using trading accounts and doing so should make it unnecessary for the 
> balance sheet report to include trading accounts.
> 
> Unrealized gains are another matter entirely and are a result of using 
> prices from the price database instead of actual cost from the 
> transaction data. IMO the balance sheet report shouldn’t be taking prices 
> from the price db and shouldn’t be able to see unrealized gains, but if 
> price source is going to be an option then an unrealized gains line flows 
> from that so that users don’t waste a bunch of time chasing an imbalance 
> caused by price differences.
> 
> 

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[John Ralls]

Chris,

That’s because you used price source = “latest” which uses the most recent 
price in the pricedb for the purchase as well as the valuation.

Regards,
John Ralls

> On Aug 16, 2018, at 12:58 AM, Christopher Lam  
> wrote:
> 
> Hi John
> 
> Just to be a pain again... I found a small discrepancy - (This is different 
> from the previously noted missing-capital-gains situation)
> 
> if trading-accounts are enabled,
> a single 100AAPL purchase @ $100 each dated 01/01/18
> a new increased price $200 on 01/06/18 is recorded, 
> price-source is 'latest' to pick up the new price
> There's no trade sale yet -- this means 'trading gains' is $0 -- indeed the 
> book will not have any Trading accounts yet.
> 
> I'd expect the balance-sheet to record the increased price as 'unrealized 
> gain'.
> 
> Yet the balance-sheet just displays an increased FUNDS valuation at $20,000 
> (i.e. total assets = $2) without a corresponding increase in 
> right-hand-side (ie total equity+liability=$1).
> 
> I'd think the 'correct' balance sheet with trading-accounts enabled, *should* 
> still report Unrealized Gains, no?
> 
> 
> On 13/08/18 22:51, John Ralls wrote:
>> 
>> 
>>> On Aug 12, 2018, at 10:04 PM, Christopher Lam >> > wrote:
>>> 
>>> Hi Jralls
>>> 
>>> So just wish to double check my understanding of gnucash's data format for 
>>> a balance-sheet on date X
>>> 
>>> There are two possibilities for displaying the right-hand-side
>>> 
>>> Liabilities + Equity + Retained Earnings + Trading Balances
>>> Liabilities + Equity + Retained Earnings + Unrealized Gains
>>> "Retained Earnings" should be NULL if the user has properly closed the 
>>> books on the balance sheet date X.
>>> 
>>> In my understanding, "Trading Balances" and "Unrealized Gains" are one and 
>>> the same -- in balance-sheet.scm the unrealized-gain-collector is only 
>>> populated if book->trading-accounts setting is disabled. (btw this causes a 
>>> 'bug' whereby a book with 'enable-trading-accounts', but was later switched 
>>> to 'disable-trading-accounts' will then add both the 
>>> unrealized-gain-collector and the trading-balance the right-hand-side).
>>> 
>>> This seems to be deconstruct current balance-sheet?
>>> 
>>> (I can't seem to find any unrealized-gain issue... from using different 
>>> price-sources... perhaps this is beyond my understanding.)
>>> 
>>> 
>>> On 11/08/18 22:41, John Ralls wrote:
 Chris,
 
 Remember that we’ve long advised users that they need not close their 
 books, they can run a balance sheet report for any day. IMO removing that 
 capability would be a major breakage.
 
 I suspect that you needed to use trading accounts because you didn’t book 
 the trading gains and losses as income. Users should do that regardless of 
 using trading accounts and doing so should make it unnecessary for the 
 balance sheet report to include trading accounts.
 
 Unrealized gains are another matter entirely and are a result of using 
 prices from the price database instead of actual cost from the transaction 
 data. IMO the balance sheet report shouldn’t be taking prices from the 
 price db and shouldn’t be able to see unrealized gains, but if price 
 source is going to be an option then an unrealized gains line flows from 
 that so that users don’t waste a bunch of time chasing an imbalance caused 
 by price differences.
 
 https://bugs.gnucash.org/show_bug.cgi?id=775368 
  is related because 
 that’s currently how the balance sheet report gets the “actual” costs.
 
 Regards,
 John Ralls
 
> On Aug 10, 2018, at 11:40 PM, Christopher Lam  > wrote:
> 
> Hi John
> 
> I've managed to make the left-side (activa?) match the right-side 
> (passiva?)
> 
> https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null 
> 
> 
> 1) it does require closing books on the balance-sheet date
> 
> 2) it does require adding trading-accounts
> 
> The existing balsheet introduces/calculates the "Retained Earnings", 
> "Trading Gains" and   "Unrealized Gains", whereas 
> the current iteration of new-balsheet will not.
> 
> To me this is the easiest method to ensure both sides produce the same 
> total, and is now technically correct - if the user has not closed their 
> books, the balance sheet won't   balance.
> 
> This is giving me a headache :(
> 
> Should a new balsheet calculate and report these '(fake) retained 
> earnings', and 'unrealized gains' ???
> 
> C
> 
> 
> On 09/08/18 08:32, John Ralls wrote:
>> 
>>> On Aug 8, 2018, at 8:51 AM, Geert Janssens  
>>>  wrote:

Re: [GNC-dev] gnucash-htdocs master: Fix a couple of links as reported by Stan Brown

[Geert Janssens]

Op vrijdag 10 augustus 2018 18:47:06 CEST schreef Geert Janssens:
> Op vrijdag 10 augustus 2018 17:09:58 CEST schreef John Ralls:
> > Sed will make short work of the global change on the website but we can’t
> > use it on Github releases; those would all have to be changed by hand.
> > Fortunately there are only 25-30 of them. I doubt that there are any
> > not-GnuCash bugs in the release announcements, at least from the 2.2 on.
> > In
> > order to appear in a release announcement a bug would have to have been
> > the
> > subject line of a commit note, and that’s unlikely to happen unless it’s a
> > GnuCash bug.

There was one mentioned in the known issues of the gnucash 3.1 release :)

> > 
> > All of which said, there’s a certain air of rewriting history to changing
> > all of the bug links to bugs.gnucash.org . I see
> > no problem with changing the 3.2 announcement; in fact, I like that
> > because
> > it will keep me from screwing up the 3.3 announcement by copying the gnome
> > URL and forgetting to fix it. I can sort-of see changing 3.0 and 3.1 as
> > well. The further back in time the announcement the less sense it makes to
> > me to change. At some point it makes more sense to just remove the
> > announcements. The historical record of what happened when is preserved in
> > git history and in the ChangeLog files. I don’t see much benefit to
> > maintaining it all on the website as well.
> 
> That's a reasonable approach IMO.
> 
> Geert

... and that's what I have done: I have updated all bug references to 
bugs.gnucash.org on the release announcements for gnucash 3.0-3.2.

I have spotted one gtk bug in there which I have left unchanged (that is I 
didn't bother looking for the gitlab equivalent of this one but instead I kept 
bugzilla.gnome.org as domain).

I have done this both on our website and on github.

Geert


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

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Christopher Lam]

Hi John

Just to be a pain again... I found a small discrepancy - (This is 
different from the previously noted missing-capital-gains situation)


 * if trading-accounts are enabled,
 * a single 100AAPL purchase @ $100 each dated 01/01/18
 * a new increased price $200 on 01/06/18 is recorded,
 * price-source is 'latest' to pick up the new price

There's no trade sale yet -- this means 'trading gains' is $0 -- indeed 
the book will not have any Trading accounts yet.


I'd expect the balance-sheet to record the increased price as 
'unrealized gain'.


Yet the balance-sheet just displays an increased FUNDS valuation at 
$20,000 (i.e. total assets = $2) without a corresponding increase in 
right-hand-side (ie total equity+liability=$1).


I'd think the 'correct' balance sheet with trading-accounts enabled, 
*should* still report Unrealized Gains, no?



On 13/08/18 22:51, John Ralls wrote:



On Aug 12, 2018, at 10:04 PM, Christopher Lam 
mailto:christopher@gmail.com>> wrote:


Hi Jralls

So just wish to double check my understanding of gnucash's data 
format for a balance-sheet on date X


There are two possibilities for displaying the right-hand-side

 1. Liabilities + Equity + Retained Earnings + Trading Balances
 2. Liabilities + Equity + Retained Earnings + Unrealized Gains

"Retained Earnings" should be NULL if the user has properly closed 
the books on the balance sheet date X.


In my understanding, "Trading Balances" and "Unrealized Gains" are 
one and the same -- in balance-sheet.scm the 
unrealized-gain-collector is only populated if book->trading-accounts 
setting is disabled. (btw this causes a 'bug' whereby a book with 
'enable-trading-accounts', but was later switched to 
'disable-trading-accounts' will then add both the 
unrealized-gain-collector and the trading-balance the right-hand-side).


This seems to be deconstruct current balance-sheet?

(I can't seem to find any unrealized-gain issue... from using 
different price-sources... perhaps this is beyond my understanding.)



On 11/08/18 22:41, John Ralls wrote:

Chris,

Remember that we’ve long advised users that they need not close 
their books, they can run a balance sheet report for any day. IMO 
removing that capability would be a major breakage.


I suspect that you needed to use trading accounts because you didn’t 
book the trading gains and losses as income. Users should do that 
regardless of using trading accounts and doing so should make it 
unnecessary for the balance sheet report to include trading accounts.


Unrealized gains are another matter entirely and are a result of 
using prices from the price database instead of actual cost from the 
transaction data. IMO the balance sheet report shouldn’t be taking 
prices from the price db and shouldn’t be able to see unrealized 
gains, but if price source is going to be an option then an 
unrealized gains line flows from that so that users don’t waste a 
bunch of time chasing an imbalance caused by price differences.


https://bugs.gnucash.org/show_bug.cgi?id=775368 is related because 
that’s currently how the balance sheet report gets the “actual” costs.


Regards,
John Ralls

On Aug 10, 2018, at 11:40 PM, Christopher Lam 
mailto:christopher@gmail.com>> wrote:


Hi John

I've managed to make the left-side (activa?) match the right-side 
(passiva?)


https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null

1) it does require closing books on the balance-sheet date

2) it does require adding trading-accounts

The existing balsheet introduces/calculates the "Retained 
Earnings", "Trading Gains" and "Unrealized Gains", whereas the 
current iteration of new-balsheet will not.


To me this is the easiest method to ensure both sides produce the 
same total, and is now technically correct - if the user has not 
closed their books, the balance sheet won't balance.


This is giving me a headache :(

Should a new balsheet calculate and report these '(fake) retained 
earnings', and 'unrealized gains' ???


C


On 09/08/18 08:32, John Ralls wrote:


On Aug 8, 2018, at 8:51 AM, Geert Janssens 
 wrote:


I haven't been following every detail of this. However I note on 
most balance
sheets the total assets doesn't match total net worth (or 
liabilities/equity).

In most, this is fixed by including the retained earnings.

I believe at least in most European countries the "left hand 
side" (Assets,
Active) and "right hand side" (Passive or liabilities + equity) 
of the
multicolumn view should balance (it's called balance sheet for a 
reason).
That would suggest retained earnings does have to be part of the 
balance

sheet.

However I'm not an accountant and perhaps your book is slightly 
contrived so I

don't know the exact answer here.

As for the "multi-column" vs one column debate, both present the 
same data.

The only difference is visual representation or style.

As of recently I have become a strong proponent of separating 
structure (or
accounting functionality in a different 

Re: [GNC-dev] Bug 796725

[Geert Janssens]

Op woensdag 15 augustus 2018 15:43:37 CEST schreef John Ralls:
> I was actually thinking of date ranges on report options, but yeah, having
> both “before” and “on or before” seems redundant.
> 
Technically this is true although that's like stating in sql queries '<' is 
redundant because you can simulate it with '<=' by adjusting the parameters. 
Yet sql offers both and so should we.

The reasoning is that which construct is preferable depends on the context. 
It's sometimes easier to build up the search logic "before" and sometimes it's 
easier with "on or before".

Regards,

Geert


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

Re: [GNC-dev] Location of XML Schema

[Geert Janssens]

Op woensdag 15 augustus 2018 17:16:04 CEST schreef Derek Atkins:
> David,
> 
> "David T."  writes:
> > Ah! Thank you! I have updated the links.
> > 
> > On a more substantial note: I see that this page makes significant
> > reference to changes in XML implementation from version 1.9
> > forward. An examination of the page history shows that most of the
> > content was developed in 2006.
> > 
> > At this point, I believe that this information is essentially
> > unimportant, since we are now at version 3.2 [2.8 in the old
> > numeration]. My inclination would be to drastically reduce (or
> > eliminate altogether) this discussion as no longer relevant to the
> > user base. However, I recognize that there may be a desire to retain
> > this information for historical purposes, and I put the question to
> > the developer base: what would you prefer happens with the information
> > on this page?
> 
> I think it's safe to remove it; the old text will remain in the page
> history.

Same here. I prefer the wiki to match the current situation as closely as 
possible so I would delete outdated information for anything older than the 
previous major release series or if really requested two previous release 
series (so anything before either 2.6.x or 2.4.x could go or should be 
updated).

Geert


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