GnuCash setup for multi-country use / and reply-all should be discouraged

[Derek Atkins]

cognitive.libertarian+ml at gmail.com writes:

> * Derek Atkins <warlord at MIT.EDU> [2010-02-19 07:14]:
>> 
>> I've seen no patches that "fix this problem"..  But changing
>> accounts to hold multiple currencies would be extremely problematic
>> given the current architecture.  You would have to modify every
>> Split to include a commodity instead of making the current
>> assumption that all Splits into an account share a currency (the
>> account currency).
>
> I've not seen the code, so I have no idea what kind of overhaul the
> fix would involve.  

Much.  It's a pretty invasive change.

> In terms of splits, I see no significant problem with a split
> continuing to assume a single currency, because asset accounts would
> still be mono currency.  Expense transactions would inherit the
> currency of the asset account.  Generally, splits involve one asset
> account to many expense accounts, which is the trivial case.  

Note that a Split itself doesn't have a currency -- it takes the
currency from the Split->Account->Currency.  But you're proposing that
an Account no longer have a single currency, which is where we have the
disconnect.

Note that I'm using Split in the gnucash definition, not in the "Split
Transaction" definition.  Even a "non-split transaction" has two Splits
(the debit Split and the credit Split).

> But even if you have a split mapping multiple different asset accounts
> to a single expense account, complexity only arises if the asset
> accounts in that split have currency differences.  And in such an
> odd-ball case where someone is doing something strange, it would be
> quite acceptible not to support it because splits can always be
> represented w/ multiple transactions.  That compromise would be much
> more acceptible for multicurrency users than the status quo.  

The gnucash structure is effectively:

  Transaction =: { Date, Currency, Description, SplitList }
  SplitList   =: { Split, ... }
  Split       =: { Account, Amount (in Account Currency),
                   Value (in Transaction Currency) }

So the Split Currency is implicit from the Account Currency of the
Split.  If you don't have a stable Account Currency then you need to
store that data elsewhere.

This would also imply a major data file rewrite..  Which means you're no
longer data-file compatible backwards or forwards.

>> Still, show me a patch and then we can discuss its merits.  Ideas
>> without patches are more readily ignored, because, well, *I* am not
>> going to implement it....
>
> The merit of an enhancement, or fix, is quite separate, and ignoring
> it is quite acceptible in your case.  
>
> But that's not what happened here.  In this case, some developer
> decided that they personally were not going to implement it (as you
> are), but then she used that as a basis for rejecting the bugzilla
> record on behalf of everyone.  Presumeably, she was not the only
> developer on the project.

I'm not going to argue the merits of feature requests that imply huge
architectural changes to GnuCash.  Sometimes I think we should take on
the MythTV approach; their tracker is only for bugs.  They automatically
close any enhancement request without a patch.

>> > Please remember to CC this list on all your replies.
>> > You can do this by using Reply-To-List or Reply-All.
>
> Please don't encourage use of "reply all".  Everyone who posts is
> inherently on the list, and gets the message.  We don't need a
> duplicate.  

Nope, everyone who posts is *NOT* inherently on the list, so they do NOT
inherently get the message.  There's this concept called "moderation"
where you can go through and manually allow messages through to the list
for those who were not subscribed..  We encourage anyone and everyone to
ask questions here, even if they are not subscribed.

> Reply-all is often used by those who have substandard mail clients
> that don't offer Reply-To-List, and it creates problems for those who
> have proper mail filtering (eg. procmail keying on List-Id).  Dupe
> filtering fails on the user end because nothing ensures that the list
> reply is the first in sequence, so half the time the list version gets
> canned.

This is why you should do dup checking based on Message-Id, which
catches these dups just fine.

> In this case, you did a reply-all and I received a personal copy from
> you in my personal inbox because the list headers were missing, so it
> was not properly filtered.  I actually have the list configured to
> only send one copy to my account, but the list software also makes a
> poor choice here; it passes along the message with missing headers.

This is also why you should base your filtering on To/Cc and not on
non-standardized headers.

By forcing a Reply-To to the list you also make it MUCH HARDER to allow
someone to reply privately if they want to.  It's quite annoying when I
want to send a personal reply but I can't because when I hit reply it
forces it to go back to the list.  *I* know better than the
administrator as to whom I want to send my messages.  Don't force me to
send to the list when I don't want to.  Indeed, this is exactly why we
encourage Reply-To-List usage.

Personally, yes, I use Reply-All.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-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
       warlord at MIT.EDU                        PGP key available