[GNC-dev] book-currency

[Christopher Lam]

Just wish to ask update.
I intend to refactor lots of scheme code, there's lots of inefficiencies
here; at the very least I can optimise them safely.

On Wed., 4 Jul. 2018, 08:12 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.
>
>
>
>