some questions on accounts/commodities
Sébastien de Menten
sdementen at gmail.com
Mon Dec 29 15:35:45 EST 2014
On Mon, Dec 29, 2014 at 6:36 PM, John Ralls <jralls at ceridwen.us> wrote:
> > On Dec 29, 2014, at 7:17 AM, Sébastien de Menten <sdementen at gmail.com>
> > hello,
> > I have some questions on gnucash behavior regarding some "limit" changes:
> > - a placeholder account: an account can be converted to a placeholder
> > account even if there are splits related to it. Is it expected behavior ?
> > or should the placeholder flag be selectable only if there are no split
> > the account.
> Expected, because one use of "placeholder" is to freeze an account,
> perhaps because it's been closed.
> Indeed, it makes sense. On 2.6.4, if an account is opened (ie I see the
ledger) and I change the placeholder flag of the account to True, I still
can add new transactions/splits. If I close the account and reopen it, then
it is indeed impossible to add new ones.
It could be worth to clarify a little bit the documentation with
A *Placeholder* means this account is not used for *new *transaction data.
*New* transactions may not be posted to this account, only to sub-accounts
of this account not marked themselves as *Placeholder*.
> - once an account has splits, it is still possible to change the commodity
> > of the account (ie we can move from EUR to YHOO stock without any
> > Is it expected behavior ?
> Expected behavior. Countries change currency (adoption of the Euro being
> the most common case, but others include Zimbabwe's adoption of the USD
> after the collapse of their own currency). There's code in the engine to
> recalculate all of the existing splits in the new commodity.
When I change the account commodity in GnuCash, I do not "see" any code
running to propose some currency conversion for the current splits (with or
without trading accounts). Is it normal ? How can I trigger the
recalculation of the existing splits ?
In case of change of currency in a country, shouldn't the old
transactions/splits be kept in the old currency, the new in the new and the
balance, at a given time, changed from the old to the new currency ? (I'm
just thinking out loud...).
Otherwise, how (which FX rate) are converted the old splits in the new
> > - once an account has splits, it is still possible to change the
> > commodity_scu (smallest fraction) of the account (ie we can move from
> > to 1/10). The existing splits are not adjusted to the new commodity_scu.
> > it expected behavior ?
> There are a couple of ways of looking at that. The most accurate
> representation would be that SCU is for display only and all numbers should
> be maintained at the maximum possible precision to reduce rounding errors,
> but that's not always industry practice; some institutions round every
> transaction using a so-called "banker's round" and expect the results to
> even out over time. GnuCash's code is inconsistent in this regard: Some
> operations check the SCU and round to it, others don't. As part of the
> rewrite we should decide on a policy and make sure that we consistently
> apply it.
> > - similarly the "fraction traded" in a commodity (non currency) can be
> > changed even though accounts related to it have already splits that may
> > higher precision that the new "fraction traded". Is it expected behavior
> That's a more general example, with the same answer.
> > - in the security editor, are "symbol/abbreviation" and "display symbol"
> > the same field ?
> No, the latter is a recent change to allow users to select a different
> character for display depending on their local needs. For example, a
> Canadian might want $ to represent CAD and U$ for USD, while someone to the
> south might prefer the other way around.
> so it is only valid for currencies and not commodities ? because in
gnucash 2.6.4, when I changed the symbol on a non currency, it sets it back
to the symbol/abbreviation. On currencies, it adds a slot user_symbol with
> > I was wondering if there was not a set of characteristics of the
> > accounts/commodity that are "write once" (ie, they are defined at the
> > creation of the account/commodity but they can't be modified once they
> > other objects, like splits, relating to them). Is it more or less
> correct ?
> Perhaps there should be but the code doesn't work that way, nor does real
> life: Consider the decimalization of Pounds Sterling or of the US stock
> pricing. If we do adopt a policy that some properties should be immutable I
> think it should
> be absolute rather than dependent upon whether there are instances in the
> database. The latter choice would complicate the
> code for IMO little gain.
> yes indeed, simpler to say it is a write-once/never-change that some more
complex pattern. However, as you pinpoint, it locks down the flexibility as
we never know what can happen...
> John Ralls
More information about the gnucash-devel