Re: Stock price transactions
"Kevin A. Foss" writes: On Tue, Dec 05, 2000 at 12:50:38AM -0800, Dave Peticolas wrote: also needs to wait. It is true that GnuCash 1.4 allows stock-type accounts with no security, but this is really a bug. A stock-type account is supposed to be counting *something* and thus every such account really must have an actual security specified. The old-format importer needs to be modified to prompt the user to specify an actual security for such accounts where none exists. That should eliminate the need for the patch. Well this leads to a question I have, I currently use the Mutual Fund account type to hold the payments I make into my Investment Club, which obviously isn't an actual 'security' per se. Basically the accounting software we use started us out at $10/share in the club, so $100 bought 10 shares. Now over time the price has fluctuated with the value of the stocks we've bought, etc and I periodically enter a share price so any gains/losses figure into the overall value of the investment tree in gnucash. I find this much, much easier than maintaining my own shadow 'mutual fund' and trying to figure my share of all the stocks we own. So my question, is 1) what *should* I be filling in for a security? just a dummy string? or 2) is there a better account type in Gnucash to keep track of a club type investment? 1) For GnuCash 1.4, a 'dummy' string would be fine, though it's not really a dummy -- after all, you do own real shares in this club, so why not give them a name? In the next version of GnuCash, you can create a new 'commodity' type to represent the shares in your club. 2) No, I think mutual fund is really the most appropriate for what you are doing. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Stock price transactions
Bill Carlson [EMAIL PROTECTED] writes: Fine, except do you have any idea of when some of this support will be put in? If I (and I suspect others) are going to realistically try to work on the new stuff, this is necessary. I'm signed up for this, and I should be getting started in the next week. I've already nearly finished re-working the "quote getting" infrastructure to remove the need for swig, and finishing up that will be my first priority after I get the new g-wrap stuff finished (which should be in the next day or two). I would point out that one of the main reasons I use gnucash (or any such program) is to keep track of "where I am" financially (with history). This means that eventually things like the account table gnucash shows on startup need to reflect the "current" value of a stock, and there need to be mechanisms to produce a history of that. I can do all that just fine with the current mechanisms. Just want to make sure that whatever you are thinking of for this area reflects these "requirements". Absolutely. Oh, and you probably know this, but right now, 1.5 really is UNSTABLE. In the past, you were pretty safe using it for real data, but right now I would *highly* caution against that. We may even change the XML format in a backward incompatible way, though we'll obviously go be willing to go to some reasonable lengths to avoid that inconvenience. One more thought on this. Whatever "register" display you have for stocks should (I think) reflect the values of the stock at that time of each given transaction. I think that means that if you don't have the "price transactions" the redisplay mechanism would need to consult the "price database" every time you opened/refreshed the "register" for the stock account. Already thinking about that. Actualy, the quote database is going to have to be somewhat smart. We're going to have to keep track of "why" a quote's in the database. For example, if you enter a stock transaction, and you put in a price, the price will go into the quote database, not the transaction, but the quote will have to know that it came from a transaction so that if the user deletes that transaction, or even if they just change the date, the quote in the database can be deleted/updated as appropriate, and these "transaction quotes" will need to be distinguishable from "historical quotes" (right now those would be quotes obtained via the online-mechanism) somehow. Again, thanks for your help and feedback. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Stock price transactions
On Tue, Dec 05, 2000 at 08:01:40AM -0600, Bill Gribble wrote: On Tue, Dec 05, 2000 at 08:15:00AM -0500, Bill Carlson wrote: Fine, except do you have any idea of when some of this support will be put in? If I (and I suspect others) are going to realistically try to work on the new stuff, this is necessary. We're doing the best we can, but it's been very clearly stated that the 1.5.x series is for DEVELOPMENT, not end-user use. Yes, there are things about it that are broken, but that's because it's under development. You really should not be using the 1.5.x series for real work. Thanks, Bill Gribble I knew that I just wanted to know when you were going to start working on this area so I could help (note the words "work on the new stuff") :-) Cheers, Bill ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Stock price transactions
Dave Peticolas wrote: I am going to hold off on putting this patch in because I think it needs more discussion. Our plans for stock prices in GnuCash 2.0 are to store them separately from the register (and from accounts), and to use them for reporting/graphing purposes, but not to store them as 'real' transactions the way they are in GnuCash 1.4. I just want to say, that I strongly agree to this. I don't like the price only transactions. Herbert -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/ ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Stock price transactions
Bill Carlson writes: Hi All, In my working on the latest CVS source, I noticed some problems with a number of stock "price only" transactions that I have (as per the manual) getting imported from the binary file badly (turns up as zero price!). The following set of patches fixes these problems. The basic concept is that now that we are using REAL rational numbers, we can actually use a zero deamount as an accurate flag for the "price only" split. This makes perfect sense as we are not changing the damount, only the overall value. The only changes that needed to be made are in the accessor functions to return the "right" value for these sorts of splits. I've tested this change on my pretty big (~1 trans) file and it does well. Please accept these changes into the CVS source (or feel free to propose an alternative if this is not the way to handle it!). By the way, I also have an idea as to how todeal with splits and the like using a "zero value" but changing damount. Works well. If people are interested, I could do that up, test it, and send it in. I am going to hold off on putting this patch in because I think it needs more discussion. Our plans for stock prices in GnuCash 2.0 are to store them separately from the register (and from accounts), and to use them for reporting/graphing purposes, but not to store them as 'real' transactions the way they are in GnuCash 1.4. Part of the old format import process would be to convert these old price transactions into entries in the price database. The other part of the patch, which prevents normalizing the damount and value parts of a split for stock-type accounts with no security, also needs to wait. It is true that GnuCash 1.4 allows stock-type accounts with no security, but this is really a bug. A stock-type account is supposed to be counting *something* and thus every such account really must have an actual security specified. The old-format importer needs to be modified to prompt the user to specify an actual security for such accounts where none exists. That should eliminate the need for the patch. thanks, dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Stock price transactions
On Tue, Dec 05, 2000 at 08:15:00AM -0500, Bill Carlson wrote: Fine, except do you have any idea of when some of this support will be put in? If I (and I suspect others) are going to realistically try to work on the new stuff, this is necessary. We're doing the best we can, but it's been very clearly stated that the 1.5.x series is for DEVELOPMENT, not end-user use. Yes, there are things about it that are broken, but that's because it's under development. You really should not be using the 1.5.x series for real work. Thanks, Bill Gribble ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Stock price transactions
On Tue, Dec 05, 2000 at 12:50:38AM -0800, Dave Peticolas wrote: I am going to hold off on putting this patch in because I think it needs more discussion. Our plans for stock prices in GnuCash 2.0 are to store them separately from the register (and from accounts), and to use them for reporting/graphing purposes, but not to store them as 'real' transactions the way they are in GnuCash 1.4. Part of the old format import process would be to convert these old price transactions into entries in the price database. Fine, except do you have any idea of when some of this support will be put in? If I (and I suspect others) are going to realistically try to work on the new stuff, this is necessary. I would point out that one of the main reasons I use gnucash (or any such program) is to keep track of "where I am" financially (with history). This means that eventually things like the account table gnucash shows on startup need to reflect the "current" value of a stock, and there need to be mechanisms to produce a history of that. I can do all that just fine with the current mechanisms. Just want to make sure that whatever you are thinking of for this area reflects these "requirements". One more thought on this. Whatever "register" display you have for stocks should (I think) reflect the values of the stock at that time of each given transaction. I think that means that if you don't have the "price transactions" the redisplay mechanism would need to consult the "price database" every time you opened/refreshed the "register" for the stock account. Just some thoughts. The other part of the patch, which prevents normalizing the damount and value parts of a split for stock-type accounts with no security, also needs to wait. It is true that GnuCash 1.4 allows stock-type accounts with no security, but this is really a bug. A stock-type account is supposed to be counting *something* and thus every such account really must have an actual security specified. The old-format importer needs to be modified to prompt the user to specify an actual security for such accounts where none exists. That should eliminate the need for the patch. Again, fine. I certainly recognize this as a "hack" and would be quite willing to work on such an importer at the apropriate time. thanks, dave And thank you for all your gnucash efforts. I am very impressed by the results your efforts! Cheers, Bill ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Stock price transactions
Hi All,
In my working on the latest CVS source, I noticed some
problems with a number of stock "price only" transactions that
I have (as per the manual) getting imported from the binary file
badly (turns up as zero price!). The following set of patches fixes
these problems. The basic concept is that now that we are
using REAL rational numbers, we can actually use a zero deamount
as an accurate flag for the "price only" split. This makes perfect
sense as we are not changing the damount, only the overall
value. The only changes that needed to be made are in the accessor
functions to return the "right" value for these sorts of splits.
I've tested this change on my pretty big (~1 trans) file and
it does well. Please accept these changes into the CVS source
(or feel free to propose an alternative if this is not the way
to handle it!). By the way, I also have an idea as to how todeal with
splits and the like using a "zero value" but changing damount. Works
well. If people are interested, I could do that up, test it, and
send it in.
Cheers,
Bill Carlson
[EMAIL PROTECTED]
Index: src/engine/Account.c
===
RCS file: /home/cvs/cvsroot/gnucash/src/engine/Account.c,v
retrieving revision 1.98
diff -r1.98 Account.c
535c535,536
return gnc_numeric_zero();
---
return gnc_numeric_mul(share_count, s-value,
gnc_numeric_denom(s-value), GNC_RND_ROUND);
Index: src/engine/Scrub.c
===
RCS file: /home/cvs/cvsroot/gnucash/src/engine/Scrub.c,v
retrieving revision 1.18
diff -r1.18 Scrub.c
163a164,167
/*
* don't adjust splits in STOCK or MUTUAL accounts, because some
* users have not set securities for all such accounts
*/
165c169,170
if (!account)
---
if (!account || xaccAccountGetType(account) == STOCK
|| xaccAccountGetType(account) == MUTUAL)
Index: src/engine/Transaction.c
===
RCS file: /home/cvs/cvsroot/gnucash/src/engine/Transaction.c,v
retrieving revision 1.137
diff -r1.137 Transaction.c
383,384c383,393
s-value = gnc_numeric_mul(s-damount, price,
get_currency_denom(s), GNC_RND_ROUND);
---
/*
* if amount is REALLY zero, set value to price because this
* is a price-setting split that has no effect on share balance
*/
if (gnc_numeric_zero_p (amt))
s-value = gnc_numeric_convert(price, get_currency_denom(s),
GNC_RND_ROUND);
else
s-value = gnc_numeric_mul(s-damount, price,
get_currency_denom(s), GNC_RND_ROUND);
402,403c411,420
s-value = gnc_numeric_mul(s-damount, price, get_currency_denom(s),
GNC_RND_ROUND);
---
/*
* if amount is REALLY zero, set value to price because this
* is a price-setting split that has no effect on share balance
*/
if (gnc_numeric_zero_p (s-damount))
s-value = gnc_numeric_convert(price, get_currency_denom(s),
GNC_RND_ROUND);
else
s-value = gnc_numeric_mul(s-damount, price, get_currency_denom(s),
GNC_RND_ROUND);
2173a2191,2195
DxaccSplitGetRawValue (Split * split) {
return gnc_numeric_to_double(xaccSplitGetRawValue(split));
}
double
2188a2211,2228
/*
* zero damount means this is a special price-only split,
* meaning the value of the split is really zero
*/
if (gnc_numeric_zero_p(split-damount))
return gnc_numeric_zero();
return split-value;
}
/*
* A function which returns the raw value, mainly
* for saving
*/
gnc_numeric
xaccSplitGetRawValue (Split * split) {
if (!split) return gnc_numeric_zero();
2194c2234
if(!split || gnc_numeric_zero_p(split-damount)) {
---
if(!split) {
2196,2199c2236,2240
}
return gnc_numeric_div(split-value,
split-damount,
PRICE_DENOM, GNC_RND_ROUND);
---
} else if (gnc_numeric_zero_p(split-damount)) {
return split-value;
}
return gnc_numeric_div(split-value, split-damount,
get_security_denom(split), GNC_RND_ROUND);
Index: src/engine/Transaction.h
===
RCS file: /home/cvs/cvsroot/gnucash/src/engine/Transaction.h,v
retrieving revision 1.81
diff -r1.81 Transaction.h
426a427
doubleDxaccSplitGetRawValue (Split * split);
430a432
gnc_numeric xaccSplitGetRawValue (Split * split);
Index: src/engine/io-gncbin-r.c
===
RCS file: /home/cvs/cvsroot/gnucash/src/engine/io-gncbin-r.c,v
retrieving revision 1.5
diff -r1.5 io-gncbin-r.c
1124a1125
split-acc = acc;
Index: src/engine/io-gncxml-w.c
