Issues with Placeholder Accounts

Chris Good chris.good at ozemail.com.au
Fri Feb 10 20:04:35 EST 2017


> Message: 1
> Date: Fri, 10 Feb 2017 09:17:57 +0500
> From: "David T." <sunfish62 at yahoo.com>
> To: GnuCash Developers <gnucash-devel at gnucash.org>
> Subject: Issues with Placeholder Accounts
> Message-ID: <875E65EF-1A79-4C3A-ADEB-8BDCE8CA3FB4 at yahoo.com>
> Content-Type: text/plain; charset=utf-8
> 
> Hello,
> 
> I will preface this email with a reminder that I am not a developer, and
> apologize ahead of time if my understanding of GnuCash functionality is
> flawed. That said...
> 
> In the course of trying to corral a problem with Unrealized Gains
reporting, I
> have been dealing with accounts that have had the Placeholder flag set. As
> folks here are no doubt aware, this flag sets the account to read-only
status,
> and indeed, when I open one of these accounts, I am informed of that fact
in
> a dialog box.
> 
> However, there are numerous situations in which GnuCash does not respect
> this. For example: it is possible to create multiple transactions in a
> Commodity type account by using the lots feature and scrubbing the
> account. Similarly, one can edit the split in a placeholder account by
accessing
> the transaction from the far account, which is not set to placeholder. I
don?t
> know whether there are other such exceptional circumstances.
> 
> Both of these undermine the concept of a placeholder account, and raise
> some interesting thoughts for me.
> 
> First, I think the lots feature needs to take this flag into account; it
is quite
> easy to scrub an account and generate numerous gains transactions in a
> placeholder account, which might cause major problems for an unsuspecting
> user.
> 
> Second, I wonder where the placeholder flag is evaluated; it appears to be
at
> the register or perhaps transaction level, but really, it should be
evaluated at
> the split. Changing this is, I am sure, likely to be a painful fix, but I
think it
> ultimately would yield a more consistent result. Evaluating at the split
would
> prevent my second scenario from going through.
> 
> Third, I wonder if this ?Placeholder for people but not processes? concept
> might not be leveraged to address the fragility of A/R and A/P business
> features. That is, have these accounts sets to Placeholder so that users
do
> not edit these transactions directly (something that Derek notes he has
been
> repeating on the lists for ten years), but use processes to modify the
data
> entered into these accounts. Please be aware that I am not a business
user,
> so I only am going on third party information on this. If this is in fact
how it is
> set up, or if the idea is fundamentally dumb, I apologize.
> 
> David
> 

Hi David,

The Help manual says:

A Placeholder means this account is not used for transaction data.
Transactions may not be posted to this account, only to sub-accounts of this
account not marked themselves as Placeholder.

My feelings are...

Maybe the manual should be changed to say you cannot add *additional*
transactions via the register (or import?).

I assume since you have a placeholder stock account with transactions, that
the UI doesn't check if there are existing transactions before allowing it
to be changed to a placeholder account.
I think that is useful functionality that should remain.

If a placeholder stock account already has transactions, then presumably you
have made it a placeholder to stop yourself adding new transactions.
Adding capital gain transactions via scrubbing is really just properly
completing the sale transaction, so I don't see a need for a change there.

Regards, Chris Good
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4817 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20170211/be7c01b1/attachment.p7s>


More information about the gnucash-devel mailing list