Wm, I must admit I don't use trading accounts much at present. I'll check out how they handle it.
I take your point on the difference between amounts entered in a transaction as distinct from the value at a specific point in time in a balance sheet or even TB. you would want recording aof a transaction to record the amounts debited and credited to accounts as the values involved in the transaction and not be subject to any sort of updating of their value with a change in the price database. The amount recorded as the price in the transaction price field should be calculated from the entered amounts and not from a value in the price database, at least unless the person entering the transaction specifically requests that a current on-line price or price from the database be used explicitly. If it was used an extra confirmation from the user that they are aware of the implications might be in order. I don't think this is what Alex was proposing. My reading of a use case he might be trying to address is that in a case of a multisplit transaction where more than two foreign currency accounts were involved, the balance condition for the transaction would be checked in the book currency. I will have to check the data structures but I think from a brief look some time ago there is only one price associated with a transaction, whereas if what Alex is proposing is what I think he is, it would require a price from the currency of the account the split is to to the register account currency to be associated with each split to enable that transaction balancing to occur. Ideally I would think a transaction should not be specifically associated with any specific account other than through the splits to the accounts. I think that is the case in GnuCash but I haven't explicitly checked the code but a single price for a transaction if that is the case may break that. Geert, John or Derek may be better able to comment on this If you are recording a change in asset value in the register there should be a specific transaction to do that. No problem perhaps for a report, but even then I would always prefer to know explicitly the basis for any difference between what is in the register and what appears in a report, i.e. it should be part of the report. I think we all have a tendency to think the whole world runs the way things are run in our local environment until we experience a situation that disabuses us of this false notion, usually travel. I can't say that my experience of the GnuCash development team indicates that that this particularly a problem. When something new is developed it is likely to at least initially reflect what the developer is most familiar with and it requires wider input to then generalize it to other requirements. GnuCash is not a commercial effort where there is a definite financial incentive to provide adaption to different jurisdictions so it gets down to individual motivation and enough users with some development skill taking on the tasks to do that adaption. That unfortunately is not that easy. I found it very difficult to get to the point where I could even begin to develop any code. My wife (who was the daughter of a USMC second lieutenant) but was brought up in Australia is much tougher than I am on US cultural imperialism. Unfortunately we are faced with governments being unnecessarily prescriptive about how things should be done in cases where they have minimal expertise. Making Tax Digital is a case in point in the UK. I am hoping the ATO here does not catch a case of the HMRC bloody mindedness as we still have a fall back to a web portal into which we can cut and paste the required information. David Cousens David Cousens ----- David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
