Re: [GNC-dev] Location of XML Schema

[David T. via gnucash-devel]

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?

Cheers,
David

> On Aug 14, 2018, at 12:34 PM, Derek Atkins  wrote:
> 
> It moved to libgnucash/doc/...
> 
> -derek
> Sent using my mobile device. Please excuse any typos.
> On August 14, 2018 3:31:45 PM "David T."  wrote:
> 
>> Hello,
>> 
>> In preparation for writing up data storage information to address Bug 
>> 777893, I consulted the Wiki at wiki.gnucash.org/wiki/GnuCash_XML_format 
>> , and found a reference to 
>> "a non-normative RELAX NG schema for the XML file format (gnucash-v2.rnc).” 
>> Unfortunately, the link 
>> (https://github.com/Gnucash/gnucash/blob/master/src/doc/xml/gnucash-v2.rnc 
>> ) 
>> is dead, and I cannot locate it with any of my search juju.
>> 
>> Has this file gone away, and if so, could someone with better understanding 
>> of the subject correct the wiki to reflect the current state of the art?
>> 
>> Thanks!
>> 
>> David
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> 
> 

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

Re: [GNC-dev] Location of XML Schema

[Derek Atkins]

It moved to libgnucash/doc/...

-derek
Sent using my mobile device. Please excuse any typos.
On August 14, 2018 3:31:45 PM "David T."  wrote:


Hello,

In preparation for writing up data storage information to address Bug 
777893, I consulted the Wiki at wiki.gnucash.org/wiki/GnuCash_XML_format 
, and found a reference to 
"a non-normative RELAX NG schema for the XML file format (gnucash-v2.rnc).” 
Unfortunately, the link 
(https://github.com/Gnucash/gnucash/blob/master/src/doc/xml/gnucash-v2.rnc 
) 
is dead, and I cannot locate it with any of my search juju.


Has this file gone away, and if so, could someone with better understanding 
of the subject correct the wiki to reflect the current state of the art?


Thanks!

David
___
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] Location of XML Schema

[David T.]

Hello,

In preparation for writing up data storage information to address Bug 777893, I 
consulted the Wiki at wiki.gnucash.org/wiki/GnuCash_XML_format 
, and found a reference to "a 
non-normative RELAX NG schema for the XML file format (gnucash-v2.rnc).” 
Unfortunately, the link 
(https://github.com/Gnucash/gnucash/blob/master/src/doc/xml/gnucash-v2.rnc 
) is 
dead, and I cannot locate it with any of my search juju. 

Has this file gone away, and if so, could someone with better understanding of 
the subject correct the wiki to reflect the current state of the art?

Thanks!

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

Re: [GNC-dev] Bug 796725

[John Ralls]

> On Aug 14, 2018, at 6:55 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> I have been looking at this one and know what is wrong but not sure if my
> fix is valid.
> 
> It is to do with searching for transactions by posted date and returning
> the wrong number of transactions for the required filter option.
> 
> When the date entered in the GtkEntry, gnc_date_edit_get_date returns the
> time64 but at 12:00:00 am for that day.
> 
> Looking at the transaction posted date in my Xml file they are at
> '2018-01-01 10:59:00 +'
> 
> I can fix this in search-date.c by changing the two occurrences of
> gnc_date_edit_get_date to some thing like this...
> 
>time64 temp = gnc_date_edit_get_date (GNC_DATE_EDIT (priv->entry));
>struct tm * temp_tm = gnc_localtime ();
> 
>fi->tt = gnc_dmy2time64_neutral (temp_tm->tm_mday, temp_tm->tm_mon
> + 1, temp_tm->tm_year + 1900);
>gnc_tm_free (temp_tm);
> 
> but this would affect all date searches in transactions, invoices and bills.
> 
> Should all dates be at this neutral time so it does not matter ?

Bob,

I think all search dates should be “open” intervals, meaning that if you search 
from 1 - 31 January, the result set should include transactions on both 1 
January and 31 January as well as everything in between. The best way to 
accomplish this is to use gnc_dmy2time64() for the beginning of the search and 
gnc_dmy2time64_end() for the end of the search: The former returns 00:00:00 on 
the day and the latter to 23:59:59.

Transaction *posted* dates created with 2.6.12 or so and later are set to 
10:59:00 UTC using gnc_dmy2time64_neutral() unless the user is in one of the 
“edge” timezones, -12, +13, or +14, in which cases the time is offset to keep 
the time in the same local day. Other dates, e.g. date_entered and 
date_reconciled, are set to the actual time that the action occurred, usually 
using gnc_time().

Regards,
John Ralls

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

[GNC-dev] Bug 796725

[Robert Fewell]

I have been looking at this one and know what is wrong but not sure if my
fix is valid.

It is to do with searching for transactions by posted date and returning
the wrong number of transactions for the required filter option.

When the date entered in the GtkEntry, gnc_date_edit_get_date returns the
time64 but at 12:00:00 am for that day.

Looking at the transaction posted date in my Xml file they are at
'2018-01-01 10:59:00 +'

I can fix this in search-date.c by changing the two occurrences of
gnc_date_edit_get_date to some thing like this...

time64 temp = gnc_date_edit_get_date (GNC_DATE_EDIT (priv->entry));
struct tm * temp_tm = gnc_localtime ();

fi->tt = gnc_dmy2time64_neutral (temp_tm->tm_mday, temp_tm->tm_mon
+ 1, temp_tm->tm_year + 1900);
gnc_tm_free (temp_tm);

but this would affect all date searches in transactions, invoices and bills.

Should all dates be at this neutral time so it does not matter ?

Regards,

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

Thank you - plenty of material here for test cases.

I note your observation that selling a stock at an increased price, in a
book without trading-accounts, without properly booking the capital-gain to
income leads to an incorrect balance-sheet. This is illus by txn-A and
txn-B below. This shouldn't arise -- all cap-gains must be documented
according to documentation - either together with the sell transaction, or
in a separate transaction. So, IMHO the incorrect report as you found out
does not really need fixing.

01-jan-18 Txn-A - buy
Asset:Broker -$1
Asset:Broker:Stock +100 AAPL (+$1)

01-jun-18 Txn-B - sell
Asset:Broker +$2
Asset:Broker:Stock -100 AAPL (-$2)

01-jun-18 Txn-C - cap-gain
Asset:Broker:Stock 0AAPL (+$1)
Income:Capital-Gains -$1

Moreover, about that price-source... I'll try and replicate.

C
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

   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 
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 context) from style, I think this
should be delegated to the realm of css. This particular layout variation
can
IMO be handled by making