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

[Adrien Monteleone]

Are not Retained Earnings part of Equity? And then, that account would only be 
used in a close books process, not without it. Closing the books should zero 
the income and expense accounts TO Retained Earnings.

Regards,
Adrien

> On Aug 13, 2018, at 12:04 AM, 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 divs for each large group and either let them 
> follow
> normal flow or use float to move them next to each other. If you will you 
> can
> have a 

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

[Christopher Lam]

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 context) from style, I 
think this
should be delegated to the realm of css. This particular layout 
variation can
IMO be handled by making divs for each large group and either let 
them follow
normal flow or use float to move them next to each other. If you 
will you can
have a European style sheet and an American one, or an Australian 
or whatever.


As for "categories", I read Frank's earlier reply as if he agreed 
that at
least for now the account organization is something to be done in 
the CoA, not

in report code.
The Balance Sheet is indeed supposed to balance, but in normal 
practice it balances only when the book is “closed”, i.e. when all 
of the income and expense accounts are summed up and added to 
Equity. In US corporate books the cumulative total of income and 
expenses lives in an Equity account called “Retained Earnings”.


In the pen-and-paper days a  “Trial Balance” was computed outside of 
the books before closing as a way to catch errors before making the 
closing 

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[David Cousens]

Rob,
I think it was I who was missing something. I would have expected the
Ctrl-click behaviour to be built in to the GTkTreeView and the dGTK
developers obviously thought it was so obvious they didn't have to mention
it. The pointers John gave me should help me sort it out.

Thanks

David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[David Cousens]

Thanks John,That cleared a few issues up for me. I'll have a look at
the gnc- tree- view-account  code to get some pointers. I have
programmed before in C ,only a very little in C++, but I am fairly
rusty . I was surprised to get a few things wokring without any
problems so far. I am not sure bravery is the right word - possibly
more like senile dementia. The barrier up to now has always been
finding my way round the code base but I found a program called
SourceTrail which is great for locating all the places a particular
variable structure or function is used. making tracking down
dependencies in the code a lot easier.
CheersDavid
> 
> David,
> Your bravery is admirable, but it takes a lot of study to
> successfully customize Gtk internals and GtkTreeView is one of Gtk’s
> most complex features. Fortunately GtkTreeView already has ctrl-click 
> multiple selection and GnuCash has GtkTreeViews using it, for example
> the account selection in report options. The code for that is in http
> s://github.com/Gnucash/gnucash/blob/maint/gnucash/gnome-utils/gnc-
> tree-view-account.c.
> Regards,John Ralls
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[John Ralls]

> On Aug 12, 2018, at 12:22 AM, David Cousens  wrote:
> 
> Hi,
> 
> I raised the above bug as a feature request then I decided to try and tackle
> it myself. My concept was to have a popup menu activated by a right click in
> the matcher window area from which the user could enable and disable
> multiple selection of transactions in the window and elect to assign a
> transfer account to a selection of multiple rows. My reason for doing this
> is I often have within an imported set of transactions, sets of multiple
> transactions which have the same transfer account and processing an import
> would be speeded up if these could be selected as a group and the the
> transfer account selected and applied to the group. 
> 
> I now have a lot of the basic code in place to process a selection and to
> create and view a popup menu, activate and disable multiple selection and
> process a group of selected rows, partially tested but I have struck a
> problem in that the GtkTreeView does not implement Ctrl-click selection in
> the API and i am going to have to provide that myself.
> 
> As far as I can see from the code in import-main-matcher.c GnuCash does not
> seem to implement anything other than a mouse double click to select a
> single row which is processed by the callback initiated by the TreeView
> "row-activated" event. I.e. there is no selection by pressing "Enter" while
> the focus is on a given row. 
> 
> My plan is to detect Ctrl-Left click (implemented) and use that to add rows
> to the selection and then initiate the processing of the selection using the
> right click (implemented) popup menu. To do this, I have to detect a
> GDK_BUTTON_PRESS event and then use the event->state to determine whether
> Ctrl is pressed simultaneously (implemented) or whether the third mouse
> button has been clicked (implemented) . This however appears to short
> circuit the "row-activated" event detection by the GtkTreeView as it detects
> the sequence:
> GDK_BUTTON_PRESS
> GDK_BUTTON_RELEASE
> GDK_BUTTON_PRESS
> GDK_BUTTON_RELEASE if it occurs within 0.25 s
> so I am going to have to provide my own double click detection within the
> callback I use to process the initial button press.
> 
> My question is is this. Is what I have outlined above likely to interfere
> with any non mouse based selection of transactions for applying a transfer
> account and does the approach seem reasonable? I can't see that occurring in
> the code for the main matcher, but I am a relative novice in using Gdk and
> Gtk so I could be easily missing something. E.g. Up, Down keys to shift the
> row focus and Enter to select for example. 
> 

David,

Your bravery is admirable, but it takes a lot of study to successfully 
customize Gtk internals and GtkTreeView is one of Gtk’s most complex features. 
Fortunately GtkTreeView already has ctrl-click multiple selection and GnuCash 
has GtkTreeViews using it, for example the account selection in report options. 
The code for that is in 
https://github.com/Gnucash/gnucash/blob/maint/gnucash/gnome-utils/gnc-tree-view-account.c
 
.

Regards,
John Ralls


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

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[John Ralls]

> On Aug 12, 2018, at 3:47 AM, David Cousens  wrote:
> 
>  I am assuming here that the python GTK
> implementation is an exact parallel of the C++ implementation. I would
> expect it to be pretty similar and possibly just the C++ code in Python
> wrappers.

David,

Gtk+ is written in C, not C++, and includes comment-based introspection. A 
separate project, gobject-introspection, generates an introspection library 
from the comments, and a third project, pygobject, converts the introspection 
library into python. The resulting python API exactly reflects the C one.

There is a separate project, gtkmm, that wraps Gtk+ in C++. It does not use 
gobject-introspection.

When using python documentation be sure that it’s not for PyGtk, an older 
non-gobject-introspection wrapper for Gtk+-2.0. That API didn’t exactly reflect 
the underlying one, and besides Gtk2 differs somewhat from Gtk3.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[Robert Fewell]

David,
I may be missing some thing but you should be able to select lines by
control, shift or by individual.
I think what you are after can be shown in the reconcile view, multiple
lines can be selected and then right moused to a menu.

Anyway, enjoy your holiday...

Bob

On 12 August 2018 at 11:47, David Cousens  wrote:

> Bob,
>
> From what I've read in the GtkTreeView documentation, the rubber-banding
> mode only seems to support selection by dragging the mouse so one is only
> able to select consecutive rows, not a group of single non-contiguous rows.
> I could of course be wrong on that.  It obviously sets the
> GTK_SELECTION_MULTIPLE mode of a GtkTreeSelection along with the drag
> detection. I find the Gtk documentation extremely terse and unhelpful in
> some areas. I did find a reference to the row-activated signal being
> emitted
> when"when a non-editable row is selected and one of the keys: Space,
> Shift+Space, Return or Enter is pressed." which would permit non-mouse row
> activation to initiate the selection of a transfer account
>
> I also found a Python gtk discussion to the effect that GtkTreeView's
> slection capabilities were limited pretty well to the drag over to select
> and from that found a hint on how to do Ctrl click event detection using
> the
> GdkEventButton using the event-> state and also how to detect the right
> click event.  When I included that in the import-main-matcher.c the
> row-activated signal stopped working. I am assuming here that the python
> GTK
> implementation is an exact parallel of the C++ implementation. I would
> expect it to be pretty similar and possibly just the C++ code in Python
> wrappers.
>
> I may have to setup a dummy program implementing  a TreeView and just play
> with how things work with rubber banding and multiple selection until I
> understand it better and the interaction between the rubber-banding and
> multiple selection mode. Usually the best way of understanding incomplete
> or
> unclear documentation.
>
> I'm away for a few days on holidays so I'll try and tackle it then if my
> wife lets me get an opportunity. Otherwise it will be when I return.
>
> Cheers
>
> David
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> 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] Bug 796778 Feature Request Multiple Selection in Import- matcher

[David Cousens]

Bob,

>From what I've read in the GtkTreeView documentation, the rubber-banding
mode only seems to support selection by dragging the mouse so one is only
able to select consecutive rows, not a group of single non-contiguous rows.
I could of course be wrong on that.  It obviously sets the
GTK_SELECTION_MULTIPLE mode of a GtkTreeSelection along with the drag
detection. I find the Gtk documentation extremely terse and unhelpful in
some areas. I did find a reference to the row-activated signal being emitted
when"when a non-editable row is selected and one of the keys: Space,
Shift+Space, Return or Enter is pressed." which would permit non-mouse row
activation to initiate the selection of a transfer account

I also found a Python gtk discussion to the effect that GtkTreeView's
slection capabilities were limited pretty well to the drag over to select
and from that found a hint on how to do Ctrl click event detection using the
GdkEventButton using the event-> state and also how to detect the right
click event.  When I included that in the import-main-matcher.c the
row-activated signal stopped working. I am assuming here that the python GTK
implementation is an exact parallel of the C++ implementation. I would
expect it to be pretty similar and possibly just the C++ code in Python
wrappers.

I may have to setup a dummy program implementing  a TreeView and just play
with how things work with rubber banding and multiple selection until I
understand it better and the interaction between the rubber-banding and
multiple selection mode. Usually the best way of understanding incomplete or
unclear documentation.

I'm away for a few days on holidays so I'll try and tackle it then if my
wife lets me get an opportunity. Otherwise it will be when I return.

Cheers

David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[Robert Fewell]

David,
Why do you not as a start change the tree view selection from single to
multiple, you will see that in the dialog-import.glade file, that way you
can select multiple lines.
You will need to alter the selection call back as you need different
functions that use a list of selected rows.

Bob

On 12 August 2018 at 08:22, David Cousens  wrote:

> Hi,
>
> I raised the above bug as a feature request then I decided to try and
> tackle
> it myself. My concept was to have a popup menu activated by a right click
> in
> the matcher window area from which the user could enable and disable
> multiple selection of transactions in the window and elect to assign a
> transfer account to a selection of multiple rows. My reason for doing this
> is I often have within an imported set of transactions, sets of multiple
> transactions which have the same transfer account and processing an import
> would be speeded up if these could be selected as a group and the the
> transfer account selected and applied to the group.
>
> I now have a lot of the basic code in place to process a selection and to
> create and view a popup menu, activate and disable multiple selection and
> process a group of selected rows, partially tested but I have struck a
> problem in that the GtkTreeView does not implement Ctrl-click selection in
> the API and i am going to have to provide that myself.
>
> As far as I can see from the code in import-main-matcher.c GnuCash does not
> seem to implement anything other than a mouse double click to select a
> single row which is processed by the callback initiated by the TreeView
> "row-activated" event. I.e. there is no selection by pressing "Enter" while
> the focus is on a given row.
>
> My plan is to detect Ctrl-Left click (implemented) and use that to add rows
> to the selection and then initiate the processing of the selection using
> the
> right click (implemented) popup menu. To do this, I have to detect a
> GDK_BUTTON_PRESS event and then use the event->state to determine whether
> Ctrl is pressed simultaneously (implemented) or whether the third mouse
> button has been clicked (implemented) . This however appears to short
> circuit the "row-activated" event detection by the GtkTreeView as it
> detects
> the sequence:
> GDK_BUTTON_PRESS
> GDK_BUTTON_RELEASE
> GDK_BUTTON_PRESS
> GDK_BUTTON_RELEASE if it occurs within 0.25 s
> so I am going to have to provide my own double click detection within the
> callback I use to process the initial button press.
>
> My question is is this. Is what I have outlined above likely to interfere
> with any non mouse based selection of transactions for applying a transfer
> account and does the approach seem reasonable? I can't see that occurring
> in
> the code for the main matcher, but I am a relative novice in using Gdk and
> Gtk so I could be easily missing something. E.g. Up, Down keys to shift the
> row focus and Enter to select for example.
>
> David Cousens.
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> 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] Bug 796778 Feature Request Multiple Selection in Import- matcher

[David Cousens]

Hi,

I raised the above bug as a feature request then I decided to try and tackle
it myself. My concept was to have a popup menu activated by a right click in
the matcher window area from which the user could enable and disable
multiple selection of transactions in the window and elect to assign a
transfer account to a selection of multiple rows. My reason for doing this
is I often have within an imported set of transactions, sets of multiple
transactions which have the same transfer account and processing an import
would be speeded up if these could be selected as a group and the the
transfer account selected and applied to the group. 

I now have a lot of the basic code in place to process a selection and to
create and view a popup menu, activate and disable multiple selection and
process a group of selected rows, partially tested but I have struck a
problem in that the GtkTreeView does not implement Ctrl-click selection in
the API and i am going to have to provide that myself.

As far as I can see from the code in import-main-matcher.c GnuCash does not
seem to implement anything other than a mouse double click to select a
single row which is processed by the callback initiated by the TreeView
"row-activated" event. I.e. there is no selection by pressing "Enter" while
the focus is on a given row. 

My plan is to detect Ctrl-Left click (implemented) and use that to add rows
to the selection and then initiate the processing of the selection using the
right click (implemented) popup menu. To do this, I have to detect a
GDK_BUTTON_PRESS event and then use the event->state to determine whether
Ctrl is pressed simultaneously (implemented) or whether the third mouse
button has been clicked (implemented) . This however appears to short
circuit the "row-activated" event detection by the GtkTreeView as it detects
the sequence:
GDK_BUTTON_PRESS
GDK_BUTTON_RELEASE
GDK_BUTTON_PRESS
GDK_BUTTON_RELEASE if it occurs within 0.25 s
so I am going to have to provide my own double click detection within the
callback I use to process the initial button press.

My question is is this. Is what I have outlined above likely to interfere
with any non mouse based selection of transactions for applying a transfer
account and does the approach seem reasonable? I can't see that occurring in
the code for the main matcher, but I am a relative novice in using Gdk and
Gtk so I could be easily missing something. E.g. Up, Down keys to shift the
row focus and Enter to select for example. 

David Cousens.



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel