> On Dec 29, 2014, at 12:35 PM, Sébastien de Menten <[email protected]> wrote: > > On Mon, Dec 29, 2014 at 6:36 PM, John Ralls <[email protected] > <mailto:[email protected]>> wrote: > > > On Dec 29, 2014, at 7:17 AM, Sébastien de Menten <[email protected] > > <mailto:[email protected]>> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
