Book-currency feature and cost accounting

[Alex Aycinena]

John,



On Fri, Oct 10, 2014 at 7:40 PM, John Ralls <jralls at ceridwen.us> wrote:

>
> [snip]
>
> 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
>
> My thinking is that, if you tracked cash-in-wallet, and had one in JPY in
this example, if the expense accounts were in USD, then the system would
calculate the cost in USD of the JPY spent (since it is tracking lots and
would use the user-selected costing policy, LIFO, FIFO, etc.) and that
would be the amount in the USD expense split. Therefore there would be no
gain/loss split and no extra work for the user (but the user could elect to
override the default if they wished to do so, in which case there could be
a gain/loss).

Regards,

Alex