<cstim> goonie: well...
<goonie> How about this:
<cstim> goonie: You can print each value as a gnc-monetary goonie: this?
<goonie> cstim: don't worry, go on with your outline.
<cstim> How are you printing balances right now? I guess you plug a gnc-numeric into the html code. If you do a s/gnc-numeric/gnc-monetary/ ... then everything would be multi-currency compliant Of course the gnc-monetary needs the actual currency specified. Would that lead to problems? Definition of gnc-monetary is in src/scm/gnc-numeric.scm
<cstim> Right now every gnc-monetary is printed like $500.23, DEM 123.45, CHF 456.32
<goonie> I think that should work fine.
<cstim> but the formatting of gnc-monetary could be modified by any style sheet.
<goonie> You also had some code for calculating totals in multiple currencies?
<cstim> goonie: ouch. Yes. But that gets complicated quickly.
<goonie> Yes, it does.
<cstim> goonie: You will need to use a commodity-collector from report-utilities.scm
<goonie> OK, cool, I think I can figure it out.
<cstim> If you want the total of only one commodity, you can use the 'getpair action of commodity-collector... but if you want to show (correctly) all of the currencies, you will have a lot of trouble. Basically, I have the "reference implementation" in html-utilities.scm .
<goonie> OK, excellent.
<cstim> You can see how I print just one balance... in the big function gnc:html-build-acct-table, line 297, where I print the total sum. That would be a starting point to see how a balance with a bunch of commodities gets printed.
<goonie> cstim: taking it up a level for a second, how would you prefer a total for a collection of splits in different currencies to be displayed?
<cstim> what do you mean by "total for splits"?
<goonie> OK, consider a transaction report for the account Expenses:Beer for the period 1/1/2001 to 2/1/2001 (UK date format ;) and let's say I've had beer in Australia, the US, Germany, and Hong Kong during that period. further, let's assume that my "native currency" is AUD. cstim: try some of the Australian specialty beers.
<goonie> cstim: but even VB or Carlton Draught is an improvement on soap suds . . . er, Budweiser. but back to Gnucash matters . . .
<goonie> now there's several possibilities for doing the totals here . . .
<cstim> wait wait what accounts and what splits are you thinking of? or in other words, what are your sorting/account/viewing parameters?
<goonie> Only one account selected, sorted by date, say (we'll discuss subtotals in a sec).
<cstim> goonie: One account means that there is only one currency, right?
<goonie> dave_p: hang on, let me just check . . . s/dave_p/cstim
<goonie> dave_p: what's the status of currency-in-transaction?
<goonie> nope, really dave_p this time :)
<cstim> dave_p is away: I'm doin' stuff AFAIK an account has a commodity and a transaction has a commodity.
<cstim> gnc:account-get-commodity, gnc:transaction-get-commodity
<goonie> However, read the comments in TransactionP.h
* The common_currency field indicates the currency type that * all of the splits in this transaction share in common. This * field is going to replace the currency field in the account * structures.
<cstim> yeah, that's right.
<goonie> So, in the short term, your assumption is correct. In the long term, not the case.
<cstim> What I would usually call the "currency" of an account is in Gnucash acctually called "security". gnc:account-get-commodity will return this security of the account.
<goonie> Gotta love terminology. The reason for the differentiation is for stock/mutual fund accounts, if I recall correctly.
<goonie> Yep, so the situation I described above can't happen right now, but will be possible in the near future. Which brings us back to how should we display things: A total for each currency.
<cstim> What account would that be?
<goonie> The account Expenses:Beer.
<cstim> What security will it have?
<cstim> go ahead
<goonie> OK, say that there's only four transactions in that account for the period in question: $2 in AUD, 5 USD, 1 EURO, and 12 HKD being the values. What should we display as the total(s)? Or more to the point, what options do we need to offer?
<cstim> waitwait. Expenses:beer has security AUD. So there is one Transaction between Cash:USD and the beer. And one between Cash:Euro and the beer. And one between (what the heck is) Cash:HKD and the beer.
<goonie> Hong Kong Dollar, BTW.
<cstim> And, say, those Transaction have the transaction-commodity according to the Cash:*
<cstim> But the split which belongs to Exp:Beer has only one value and that value represents the beer expense in AUD. i.e. in the split's account's security.
<goonie> hang on . . . let me think this through carefully . . .
<cstim> ok, lets get things straight: Each split has two fields, value and damount Quote from a grib posting last October:
- Eliminate the 'share price' field from the Split structure and replace it with a 'value' field. The 'value' is a translation of the Split's 'damount' (which is the amount of the Account's security involved) into the Transaction's balancing currency.
the last sentence is the one that matters.
* value is the amount of the account's currency involved, * damount is the amount of the account's security. For * bank-type accounts, currency == security and * value == damount. gnc_numeric value; gnc_numeric damount;
from src/engine/ TransactionP.h
<cstim> that's outdated. In the long run: value is the amount of the transaction-commodity involved, damount is the amount of the account-commodity involved.
<goonie> OK, but the value returned from gnc:split-get-value is the value rather than the damount. sorry for the long delay, I was reading code to make sure I understood what was going on. value being the one denominated in the transaction-commodity.
<cstim> That's right. gnc:split-get-value gives you the value, whereas gnc:split-get-share-amount gives you the damount Maybe that functions need some name change in the future.
<goonie> perhaps. the trouble is that there are so many things that need names in gnucash, that you start to run out :)
<cstim> :) We could gnc:split-get-share-amount => gnc:split-get-damount whatever. My point for the Beer is let's have some.
<cstim> oops. I would expect that the transaction report uses gnc:split-get-share-amount which in this case gives you already the amounts exchanged into AUD and everything's fine.
<goonie> You would prefer that over the transaction-specific value, then?
<cstim> Well, if I want the list for one specific account, then I would expect all amounts to be in that account's commodity, i.e. the account-commodity (formerly known as security :)
<goonie> yep. But then the problem just arises in a different light if you have multiple accounts, sorted by date, say.
<cstim> I would recommend a name change for gnc:split-get-share-amount. multiple accounts. okay, let's talk about that. what scenario do you think of?
<goonie> cstim: could you mail Dave wrt function renaming?
<cstim> I'll send a mail to the ML
<goonie> OK, let's say you've selected Expenses:Champagne (in Francs), Expenses:Saki (in Yen), and Expenses:VB (in Aussie dollars), and you want a report for all those transactions for the past month, sorted by date. You have Cash:Francs, Cash:Yen and Cash:Aussie accounts with the expected currencies.
<cstim> what's VB?
<goonie> Victoria Bitter (Australian Beer).
<cstim> okay. well...
<goonie> If you want a distinctively Australian Alcoholic beverage, s/VB/Sparkling Red
<cstim> Lets have some. ( goonie offers cstim a glass of fine Rutherglen sparkling red. ) Transaction report: but it doesn't make much sense to show a total sum for that anyway, does it_ s/_/?/ oh well, it might.
<goonie> Option 1) display a total for each currency in the report.
<cstim> exactly. Option 2) shows the total for only one currency, the report-currency. Option 3) somehow gets the right exchange rate so that it also ends up with only one total. I'd recommend option 2 for now. For option one you basically would have to copy the code out of the html-build-acct-table function cited above.
<goonie> So, what happens to transactions not in the report-currency in option 2) - they aren't totalled?
<cstim> Maybe with the tons of comments it is do-able goonie: yes, they dissolve in heat and aren't totalled.
<goonie> OK, I think I can implement 1) and 2). 3 (which might have to be split into 3a, 3b . . . ) can probably wait. Well, I could implement a "quickie" 3a that just grabs a current exchange rate and does the conversion on it.
<cstim> again, for 1) you "just" have to copy ~100 lines of code from html-utilities.scm and adapt them to your table structure.
<goonie> that has all sorts of problems, but might be useful if taken with a grain of salt. OK.
<cstim> oh, a quick 3) costs you about 5 lines of extra cost.
<goonie> I think I can cope with that :)
<cstim> just look into pnl.scm and see how they (i.e. I) use gnc:make-exchange-alist and gnc:make-exchange-function both from src/scm/commodity-utilities.scm
<goonie> OK, cool. Thanks for your help.
<cstim> what did you mean by "quickie" 3a that just grabs a current exchange rate " a dialog box? a parameter? gnc-prices?
<goonie> gnc-prices. or a parameter. something other than digging through a bunch of historical data trying to figure out what the exchange rate was at the time of particular transactions.
<cstim> parameter: Bad. gnc-prices: Goood. I'd be happy if someone could implement that to augment the current code in commodity-utilities.scm Oh, the exchange rate at the time of a particular transaction is easy – that's just the fraction value/damount .
<goonie> not always - what if the transaction is (say) yen/yen but you want to display in dollars? for instance, our glass of saki, paid for in cash yen.
<cstim> Yes, right. currently the commodity-utilities stuff uses a weighted average over the history. But using the last known exchange rate instead may be useful at times. Maybe I'll implmement something like that maybe if i have time :)