some questions on accounts/commodities

John Ralls jralls at ceridwen.us
Mon Dec 29 16:06:04 EST 2014


> On Dec 29, 2014, at 12:35 PM, Sébastien de Menten <sdementen at gmail.com> wrote:
> 
> On Mon, Dec 29, 2014 at 6:36 PM, John Ralls <jralls at ceridwen.us <mailto:jralls at ceridwen.us>> wrote:
> 
> > On Dec 29, 2014, at 7:17 AM, Sébastien de Menten <sdementen at gmail.com <mailto:sdementen at gmail.com>> wrote:
> >
> > 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 in
> > 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 warning).
> > 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 ?

I know that I’ve seen code for handling the change, but I’ll have to study the code sometime to find the execution path. You might have to run “check and repair”.

> 
> 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…).

Maybe, but the only way GnuCash would be able to handle it with the current design is for the user to create a new account with the new currency and transfer the balance from the old one.

> Otherwise, how (which FX rate) are converted the old splits in the new currency ?

The government will generally specify a conversion rate. 

>  
> 
> > - once an account has splits, it is still possible to change the
> > commodity_scu (smallest fraction) of the account (ie we can move from 1/100
> > to 1/10). The existing splits are not adjusted to the new commodity_scu. Is
> > 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.
> 
> ok 
> > - similarly the "fraction traded" in a commodity (non currency) can be
> > changed even though accounts related to it have already splits that may use
> > higher precision that the new "fraction traded". Is it expected behavior ?
> 
> That's a more general example, with the same answer.
> 
> indeed 
> > - 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 the symbol.

Yes, currencies only. There’s no codepoint for a symbol for YHOO, and it would be a bit weird to assign one.

> >
> > 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 have
> > 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…

Not really. Here the benefit would be that if a commodity’s immutable changes and one hadn’t used that commodity already, one could modify the commodity instead of deleting it and making a new version. That’s a pretty small benefit considering the complexity implementing it would require.

Regards,
John Ralls


More information about the gnucash-devel mailing list