Unintended consequences / retrograde behaviour re 2.6.16 fix of Bug 603379 - Prevent changing some Account Options if it has transactions.

[Geert Janssens]

>> On May 2, 2017, at 5:11 PM, Wm via gnucash-devel
>> <gnucash-devel at gnucash.org> wrote:
>> 
>> On 24/04/2017 23:31, Wm via gnucash-devel wrote:
>> 
>> [apparent ff to self]
>> 
>> I have a message from JohnR that I think may have been intended for this
>> list.
>> 
>> It makes sense to me for other people to see it and hear him before I
>> represent my case on immutability.
>> 
>> ===
>> 
>> I think account types *are* immutable in formal accounting, but I'm open
>> to changing my mind if you can suggest some use-cases where it's allowed.
>> 
>> To ensure that we're talking about the same thing, the account types
>> are: Asset, with subclasses  Bank, Stock, Mutual Fund, and Cash;
>> Liability, with subclass Credit Card; Equity, with subclasses Income and
>> Expense; and special types that are for GnuCash's internal use Payable,
>> Receivable, and Trading. There are some others declared in the code that
>> aren't exposed anywhere so they don't count.
>> 
>> I'll stipulate that Stock and Mutual Fund behave exactly the same, as do
>> Bank and Cash, so those four should be collapsed into two.
> 
> I had a network issue posting to the list (comcast timed out trying to
> connect to code.gnucash.org when delivering mail for gnucash-devel while
> working just fine with gnucash-user) when I sent that to you and gave up
> after several retries.
> 
> Derek, Geert, and I discussion about this on IRC the other day and both
> disagree with me. I think Geert is looking into how to restore the
> account type selector and block type changes between STOCK/FUND and
> everything else.

I believe you are correct accounts are immutable in formal accounting. In 
formal accounting transactions are immutable as well. Yet we allow users to 
change transactions if they choose not to adhere to formal accounting rules. 
In that sense I believe we can also allow users to do the same with accounts 
if they choose to do so, at least within reasonable limits.
These limits are:
- the commodity shouldn't be changed. It wouldn't make sense that an account 
that was tracking USD suddenly starts tracking EUR. The values wouldn't match 
consistently.
- GnuCash makes certain assumptions about Accounts Receivable and Accounts 
Payable account types and stores more information in those internally than in 
other account types. Changing types on these accounts would violate these 
assumptions and/or would lose the added information. To avoid these changing 
account types to/from A/R and A/P should not be allowed.
- John also mentions the Trading account type. While it's an internal use type 
as well I don't know much about the assumptions gnucash makes on these account 
types nor whether changing an account to/from such a type would affect 
gnucash' proper functioning or not. Nor can I imagine a use case where it 
would make sense to change to/from a trading account. They are generated 
automatically when needed.

Regards,

Geert