some questions on accounts/commodities
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. - 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 ? - 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 ? - 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 ? - in the security editor, are symbol/abbreviation and display symbol the same field ? 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 ? kr sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: some questions on accounts/commodities
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. - 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. - 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. - 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. - 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. 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. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: some questions on accounts/commodities
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
Re: some questions on accounts/commodities
On Dec 29, 2014, at 12:35 PM, Sébastien de Menten sdemen...@gmail.com wrote: On Mon, Dec 29, 2014 at 6:36 PM, John Ralls jra...@ceridwen.us mailto:jra...@ceridwen.us wrote: On Dec 29, 2014, at 7:17 AM, Sébastien de Menten sdemen...@gmail.com mailto: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 ? 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
