Book-currency feature and cost accounting

John Ralls jralls at ceridwen.us
Thu Oct 9 20:26:43 EDT 2014


On Oct 9, 2014, at 2:30 PM, Alex Aycinena <alex.aycinena at gmail.com> wrote:

> Developers,
> 
> I am planning to add a feature to gnucash, primarily, but not exclusively,
> related to currency accounting, and wanted to summarize what I was thinking
> of. I would welcome feedback.
> 
> Since version 2.4.0, GnuCash supports trading accounts as described in
> 'Tutorial on multiple currency accounting' and 'Multiple currency
> accounting in GnuCash' by P. Selinger (see
> http://wiki.gnucash.org/wiki/Trading_Accounts). I believe Mike Alexander
> added this feature.
> 
> In his tutorial, he (P. Selinger) mentions a 'reference currency method' as
> an alternative to the use of trading accounts. This is essentially the
> feature I wish to add.
> 
> Today, in file->properties->Accounts tab, you can turn "trading accounts"
> on or off. I propose to change this to a selection of three alternatives:
> use trading accounts, specify a 'book currency', or neither trading
> accounts nor book currency. If trading accounts is selected, it would work
> as implemented by Mike. If neither is selected, it would work as gnucash
> does now without trading accounts selected. So no one would be forced to
> use the new feature.
> 
> If 'book currency' is selected, it would require the specification of the
> book currency in file->properties. Transaction entry would be modified to
> ensure every split that was not in the book currency had a 'price' or
> 'exchange rate' associated with it (to the book currency). In addition, the
> existing lot tracking capabilities would be used to track the 'cost' (in
> book currency) of all accounts not denominated in the book currency (lots
> would automatically be created rather than having the user go through the
> Actions->View Lots process). In entering any transaction that disposes of
> non-book-currency amounts, the user would be provided with assistance to
> calculate and book any gain or loss associated with the transaction based
> on these tracked costs. The idea is that several policies would be used for
> this purpose (probably implemented in phases): LIFO, FIFO, average cost
> (perhaps), manual specification. Much of this lot tracking has already been
> implemented but I don't believe it has been fully tested.
> 
> A 'Cost and Unrealized Gains/Loss' report would be added to the menu if
> this feature is selected. It would show, for all non-book-currency
> accounts, as of a user-selected date: name, currency/commodity, cost,
> quantity, rate, value, unrealized gain/loss. Optionally, for each account,
> lot detail would be shown and, for each lot transaction detail would be
> shown.
> 
> The US Income Tax Report would be enhanced to use the booked gains/losses
> (bug 554397).
> 
> Among the changes I foresee are:
> 
> - File->Properties: specify and select 'book currency', if selected,
> default gain/loss account and default lot tracking policy.
> - Account Edit: for 'non-book-currency' accounts, specify gain/loss
> account, lot tracking policy, short-sales allowed, currency account is
> priced in, skip lot-tracking flag.
> - Register Transaction Entry: transaction currency will be 'Book Currency'
> rather than currency of register transaction is entered from, raise 'Edit
> Exchange Rates' dialog if split not in book currency, create/update lots
> for non-book-currency splits, if a sale (subject to 'short sales' rule),
> uses Lot Tracking Policy to calculate cost amount and tentative gain/loss
> - Stock Split: make compliant
> - Lot Viewer: Modify existing capability so that integrity can't be messed
> up. Also, it should not be available in menu for book-currency accounts. It
> currently has a problem where it seems to generate multiple Realized
> Gain/Loss entries under some conditions I haven't figured out yet.
> 
> It will probably take me several months to get this done. As I said above,
> I welcome feedback/comments.
> 

Alex,

How much clean-up/refactoring and C++ conversion are you willing to do in the process?

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?

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.

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.



Regards,
John Ralls




More information about the gnucash-devel mailing list