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  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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Wm via gnucash-devel]

On 08/05/2017 16:30, Derek Atkins wrote:
> "Frank H. Ellenberger"  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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Derek Atkins]

"Frank H. Ellenberger"  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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Wm via gnucash-devel]

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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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]

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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Robert Fewell]

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  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
> > >>  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
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

On woensdag 3 mei 2017 10:02:44 CEST Geert Janssens wrote:
> >> On May 2, 2017, at 5:11 PM, Wm via gnucash-devel
> >>  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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 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
>>  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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

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 
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
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

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  wrote:
> 
> 
>> On May 2, 2017, at 5:11 PM, Wm via gnucash-devel  
>> 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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Wm via gnucash-devel]

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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Wm via gnucash-devel]

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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel