John, On Thu, Oct 9, 2014 at 5:26 PM, John Ralls <[email protected]> wrote:
> > Alex, > > How much clean-up/refactoring and C++ conversion are you willing to do in > the process? > I am willing to do some when I spot an opportunity, or it is pointed out to me. May I consult you about this? > > There’s already a “Book Currency”, but it’s not exposed in > File>Properties. It’s set by the New File Assistant. There’s also Default > Currency in Prefs, which is the default currency for scheduled > transactions. IMO it would be an improvement to get rid of this and expose > the book currency in File>Properties regardless of the forex option. > > Speaking of SX, how do you propose to handle the exchange rate for those? > This I will have to think about. > > The lots facility currently uses a hard-coded account for capital gains > (with a really stupid name, “Orphaned Gains”) per-currency. The part of > your change that creates a selectable gains account should apply regardless > of how forex is handled. > That is a good point. > > I think the problem with multiple realized gains is in Scrub3.c, not in > the Lot Viewer code, but if I’m wrong about that please move any “business > logic” code that you find in the Lot Viewer into engine where it belongs. > > Be careful with automatically invoking the lots facility: In the usual > multi-currency transaction there is no potential for capital gain because > the holding period of the “foreign” currency is 0. That case is making a > purchase or sale of something in a foreign currency which is immediately > converted to one’s home currency. Even when the user has long-term holdings > of the “foreign” currency that *are* subject to capital gains and losses, > those immediate transactions won’t and shouldn’t clutter up the database > with 0-value cap gain splits. > > I agree with you here. If someone, for example, use their credit card in a foreign country (essentially 'buying' the foreign currency and then immediately spending it), then I don't think lots would be involved as long as both accounts are in the book-currency. If the user has a long-term holding in the "foreign" currency, and then spends it, the system would have a cost for that holding, and if the cost is used to value the spend, then there would be no capital gain/loss. If the uses wishes to value the spend at, say, the then current exchange rate, then the system has the data to calculate and show the resulting gain/loss and create the split to the account specified for the account (with the user option to override). > Regards, > John Ralls > > Regards, Alex _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
