Non compatibility of Gnucash 2.2 with report from Gnucash 2.0
andrew at swclan.homelinux.org
Sun Dec 23 23:23:37 EST 2007
My comments are lengthy, sorry, bear with me...
On Sun, Dec 23, 2007 at 09:27:03PM +0100, Thierry Scalais wrote:
> Chris Shoemaker a écrit :
>> On Wed, Aug 22, 2007 at 10:13:32PM +0200, Thierry Scalais wrote:
>>> Last year, I modified the advanced-portfolio report to add some useful
>>> functionality. I posted the report to this mailing list on September
>>> 2006. This reports worked fine with Gnucash 2.0.
Thanks for the link. I hadn't seen this before. In the future I
recommend you also post patches and enhancements to bugzilla as well
to improve visibility. Also, you would be better served to provide
diffs against the existing source code instead of the complete
file. This makes it easier for us to focus on what you're changing.
I have copied below your comments on your submitted report and added
my own comments.
>Concerning the new functions or differences:
> * The basis price column displays the base value per
> share. So,
> it is easier to compare the cost of own shares and the
I'm sorry, but this is meaningless in all cases except the "Average"
method of basis calculation. If you are using FIFO or FILO basis
calculations or using Lots (something I'm working on at the moment),
there is no "per-share" basis as in theory every share held could have
a different basis.
> * A option permit to display share prices in the report
> currency. Because the base value is displayed in the report
> currency, it is easier to compare the base value and the
> when the share price currency is not the report currency.
this is a good thing.
> * The moneyin column only totalises the amount of transaction
> that increases the number of shares (purchases)
> * The moneyout column only totalises the amount of transaction
> that decreases the number of shares (sales)
this is already implemented in recent versions of the report. I'm not
sure, without reviewing the commit logs, whether it was included in
the current stable release (2.2.2) but if not, it surely will be in
> * A profits column display the profit on sales
how is this different from the existing "Gains" column?
> * The income column is the summation of expenses and incomes.
> This column may be canceled with the option 'include gains
IMO, you should not combine income and expenses -- list them
separately instead. We cannot determine whether a particular expense
is valid to offset against income or not...
> * The display of the profits, incomes and unrealised gains
> columns may be canceled by an report option
> * A last column shows the 'annual growth rate' that is the
> annual growth rate that applied up to now on the shares
> transactions gives the total gain.
like and annual percentage rate? This is likely a good thing.
> * prevents the summation of expenses and incomes in a
> multi-splits transaction for each operation on the account
> commodity found in the transaction. . In this case, the
> computation was wrong because the number of shares in the
> transaction was added to the basis-list for each operation
> the account commodity within the same transaction.
> Multi-splits transaction with several split of operation on
> the account commodity are automatically generated by the
> "lots" functionnality.
this should be fixed already.
> * the exchange rate from the commodity price currency to the
> report currency is no more applied on the transactions
> amounts. (Bug#350658).
I have "forward-ported" your changes in that bug to the current
version and posted a patch file to that bug report. If you could test
that, I would appreciate it as I don't work in multiple currencies and
can't judge how well it works. Note please that there are *still*
problems with the currency handling in the rpeort, but I think your
change there is good and if it tests out okay, I'd be happy to commit
> * I applied the patch of Scott Oonk (bug#343245) to fix
> truncation error in the basis calculation.
that fix doesn't really work as done by Scott. It causes overflow
errors in particularly large accounts with many transactions. The
large number of calculations result in overly large numerators and
denominators in the gnc-numerics and they overflow. We need a more
reasonable solution -- something that makes reasonable rounding.
> * clean up on gains computation.
> * there are some other modifications and probably new bugs.
what other modifications? please provide a diff against either the
current report or at least against the version you are using so we can
see specifically what has changed.
>>> Unfortunately, Gnucash 2.2 is not compatible with this report.
>>> Is there, any where, a file that I could include in my report to retrieve
>>> the old definitions and so avoid a rewrite of my report?
>> No, there is not. We switched wrapper-generator tools
> I solved my problem with a file (named compat20) that defines the old
I'm sorry, but this is not the way to solve this problem. Although I'm
sure this report works well for you, it is really unusable in the long
run by patching it this way. I am *happy* to work with you to improve
the advanced portfolio to work better, but I'm not willing to spend a
lot of time translating the report to the current version. I did
translate the txn-currency version you posted in #350658 to the
current version because I think it's good and a relatively simple
change. But some of the other things you're doing here are more
extensive and since you clearly understand what you're trying to do,
you need to be the one to make the changes.
> Meanwhile, I note that the basis value calculation based on the average
> value is wrong (the base value may even become negative). As well in my
> report than in the original one.
How so? Which version? I think this is fixed in current versions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20071223/fe1e0cb9/attachment.bin
More information about the gnucash-devel