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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

GnuCash - Dev mailing list
I have long considered it a very-good-thing that gnc allowed accounts to
be moved between formal accounting objects (assets, liabilities, equity,
income, expenses) so long as the plus and minus signs underneath worked.

It looks like fixing 603379 has involved taking much of this freedom
away, I could understand if some "do you really know what you are
doing?" interference was added but do not like this introduction of
nanny at all and I'm not sure if the limit was intentional or
consequential.  More below.

The good news for me is that I have kept a working copy of 2.6.15 which
isn't shackled so I'm ok until the next significant db change.

Reading through the Bugzilla for 603379 I see Geert said on 2017-03-17:13:34
===
The idea is good. Strictly speaking the account type can change as long
as the existing currency/commodity is a valid one for the new account
type or the type is not changing to/from a business account type.
===

Geert is correct and I think somewhere in fixing this that has got lost,
also not involving business account types is a gnc internal thing not an
accounting thing, it is just that the gnc business accounts aren't ready
for this sort of interaction.

So, here are my late night thoughts for other people to think about, add
to, differ with:

If the currency / commodity is unchanged and neither of the account
parents is a business account the change should be allowed.

So I think that sort of takes me in a circle, if we're moving an account
in the tree aren't we by definition leaving currency / commodity
unchanged ?  We're moving it not changing it, right?

and then there is Geert on 2017-03-17:17:06
===
Just a heads up: disallowing the user to change account types is
actually the solution for bug 548021.
===

and that goes back to 2008 / 2009 and then jumps to JohnR making a
comment in 2013 and then account types becoming immutable.

================

Account types are not immutable.  Not in formal accounting or (with some
practical exceptions) in gnc.

I'd like 603379 and the older 548021 to be reviewed with the idea being
that:

flexibility should be allowed where sensible

 and

silly behaviour (5USD can't be 5GBP most of the time, 10IBM shares can't
be 10CIA shares any time, etc) should be prevented.

--
Wm







_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

GnuCash - Dev mailing list
On 24/04/2017 23:31, Wm via gnucash-devel wrote:

[ff own post]

> I have long considered it a very-good-thing that gnc allowed accounts to
> be moved between formal accounting objects (assets, liabilities, equity,
> income, expenses) so long as the plus and minus signs underneath worked.
>
> It looks like fixing 603379 has involved taking much of this freedom
> away, I could understand if some "do you really know what you are
> doing?" interference was added but do not like this introduction of
> nanny at all and I'm not sure if the limit was intentional or
> consequential.  More below.
>
> The good news for me is that I have kept a working copy of 2.6.15 which
> isn't shackled so I'm ok until the next significant db change.

OK, 2.6.16 has definitely gone too far with immutability.

Consider this:

Assets (type Asset)
  p2p lending (type Asset)
    bids (type Asset)
    cash (type Asset) [1]
    loans (type Asset)

[1] 2.6.16 won't allow me to change
Assets:p2p lending:cash
to type Bank because it contains transactions.

THIS IS WRONG

It could be argued that giving Assets insignificant meaning (Bank vs
Cash) was a bad move in the first place, but that decision was taken a
while back.

To say that a sub Asset can't be called Bank because its parent is an
Asset is fucking with sensibility ... I think it also means that a whole
lot of the examples in the tutorials won't work any more :)

Undo the immutability change ASAP, please!

--
Wm






_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

GnuCash - Dev mailing list
In reply to this post by GnuCash - Dev mailing list
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.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

John Ralls-2
And it bounced again, so trying again with a different smtp server.

Regards,
John Ralls

> On May 2, 2017, at 6:30 PM, John Ralls <[hidden email]> wrote:
>
>
>> On May 2, 2017, at 5:11 PM, Wm via gnucash-devel <[hidden email]> 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.
>
> Regards,
> John Ralls
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Christopher Lam
In reply to this post by GnuCash - Dev mailing list
Not sure how much this adds to the discussion, but a long time ago, as a
user new to job market and accounting in general, I was expensing my
pension contributions. As a salaried employee, and as a new contractor, I
was categorizing them as Expenses:Pension

Now I know these belong in the assets column. It was a quick job to
reparent the Retirement account from Expenses to Assets. Agree with Wm if
this is disabled then the gnucash beautiful ability to grow into our mental
model will be lost.

Perhaps we just need to ensure the commodities are immutable, whereas
account type can change... as long as they're not stock/fund/business
accounts.

On 3 May 2017 at 08:11, Wm via gnucash-devel <[hidden email]>
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.
>
> Regards,
> John Ralls
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Geert Janssens-4
In reply to this post by John Ralls-2
>> On May 2, 2017, at 5:11 PM, Wm via gnucash-devel
>> <[hidden email]> 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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Geert Janssens-4
On woensdag 3 mei 2017 10:02:44 CEST Geert Janssens wrote:

> >> On May 2, 2017, at 5:11 PM, Wm via gnucash-devel
> >> <[hidden email]> wrote:
> > 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.

Oh, and I meant to add I'm not working on this issue (yet). As Robert Fewell
is the original author of the previous patch I was kind of hoping he would
pick it up :)

If not, I will handle it.

Regards,

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Robert Fewell-2
I have been watching this and can look at it again when a clear outcome of
this discussion is made and hopefully the bug can be updated with what is
required.

Bob

On 3 May 2017 at 11:44, Geert Janssens <[hidden email]> wrote:

> On woensdag 3 mei 2017 10:02:44 CEST Geert Janssens wrote:
> > >> On May 2, 2017, at 5:11 PM, Wm via gnucash-devel
> > >> <[hidden email]> wrote:
> > > 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.
>
> Oh, and I meant to add I'm not working on this issue (yet). As Robert
> Fewell
> is the original author of the previous patch I was kind of hoping he would
> pick it up :)
>
> If not, I will handle it.
>
> Regards,
>
> Geert
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Frank H. Ellenberger-3
In reply to this post by GnuCash - Dev mailing list
Hi,

Am 03.05.2017 um 02:11 schrieb Wm via gnucash-devel:
8X---
> 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.

In theory the is a difference, but currently  not implemented in GnuCash
between Bank and Cash:

Cash must never be below zero.

~Frank
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

GnuCash - Dev mailing list
On 07/05/2017 15:30, Frank H. Ellenberger wrote:
> Hi,

[JohnR not Wm said]
> Am 03.05.2017 um 02:11 schrieb Wm via gnucash-devel:
> 8X---
>> 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.
>
> In theory the is a difference, but currently  not implemented in GnuCash
> between Bank and Cash:
>
> Cash must never be below zero.

That is not an issue in accounting.  It is an issue in banking, it is an
issue in business and personal finance.  But in accounting?  Nope.
Accounting does not care.

I've also just checked and my actual gnc Cash account has sometimes gone
into the apparent red when I've recorded transactions in a natural order.

e.g. out for a meal, I pay, people give me the money.

are you really saying in accounting a Cash account must never be below
zero?  It happens all the time in real life ... and accounts should
reflect not dictate, after all.

It is possible people use these differently[1], but I think if gnc
prevented the entry above it would upset people.

[1] I call what is in the pockets of my clothing a Cash account and
don't think it needs a new name, it is the cash I have on me.

IMO the Asset and Liability types are over divided.  Unless they are
doing something useful they should be consolidated longer term.

Also it is silly in modern banking, my current account provider offers
me a free overdraft.

If I use that ofverdraft facility does my account change from a Cash
account to a Bank account in gnc?  No.  The definition is artificial.

In summary I disagree strongly with Frank and say differences between
Cash and Bank should be removed because they do not reflect natural
accounting.

I say further that issues of very personal finance like "your cash
cannot go below zero" are issues that gnc passed by when it stopped
being a personal finance nanny copy of another piece of software.

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Derek Atkins
In reply to this post by Frank H. Ellenberger-3
"Frank H. Ellenberger" <[hidden email]> writes:

> Hi,
>
> Am 03.05.2017 um 02:11 schrieb Wm via gnucash-devel:
> 8X---
>> 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.
>
> In theory the is a difference, but currently  not implemented in GnuCash
> between Bank and Cash:

IMNSHO, the main different between the various sub-types is the
displayed header in the register.  E.g. Cash is Spend and Receive,
whereas Bank is Deposit and Withdrawl, Credit Card is Charge and
Payment, etc.  The underlying functionality is the same otherwise, but I
think it's still useful to users, especially new users, to have the
commonplace headings.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

GnuCash - Dev mailing list
On 08/05/2017 16:30, Derek Atkins wrote:

> "Frank H. Ellenberger" <[hidden email]> writes:
>
>> Hi,
>>
>> Am 03.05.2017 um 02:11 schrieb Wm via gnucash-devel:
>> 8X---
>>> 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.
>>
>> In theory the is a difference, but currently  not implemented in GnuCash
>> between Bank and Cash:
>
> IMNSHO, the main different between the various sub-types is the
> displayed header in the register.  E.g. Cash is Spend and Receive,
> whereas Bank is Deposit and Withdrawl, Credit Card is Charge and
> Payment, etc.  The underlying functionality is the same otherwise, but I
> think it's still useful to users, especially new users, to have the
> commonplace headings.

Hmmmn, somewhere along the way gnc made commonplace headings (which I
agree are useful labels versus + and - or Dr and Cr) immutable.

I think when it is put that way most people will see the new found
immutability as a problem not to be solved.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Derek Atkins
Wm via gnucash-devel <[hidden email]> writes:

>> IMNSHO, the main different between the various sub-types is the
>> displayed header in the register.  E.g. Cash is Spend and Receive,
>> whereas Bank is Deposit and Withdrawl, Credit Card is Charge and
>> Payment, etc.  The underlying functionality is the same otherwise, but I
>> think it's still useful to users, especially new users, to have the
>> commonplace headings.
>
> Hmmmn, somewhere along the way gnc made commonplace headings (which I
> agree are useful labels versus + and - or Dr and Cr) immutable.

I'm not sure I understand your statement here:  "somewhere along the way
gnc made commonplace headings immutable."?  What does this mean?

> I think when it is put that way most people will see the new found
> immutability as a problem not to be solved.

Huh?  How do you come to this conclusion?

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel