Book-currency feature and cost accounting

Bob Gustafson bobgus at rcn.com
Sat Oct 11 10:17:47 EDT 2014


On 10/10/2014 09:40 PM, John Ralls wrote:
> On Oct 10, 2014, at 4:14 PM, Alex Aycinena <alex.aycinena at gmail.com> wrote:
>
>> 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?
> Of course.
>
> [SNIP]
>
>> 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).
> Right. The credit card transaction in particular has the potential to ignore the "foreign" currency. I was thinking more of the people who track "cash in wallet". If I'm visiting
> (my family says Japan is next) and get 10000JPY from the ATM I'd need a Cash and some Expense accounts in JPY to account for spending that cash. Since those transactions
> wouldn't be in the book currency (USD in my case) I'd be presented with a Transfer dialog box for each, and might select a different exchange rate from the one used for the
> ATM withdrawal, inadvertently creating a wholly bogus cap gain/loss. That's all entirely hypothetical, I treat cash as an expense category and don't worry much about how
> I spend it because in general I don't use it that much., but since "Cash in Wallet" is one of the accounts in the templates I'm sure there are others who do track it.
>
> Regards,
> John Ralls

Decades ago, when I was doing more international business travel, I kept 
track of my money exchange receipts and periodically counted the cash in 
my pocket and wrote it down. I had a little basic program that tracked 
my business and personal expenses.

Because I would exchange money at different times (and rates), it was 
possible to assign the more favorable exchange rates to my personal 
expenses. I don't know whether this minor 'profit' ever approached 
paying for the (slight) extra time needed to keep track of things, but 
it was fun.

Bob G


More information about the gnucash-devel mailing list