Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp
Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam: > Hi Stephen, Dave &al > > Thank you - > > Dave - the changes are merely cosmetic therefore easy. > > It sounds there are still 2 desired presentational types - (1) Dave's > approach = *recursive-bal* - 'parent' accounts generally collect their > children account amounts; if they also have their own amount, the latter is > rendered on the next line, indented as a child account. (2) Stephen's > approach = *multilevel-bal* - parent accounts' amounts are hidden unless > they exist. > I'm not sure I understand the difference here. Isn't this expressing the same thing twice in different ways ? Perhaps I'm missing a subtlety in the English language... Or is the difference whether the totals are shown above or below the children ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp
Broadly yes, one approach is that parent accounts always show totals for themselves+children, the other approach is the totals appear after each parent+children. Same information presented in 2 different ways. The difference is that the recursive subtotals are easier When reaching an account, it just queries if it has children, and if yes check if they have own amount, and if yes insert next line for own account. Multilevel subtotals require collectors to keeping track of amounts while cycling the account list. On Tue, 3 Jul 2018, 15:41 Geert Janssens wrote: > Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam: > > Hi Stephen, Dave &al > > > > Thank you - > > > > Dave - the changes are merely cosmetic therefore easy. > > > > It sounds there are still 2 desired presentational types - (1) Dave's > > approach = *recursive-bal* - 'parent' accounts generally collect their > > children account amounts; if they also have their own amount, the latter > is > > rendered on the next line, indented as a child account. (2) Stephen's > > approach = *multilevel-bal* - parent accounts' amounts are hidden unless > > they exist. > > > I'm not sure I understand the difference here. Isn't this expressing the > same > thing twice in different ways ? Perhaps I'm missing a subtlety in the > English > language... > > Or is the difference whether the totals are shown above or below the > children > ? > > Geert > > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Removing gncmod-python.c in commit 4ecd9c2dd41ae75ec4e82a662a241543fc075c01
Hi, Would a patch to restore gncmod-python.c be accepted for inclusion. I have been using this to load a python subsystem into gnucash for a number of years. I know it cant be restored as was but I have a small patch to it which removes the calls to the init of the _sw_core_utils and _sw_app_utils modules in the code (which dont appear to be used directly in gncmod-python.c). This means gncmod-python.dylib simply links to gnc-core-utils and no need for gnc-core-utils-python gncmod-app-utils-python. With this patch - and some python 3 fixups to init.py the init.py has no errors on loading. Note that gncmod-python.c was only place the init.py script was used. Thanks David Osguthorpe ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Removing gncmod-python.c in commit 4ecd9c2dd41ae75ec4e82a662a241543fc075c01
> On Jul 3, 2018, at 9:11 AM, David Osguthorpe > wrote: > > Hi, > > Would a patch to restore gncmod-python.c be accepted for inclusion. > > I have been using this to load a python subsystem into gnucash for a > number of years. > > I know it cant be restored as was but I have a small patch to it which > removes the calls to the init of the _sw_core_utils and _sw_app_utils > modules in the code (which dont appear to be used directly in > gncmod-python.c). This means gncmod-python.dylib simply links to > gnc-core-utils and no need for gnc-core-utils-python > gncmod-app-utils-python. > > With this patch - and some python 3 fixups to init.py the init.py has > no errors on loading. > > Note that gncmod-python.c was only place the init.py script was used. David, So there actually is someone using that! Sure, go ahead. The _sw_core_utils and _sw_app_utils calls would have been to make those modules' API available for import into the python console, but it might be cleaner if the python console could import the python bindings instead. Please also remove the files in pycons that aren't needed and don't work with Gtk3 (pycons in particular is using pygtk and pypango instead of pygobject). Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book-currency
On Mon, Jul 2, 2018 at 7:35 PM Christopher Lam wrote: > Hi Alex > Thank you for update - would you mind letting us know the layman version > of it? > Thanks! > > On 3 July 2018 at 01:02, Alex Aycinena wrote: > >> >>> -- Forwarded message -- >>> From: John Ralls >>> To: Christopher Lam >>> Cc: gnucash-devel >>> Bcc: >>> Date: Sun, 1 Jul 2018 20:13:37 -0700 >>> Subject: Re: [GNC-dev] book-currency >>> If you’re sure it’s dead code, by all means. >>> >>> The volume of cruft often overwhelms the working code, and always wastes >>> maintenance time. >>> >>> Regards, >>> John Ralls >>> >>> > On Jul 1, 2018, at 5:47 PM, Christopher Lam >>> wrote: >>> > >>> > There's lots of dead code related to an (AFAIK) unimplemented >>> book-currency >>> > or currency-accounting feature... Some are cluttering options.scm - >>> should >>> > we remove them? >>> > ___ >>> > gnucash-devel mailing list >>> > gnucash-devel@gnucash.org >>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> >> >> >> I put it there for a project I am working on (but have gotten delayed >> on). It is not dead code; however, allow me to remove it in the next week >> or so and I will re-apply it later when the project moves forward. >> >> Alex >> > > Christopher. I have copied and pasted below an email I sent several years ago that explains the project. I made several commits on it then pulled them out into a separate feature branch. The book option part you see is the first part that was not pulled out. I am still planning to proceed with this but other time commitments have limited my time on it. Regards, Alex Prior email: Developers, I am planning to add a feature to gnucash, primarily, but not exclusively, related to currency accounting, and wanted to summarize what I was thinking of. I would welcome feedback. Since version 2.4.0, GnuCash supports trading accounts as described in 'Tutorial on multiple currency accounting' and 'Multiple currency accounting in GnuCash' by P. Selinger (see http://wiki.gnucash.org/wiki/Trading_Accounts). I believe Mike Alexander added this feature. In his tutorial, he (P. Selinger) mentions a 'reference currency method' as an alternative to the use of trading accounts. This is essentially the feature I wish to add. Today, in file->properties->Accounts tab, you can turn "trading accounts" on or off. I propose to change this to a selection of three alternatives: use trading accounts, specify a 'book currency', or neither trading accounts nor book currency. If trading accounts is selected, it would work as implemented by Mike. If neither is selected, it would work as gnucash does now without trading accounts selected. So no one would be forced to use the new feature. If 'book currency' is selected, it would require the specification of the book currency in file->properties. Transaction entry would be modified to ensure every split that was not in the book currency had a 'price' or 'exchange rate' associated with it (to the book currency). In addition, the existing lot tracking capabilities would be used to track the 'cost' (in book currency) of all accounts not denominated in the book currency (lots would automatically be created rather than having the user go through the Actions->View Lots process). In entering any transaction that disposes of non-book-currency amounts, the user would be provided with assistance to calculate and book any gain or loss associated with the transaction based on these tracked costs. The idea is that several policies would be used for this purpose (probably implemented in phases): LIFO, FIFO, average cost (perhaps), manual specification. Much of this lot tracking has already been implemented but I don't believe it has been fully tested. A 'Cost and Unrealized Gains/Loss' report would be added to the menu if this feature is selected. It would show, for all non-book-currency accounts, as of a user-selected date: name, currency/commodity, cost, quantity, rate, value, unrealized gain/loss. Optionally, for each account, lot detail would be shown and, for each lot transaction detail would be shown. The US Income Tax Report would be enhanced to use the booked gains/losses (bug 554397). Among the changes I foresee are: - File->Properties: specify and select 'book currency', if selected, default gain/loss account and default lot tracking policy. - Account Edit: for 'non-book-currency' accounts, specify gain/loss account, lot tracking policy, short-sales allowed, currency account is priced in, skip lot-tracking flag. - Register Transaction Entry: transaction currency will be 'Book Currency' rather than currency of register transaction is entered from, raise 'Edit Exchange Rates' dialog if split not in book currency, create/update lots for non-book-currency splits, if a sale (subject to 'short sales' rule), uses Lot Tracking Policy to calculate cost amount and tentative gain/loss - Stock Split: make compliant - Lot
Re: [GNC-dev] book-currency
> On Jul 3, 2018, at 5:12 PM, Alex Aycinena wrote: > > On Mon, Jul 2, 2018 at 7:35 PM Christopher Lam > wrote: > >> Hi Alex >> Thank you for update - would you mind letting us know the layman version >> of it? >> Thanks! >> >> On 3 July 2018 at 01:02, Alex Aycinena wrote: >> >>> -- Forwarded message -- From: John Ralls To: Christopher Lam Cc: gnucash-devel Bcc: Date: Sun, 1 Jul 2018 20:13:37 -0700 Subject: Re: [GNC-dev] book-currency If you’re sure it’s dead code, by all means. The volume of cruft often overwhelms the working code, and always wastes maintenance time. Regards, John Ralls > On Jul 1, 2018, at 5:47 PM, Christopher Lam wrote: > > There's lots of dead code related to an (AFAIK) unimplemented book-currency > or currency-accounting feature... Some are cluttering options.scm - should > we remove them? > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >>> >>> >>> >>> I put it there for a project I am working on (but have gotten delayed >>> on). It is not dead code; however, allow me to remove it in the next week >>> or so and I will re-apply it later when the project moves forward. >>> >>> Alex >>> >> >> > Christopher. > > I have copied and pasted below an email I sent several years ago that > explains the project. I made several commits on it then pulled them out > into a separate feature branch. The book option part you see is the first > part that was not pulled out. I am still planning to proceed with this but > other time commitments have limited my time on it. > > Regards, > > Alex > > Prior email: > > Developers, > > I am planning to add a feature to gnucash, primarily, but not exclusively, > related to currency accounting, and wanted to summarize what I was thinking > of. I would welcome feedback. > > Since version 2.4.0, GnuCash supports trading accounts as described in > 'Tutorial on multiple currency accounting' and 'Multiple currency accounting > in GnuCash' by P. Selinger (see > http://wiki.gnucash.org/wiki/Trading_Accounts). I believe Mike Alexander > added this feature. > > In his tutorial, he (P. Selinger) mentions a 'reference currency method' as > an alternative to the use of trading accounts. This is essentially the > feature I wish to add. > > Today, in file->properties->Accounts tab, you can turn "trading accounts" > on or off. I propose to change this to a selection of three alternatives: > use trading accounts, specify a 'book currency', or neither trading > accounts nor book currency. If trading accounts is selected, it would work > as implemented by Mike. If neither is selected, it would work as gnucash > does now without trading accounts selected. So no one would be forced to > use the new feature. > > If 'book currency' is selected, it would require the specification of the > book currency in file->properties. Transaction entry would be modified to > ensure every split that was not in the book currency had a 'price' or > 'exchange rate' associated with it (to the book currency). In addition, the > existing lot tracking capabilities would be used to track the 'cost' (in > book currency) of all accounts not denominated in the book currency (lots > would automatically be created rather than having the user go through the > Actions->View Lots process). In entering any transaction that disposes of > non-book-currency amounts, the user would be provided with assistance to > calculate and book any gain or loss associated with the transaction based > on these tracked costs. The idea is that several policies would be used for > this purpose (probably implemented in phases): LIFO, FIFO, average cost > (perhaps), manual specification. Much of this lot tracking has already been > implemented but I don't believe it has been fully tested. > > A 'Cost and Unrealized Gains/Loss' report would be added to the menu if > this feature is selected. It would show, for all non-book-currency accounts, > as of a user-selected date: name, currency/commodity, cost, quantity, rate, > value, unrealized gain/loss. Optionally, for each account, lot detail would > be shown and, for each lot transaction detail would be shown. > > The US Income Tax Report would be enhanced to use the booked gains/losses > (bug 554397). > > Among the changes I foresee are: > > - File->Properties: specify and select 'book currency', if selected, > default gain/loss account and default lot tracking policy. > - Account Edit: for 'non-book-currency' accounts, specify gain/loss > account, lot tracking policy, short-sales allowed, currency account is > priced in, skip lot-tracking flag. > - Register Transaction Entry: transaction currency will be 'Book Currency' > rather than currency of register transaction is entered from, raise 'Edit >
