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 (~10000 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

Reply via email to