Book-currency feature and cost accounting

[Alex Aycinena]

John,

On Thu, Oct 9, 2014 at 5:26 PM, John Ralls <jralls at ceridwen.us> 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