[GNC-dev] book-currency

[John Ralls]

> On Jul 3, 2018, at 5:12 PM, Alex Aycinena <alex.aycinena at gmail.com> wrote:
> 
> On Mon, Jul 2, 2018 at 7:35 PM Christopher Lam <christopher.lck at gmail.com>
> wrote:
> 
>> Hi Alex
>> Thank you for update - would you mind letting us know the layman version
>> of it?
>> Thanks!
>> 
>> On 3 July 2018 at 01:02, Alex Aycinena <alex.aycinena at gmail.com> wrote:
>> 
>>> 
>>>> ---------- Forwarded message ----------
>>>> From: John Ralls <jralls at ceridwen.us>
>>>> To: Christopher Lam <christopher.lck at gmail.com>
>>>> Cc: gnucash-devel <gnucash-devel at gnucash.org>
>>>> Bcc:
>>>> Date: Sun, 1 Jul 2018 20:13:37 -0700
>>>> Subject: Re: [GNC-dev] book-currency
>>>> If you’re sure it’s dead code, by all means.
>>>> 
>>>> The volume of cruft often overwhelms the working code, and always wastes
>>>> maintenance time.
>>>> 
>>>> Regards,
>>>> John Ralls
>>>> 
>>>>> On Jul 1, 2018, at 5:47 PM, Christopher Lam <christopher.lck at gmail.com>
>>>> wrote:
>>>>> 
>>>>> There's lots of dead code related to an (AFAIK) unimplemented
>>>> book-currency
>>>>> or currency-accounting feature... Some are cluttering options.scm -
>>>> should
>>>>> we remove them?
>>>>> _______________________________________________
>>>>> gnucash-devel mailing list
>>>>> gnucash-devel at gnucash.org
>>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>> 
>>> 
>>> 
>>> I put it there for a project I am working on (but have gotten delayed
>>> on). It is not dead code; however, allow me to remove it in the next week
>>> or so and I will re-apply it later when the project moves forward.
>>> 
>>> Alex
>>> 
>> 
>> 
> Christopher.
> 
> I have copied and pasted below an email I sent several years ago that
> explains the project. I made several commits on it then pulled them out
> into a separate feature branch. The book option part you see is the first
> part that was not pulled out. I am still planning to proceed with this but
> other time commitments have limited my time on it.
> 
> Regards,
> 
> Alex
> 
> Prior email:
> 
> 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,

That message is https://lists.gnucash.org/pipermail/gnucash-devel/2014-October/038170.html

So the months have turned into years... seems like besides having other commitments get in the way it might have been a more ambitious project than you expected when you started.

How big a deal would it be to revert your 6 main changes plus any fix-ups (I remember at least one from a year ago when you broke the CI tests) and put them in your feature branch? Even if it’s not dead code, it’s comatose like the Register-2 stuff and I worry about comatose code getting irretrievably obsoleted as the main part of GnuCash moves forward.

Regards,
John Ralls