On Mon, Dec 29, 2014 at 6:36 PM, John Ralls <jra...@ceridwen.us> wrote:
> > > On Dec 29, 2014, at 7:17 AM, Sébastien de Menten <sdemen...@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 ? 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 currency ? > > > - 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. > > > > 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... Regards, > John Ralls > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
