FX gain/loss account selection: way forward

[Erik Huelsmann <..hidden..>]

As promised this morning, here's my proposal on the way forward on the
FX gain/loss account identifiers in the account setting table.

The problem started out as this: there's a mismatch between
Payment.sql::payment_post() on one side and the defaults table and
standard CoA files on the other, because the former uses the FX_loss
and FX_gain configuration keys to retrieve account information to post
on while the latter stores said information using the fxgain_accno_id
and fxloss_accno_id configuration keys.


I propose:

a. To simply change the Payment.sql file to query the fxgain_accno_id
and fxloss_accno_id parameters instead of using the current FX_loss
and FX_gain
b. To add a query to Fixes.sql which sets the fxgain_accno_id and
fxloss_accno_id based on the values of FX_loss and FX_gain in the
config table - if they exist


However, further testing reveals that there is another problem:

When changing the default account settings in the defaults screen, the
selections are being saved using the configuration keys 'IC',
'IC_income', 'IC_expense', 'FX_gain' and 'FX_loss' instead of the
actual *_accno_id config key settings. IOW, saving the data in the
defaults screen creates new config keys, but doesn't change the old
ones.

Even worse: the values of the *_accno_id keys are not being used to
preselect the current account settings selection values.

With respect to this issue, I propose:

a. To stop using the 'IC', 'IC_income', 'IC_expense', 'FX_gain' and
'FX_loss' keys in the UI when we don't want to use them in the backend
b. By patching the application until these keys - when used as config
keys - are completely eliminated
c. We add a query to Fixes.sql to remove these keys of any existing
defaults tables
d. We test the AR/AP workflows (and any others?) to see if the
selections of income and expense accounts actually affect the
selection boxes in the entry screens


Comments?

Bye,


Erik.