AccrInt
This is the definition of accrued interest from a web glossary.
accrued interest
Interest that is due on a bond or other fixed income security since the last interest payment was made. This often occurs for bonds purchased
on the secondary market, since bonds usually pay interest every six months, but the interest is accrued by the bondholders every month.
When a bond is sold, the buyer pays the seller the market price plus the accrued interest, for which the buyer will be reimbursed at the end of
the six-month period. Accrued interest is calculated on a 30-day month for corporate bonds and municipal bonds, and on
actual-calendar-days for Government Bonds. Income bonds, bonds in default and zero-coupon bonds trade without accrued interest.
Here is the function definition as gnumeric has it.
N_("@FUNCTION=ACCRINT\n"
"@SYNTAX=ACCRINT(issue,first_interest,settlement,rate,par,"
"frequency[,basis])\n"
"@DESCRIPTION="
"ACCRINT calculates the accrued interest for a "
"security that pays periodic interest. The @rate is the annual "
"rate of the security and @par is the par value of the security. "
"@basis is the type of day counting system you want to use:
I was thinking that issue should be the date of the last
interest payment, settlement should be the date of the next interest
payment, first_interest should be the date that you are accuring
on, and frequency would be the number of interest payments in the
year.
Re: pre-design-doc budgeting notes [long]
Joshua Sled wrote:
>
[...]
> BudgetCategories [BCats] are the categorical entries of the budget,
> used for both income and expense. They have a name, and probably a
> description. A recurring income or expense, at least, has a frequency
> of recurrence:
>
> enum RecurrenceEnum {
> DAILY,
> WEEKLY,
> BI_WEEKLY,
> MONTHLY,
> QUARTERLY,
> YEARLY,
> };
I haven't read the whole thing, but this caught my eye. I'm wondering
if an enum might not be too restrictive here. You've already missed at
least one frequency that applies to me, to wit, SEMI_MONTHLY. My paychecks
come on the 15th and last day of the month. There are a lot of companies
in the U.S. that use this pay cycle, at least for salaried employees.
Come to think about it, I also have at least one expense that is SEMI_YEARLY:
my auto insurance (November and May on one vehicle, July and January on the
other).
Clark
--
Disclaimer: The opinions expressed herein are mine and not necessarily
those of anyone else. (As if anyone else would want them!)
Internet: [EMAIL PROTECTED] RF: KI7TU
ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
reporting currencies & integrity
Dave, Bill, all, Bill got me to think about the reporting currency & international accounting issues again. Here's a couple of simple proposals that seems to solve the issues that I can think of. Its probable that you've already discussed these, but since I haven't ... :-) Intro: I made changes to the engine to store the "transaction valuation currency" (aka common currency) with the transaction. If this ever gets out of sync with the computed common currency, a warning is printed. As Bill points out, there are deep GUI issues with prpoagating this further. Plan X: -- Store a single global 'reporting currency'. The chart of accounts will use this currency to report account totals. (its e.g. the euro). -- The user is allowed to create transactions whose 'valuation currency' is different than the 'reporting currency'. However, if this is done, then a GUI window pops up with a question "how should this transaction be valued in 'reporting currency'"? User types in some number, lets call it the 'valuation'. This number, the 'valuation', is stored in the price database, (where its specially identified as being a valuation price, maybe by storing the transaction guid with it). When preparing reports, it is used, from then-on-out, to compute the valuation for reports. -- (critical side effect proposal for Bill): for *any* multi-currency transaction/trade, we should store the 'valuation price' (and maybe the transaction guid) in the price database. Why? This allows us to perform the integrity check that Bill has been missing so much. Q: How do we 'know' that a multi-currency transaction balances? A: The 'valuation' is in the price database, and a comparison with that assures us that the transaction balances. And why should we beleive the price database? Because these special 'valuation' prices are auditable, are 'important', are verified by humans, rather than being some random numbers pulled down from yahoo. (A 'valuation price' might even have a 'reconciled' or a 'been audited already' flag stored with it). Plan Y: -- same as above, except we store the 'reporting currency' with each account. (i.e. we do a global search-n-replace of xaccTransGetCurrency to xaccTransGetReportingCurrency. I really, really think this simple name change will clear up lots of confusion). -- Modify GUI as described above. (i.e. as above, we store the 'transaction valuation currency' with the transaction. Only when it is out of sync with the 'account reporting currency' do we insist on a valuation. i.e. the checks that 'IsCommonCurrency()' performs are 'loosened', and the resulting holes pluged with the valuation prices. This allows the elimination of the currency trading accounts. So, how does that sound? It seems to kill two birds with one stone: tbill's 'accounting equation' problem, and the 'currency trading account' problem. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: reporting currencies & integrity
-BEGIN PGP SIGNED MESSAGE- How do your questions relate to the "currencies/the accounting equation" discussion last Sept/Oct? As I understood the current questions only concern the reporting end of the bookkeeping whereas the former discussion was about the back-end structure. Where can I find more information about the "price database"? I haven't found it anywhere in the source. > -- Store a single global 'reporting currency'. The chart of accounts > will use this currency to report account totals. (its e.g. the euro). vs. > -- same as above, except we store the 'reporting currency' with >each account. Anytime you create a report you need a given "reporting currency". Either we ask for it everytime (as a parameter, as in my pnl-report version last fall) or we store one globally. Storing it globally doesn't mean it remains constant at all times, though. Anyway, I think it doesn't make sense to store a reporting currency with each account -- there will always be cases when a report contains accounts with different reporting currencies, so you still have to decide which one to use. Again, you can either ask for it everytime or store one globally. Christian -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBOm3Vd2XAi+BfhivFAQHKxwP/VNOj1aG0AxW+x3FlD20KbfM/xwyBuD89 l4NGQrKNVm/fvGy3l6/JtxGNz3zfP8WtrIXy2zdcJ2mz5U2xU1YpG/XTL/h1Mwpk YjL+9GqgmkQJ/h81I/x9i/8ZhIyD2Uy673dXeuK+eFS2OVOIhCeX0wsvTZdLnMq4 28UcZlt3KUU= =uIo4 -END PGP SIGNATURE- ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Big window in 1.4.9
In the tax-report if you open the window that changes parameters, then that window is way, way to tall. It just fits on my 1152x854 screen and it can not be resized to something smaller.. -- /Dennis ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: pre-design-doc budgeting notes [long]
On Tue, Jan 23, 2001 at 08:52:28AM -0700, Clark Jones wrote: | I haven't read the whole thing, but this caught my eye. I'm wondering | if an enum might not be too restrictive here. You've already missed at | least one frequency that applies to me, to wit, SEMI_MONTHLY. My paychecks | come on the 15th and last day of the month. There are a lot of companies | in the U.S. that use this pay cycle, at least for salaried employees. The "wackiest recurring expense" mail was an attempt to ensure that something simple [like this enum] was sufficient. Actually, I was more curious about the granularity of amount specification wrt recurrance freq [and amount-change frequency]... I was spending far too much time not coming up with a solution for a highly-granular approach I was thinking of. I think this will be fine until I/someone can figure that out, sometime down the road. I should have included this in that doc, but semi-monthly == bi-weekly. Maybe semi-monthly is the right term for it. [My paycheck is that way, as well]. | Come to think about it, I also have at least one expense that is SEMI_YEARLY: | my auto insurance (November and May on one vehicle, July and January on the | other). How silly of me... 6-mo cycles, yes... It will be added. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: pre-design-doc budgeting notes [long]
On Tue, Jan 23, 2001 at 11:09:37AM -0800, Joshua Sled wrote: > I should have included this in that doc, but semi-monthly == bi-weekly. > Maybe semi-monthly is the right term for it. [My paycheck is that way, as > well]. Actually, no. They are different intervals. "semi-monthly" means twice a month, as in many people's payroll: 1st and 15th of the month, for example. "bi-weekly" means every two weeks. There are 24 semi-monthly events a year and 26 bi-weekly events a year. That's a significant difference. b.g. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: pre-design-doc budgeting notes [long]
On Tue, Jan 23, 2001 at 01:28:30PM -0600, Bill Gribble wrote: | Actually, no. They are different intervals. "semi-monthly" means | twice a month, as in many people's payroll: 1st and 15th of the month, | for example. "bi-weekly" means every two weeks. | | There are 24 semi-monthly events a year and 26 bi-weekly events a | year. That's a significant difference. Yup... yes it is. Thanks for the clarification. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: pre-design-doc budgeting notes [long]
Joshua Sled <[EMAIL PROTECTED]> writes: > I should have included this in that doc, but semi-monthly == bi-weekly. > Maybe semi-monthly is the right term for it. [My paycheck is that way, as > well]. Unfortunately bi-weekly != semi-monthly. I've had jobs where I was paid every two weeks, and I've had jobs where I was paid on the 15th and last days of the month. They are not equivalent (one year I wound up with 27 paychecks just due to when the bi-weekly payments fell :) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: reporting currencies & integrity
On Tue, Jan 23, 2001 at 10:22:59AM -0600, Linas Vepstas wrote: > Store a single global 'reporting currency'. The chart of accounts > will use this currency to report account totals. (its e.g. the > euro). I think you are saying 'the Chart of Accounts and reports will use this currency to report monetary values, in addition to the "native" denomination of the value'. If so, I agree. However, that's not a complete solution; you still have to know how to convert the amounts to the reporting currency. To do this correctly, we need to implement at least a subset of the FASB 59 standards for conversion of amounts to a reporting currency and allow the user to select which method they wish to use. In short, for each value in a "foreign" (WRT the reporting currency) currency, you have to decide whether to convert the amount at the current exchange rate, whether to convert component amounts at their historical exchange rate and sum them, or to use a weighted-average exchange rate for the entire reporting period. You need to make this decision on a per-account basis based on the type of the account. > -- The user is allowed to create transactions whose 'valuation currency' >is different than the 'reporting currency'. However, if this is >done, then a GUI window pops up with a question "how should this >transaction be valued in 'reporting currency'"? User types in >some number, lets call it the 'valuation'. This number, the >'valuation', is stored in the price database, (where its specially >identified as being a valuation price, maybe by storing the >transaction guid with it). When preparing reports, it is used, >from then-on-out, to compute the valuation for reports. I disagree with most of this. I think the right approach is to store the valuation in the transaction currency with the split. Right now, each split stores 2 monetary values: the 'damount' denominated in the account's security and the 'value' denominated in the account's currency. What Dave and I were talking about is eliminating the 'currency' from the account, moving it into the Transaction structure, and having each split have a 'damount' (still in the account's security) and a 'value', now in the Transaction's currency. I think the problem you are trying to address with your mention of the reporting currency is how to find values for all these things at report-generation time in terms of the reporting currency. It's a real problem, but I don't think you're making a 100% solution. I agree that we want to make an entry in the price database for any user-specified exchange rates (between Account security and Transaaction currency) but that doesn't really solve the reporting problem, because you could specify after the fact that you want to use a valuation strategy that requires different exchange rates than the ones you enter at the time of the transaction (i.e. you might want to use current-value for all cash assets, and that's value as of report generation time), or in fact a different reporting currency entirely. We'll need the ability to go out and fetch currency quotes for historical dates at report generation time. In any case, if we have a Transaction currency that's not the reporting currency (pretty likely) that means we have to ask the user for possibly two different exchange rates for a single entered value (one for the value of the split in the Transaction currency, one for the value of the split in the reporting currency) and that's way too much to ask. I think all we need to ask is the value in the Transaction common currency, and we figure out the rest at report generation time. > -- (critical side effect proposal for Bill): for *any* multi-currency >transaction/trade, we should store the 'valuation price' (and maybe >the transaction guid) in the price database. Why? This allows us to >perform the integrity check that Bill has been missing so much. I'm not sure what you're talking about here. What integrity check do you mean, and why do you think I'm missing it? (later) Oh, I see. You're talking about the "accounting equation" discussion we had several months ago. I think we resolved that just fine; we have to implement FASB-compliant historical/current valuation policies, and make a report that takes unrealized gains/losses into account as part of the Equity term of the accounting equation. We will never be able to "check" this during normal operation, because generating the info you need to run the accounting equation is more of a pain in the butt than you want to incur for normal operation. It may make sense to have this as a "Scrub" type option. >Q: How do we 'know' that a multi-currency transaction balances? >A: The 'valuation' is in the price database, and a comparison >with that assures us that the transaction balances. And why >should we beleive the price database? Because these special >'valuation' prices are auditable, are 'im
sv.po for 1.4.9
An update of the swedish translation. Small changes only. Most of the tax-report is not translated, it was not there when I did the last translation. But from the short look I had of it, it looks like it's not so important for swedish users anyway. A lot of the things in gnucash 1.4.x is very hard to translate since almost all strings are saved in a single file and one have no idea of the context where the string is used. I took a quick look at the cvs head version and it looks like it have become much better. ps. I forgot if I should have sent the translation to some specific person or not. So I send it here. -- /Dennis sv.po.gz
Re: Big window in 1.4.9
I'll add another "Tab Section" That should reduce the size by aboutr one third. Gilligan Dennis Bjorklund wrote: In the tax-report if you open the window that changes parameters, then that window is way, way to tall. It just fits on my 1152x854 screen and it can not be resized to something smaller.. -- /Dennis ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel -- Gilligan | __o .oooO /| _ \<,_ ( ) /p|\ (_)/ (_) \ ( Oooo. / | \ \_) ( ) ) / [EMAIL PROTECTED] (_/ [EMAIL PROTECTED]
Re: reporting currencies & integrity
Hi Bill, It's been rumoured that Bill Gribble said: > > On Tue, Jan 23, 2001 at 10:22:59AM -0600, Linas Vepstas wrote: > > Store a single global 'reporting currency'. The chart of accounts > > will use this currency to report account totals. (its e.g. the > > euro). > > I think you are saying 'the Chart of Accounts and reports will use > this currency to report monetary values, in addition to the "native" > denomination of the value'. If so, I agree. Yes, that's it. > However, that's not a complete solution; you still have to know how to > convert the amounts to the reporting currency. To do this correctly, > we need to implement at least a subset of the FASB 59 standards for > conversion of amounts to a reporting currency and allow the user to > select which method they wish to use. In short, for each value in a > "foreign" (WRT the reporting currency) currency, you have to decide > whether to convert the amount at the current exchange rate, whether to > convert component amounts at their historical exchange rate and sum > them, or to use a weighted-average exchange rate for the entire > reporting period. You need to make this decision on a per-account > basis based on the type of the account. Yes, that is correct. That is what the FIFO Queue code in the engine was starting to do. I'd hoped that someone would volunteer to write more methods, but no one has. Note that its not just foreign curencies, its also stocks, bonds, and depreciation. The FIFO was meant to be one acceptable way of doing cost-basis accounting to keep the IRS happy. Depreciation schedules are another thing that can be handled that same way as far as the software is concerned. Actually, I'm confused, .. I can't find code that's using Queue.c anywhere, so I am not sure how the ... never mind ... we no longer have a functional cost-basis report ... > > -- The user is allowed to create transactions whose 'valuation currency' > >is different than the 'reporting currency'. However, if this is > >done, then a GUI window pops up with a question "how should this > >transaction be valued in 'reporting currency'"? User types in > >some number, lets call it the 'valuation'. This number, the > >'valuation', is stored in the price database, (where its specially > >identified as being a valuation price, maybe by storing the > >transaction guid with it). When preparing reports, it is used, > >from then-on-out, to compute the valuation for reports. > > I disagree with most of this. I think you misunderstand. > I think the right approach is to store > the valuation in the transaction currency with the split. You could choose to value the transaction in a dozen currencies. You want to store a dozen values with each split? > Right now, > each split stores 2 monetary values: the 'damount' denominated in the > account's security and the 'value' denominated in the account's > currency. What Dave and I were talking about is eliminating the > 'currency' from the account, moving it into the Transaction structure, > and having each split have a 'damount' (still in the account's > security) and a 'value', now in the Transaction's currency. Yes, I have already made this change to the engine. The "transaction valuation currency" aka "common currency" is stored in the "common_currency" field in TransactionP.h. It is not is not really 'used' anywhere, but it is set, and tested, and a warning is printed if it gets out of sync with the "IsCommonCurrency()" routines. > I think the problem you are trying to address with your mention of the > reporting currency is how to find values for all these things at > report-generation time in terms of the reporting currency. It's a > real problem, but I don't think you're making a 100% solution. Re-read the note. I'm proposing several things. One of them is what to do if the "transaction valuation currency" is not equal to the "reporting currency". This is one of the showstoppers for the change-over, as you yourself had pointed out earlier. > I agree that we want to make an entry in the price database for any > user-specified exchange rates (between Account security and > Transaaction currency) Yes, but its not just 'some price', its an explicitly auditable price. I think that's a critically important part of it. > but that doesn't really solve the reporting > problem, because you could specify after the fact that you want to use > a valuation strategy that requires different exchange rates than the > ones you enter at the time of the transaction (i.e. you might want to > use current-value for all cash assets, and that's value as of report > generation time), or in fact a different reporting currency entirely. Yes, but you can scan the data and determine this at report-gen time. > We'll need the ability to go out and fetch currency quotes for > historical dates at report generation time. Sure. > In any case, if we have a Transaction cur
Re: reporting currencies & integrity
Linas Vepstas writes: > > Yes, I have already made this change to the engine. The "transaction > valuation currency" aka "common currency" is stored in the > "common_currency" field in TransactionP.h. It is not is not really > 'used' anywhere, but it is set, and tested, and a warning is printed > if it gets out of sync with the "IsCommonCurrency()" routines. > > > I think the problem you are trying to address with your mention of the > > reporting currency is how to find values for all these things at > > report-generation time in terms of the reporting currency. It's a > > real problem, but I don't think you're making a 100% solution. > > Re-read the note. I'm proposing several things. One of them is > what to do if the "transaction valuation currency" is not equal > to the "reporting currency". This is one of the showstoppers > for the change-over, as you yourself had pointed out earlier. Is this what you are proposing: Account Security stays the same, with the same meaning. Account Currency becomes Account Reported Currency and is the currency used in the main window. Transaction Currency is added and replaces the old account currency/security for determining the common currency of the transaction. split damount == amount in account security, same as before split value == amount in transaction currency > > I agree that we want to make an entry in the price database for any > > user-specified exchange rates (between Account security and > > Transaaction currency) > > Yes, but its not just 'some price', its an explicitly auditable > price. I think that's a critically important part of it. I'm not clear about the prices you propose to store: The price for transaction currency in account security "" reported currency in transaction currency "" reported currency in account security all? others? > > I think all we need to ask is the value in the > > Transaction common currency, and we figure out the rest at report > > generation time. > > ? > Yes, but the 'report generation time' is "right now" (you make it > sound like its the distant future or something). The main gnucash > window is a kind of report. When I get done with entering the > transaction, I expect the main window to instantly update & reflect > the new value. So that GUI popup is gonna pop up anyhow, anyway, > in fractions of a sub-second. I'm not sure that I care if its the > 'register' that caused it to happen, or the 'main window'. I think we should care, because transactions can be entered in several different ways: Register Transaction Dialog QIF Import One day that may include: OFX download Scheduled Transactions Palm Pilot Sync etc. In particular, bulk imports like QIF will be a challenge since there could be thousands of transactions to value. > You are free to argue back that this idea is overkill. But it does > solve the accounting equation problem of 'how do I know that the sum > of the splits ==0 when the splits are in different currencies'. I thought that was the purpose of the transaction currency. Is that still the case? Is this how it will work: A transaction is balanced and 'integrity checked' if the 'value' members of the splits sum to 0 and, for each split, the value member equals the damount member multiplied by the price stored in the database for that split. > I assume that means you prefer Plan X to Plan Y. > > In plan X, there is one (or a collection) of globally-applied > reporting currencies. In plan Y, there is one (or a collection) > of reporting currencies stored with each account. > > Plan Y is essentially how gnucash works today. > > I claim that Plan Y has a certain advantages, but this email is long > enough already. So you are proposing Plan Y *in addition* to the ability to specify a single currency for a given report? dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: pre-design-doc budgeting notes [long]
Joshua Sled wrote: > > On Tue, Jan 23, 2001 at 08:52:28AM -0700, Clark Jones wrote: > | I haven't read the whole thing, but this caught my eye. I'm wondering > | if an enum might not be too restrictive here. You've already missed at > | least one frequency that applies to me, to wit, SEMI_MONTHLY. My paychecks > | come on the 15th and last day of the month. There are a lot of companies > | in the U.S. that use this pay cycle, at least for salaried employees. > > The "wackiest recurring expense" mail was an attempt to ensure that something > simple [like this enum] was sufficient. Actually, I was more curious about > the granularity of amount specification wrt recurrance freq [and amount-change > frequency]... I was spending far too much time not coming up with a solution > for a highly-granular approach I was thinking of. I think this will be fine > until I/someone can figure that out, sometime down the road. I didn't consider any of my periods "wacky", so I didn't respond. Mine are all pretty standard. > I should have included this in that doc, but semi-monthly == bi-weekly. > Maybe semi-monthly is the right term for it. [My paycheck is that way, as > well]. WRONG!!! They are NOT the same. Semi-monthly == 24 times per year. Bi-weekly == 26+ times per year. On Semi-monthly, you ALWAYS have _EXACTLY_ two per month. Some periods will have 16 days, some will have 15, and (typically) one per year will have either 13 or 14 days (depending on leap year). On Bi-weekly, you ALWAYS have _EXACTLY_ 14 days per period. Most months will have 2 periods, but at least two months per year will have 3 period ends. Once in a while, a year will have 27 periods end in it, meaning that there will be three months with three periods ending in them in that year. You might also want to add a "RANDOM"... my irrigation water account has to have at least enough money in it to cover the water I want -- I get water on a 13 day cycle (_that's_ bizzare), and sometimes I need $7 worth, sometimes $9, sometimes $12, and sometimes other values -- it literally depends on the weather and time of year (I haven't used any since about October). When the account gets down to about $10, I usually send the supplier a check for $50. Is it a "recurring" cost? Yes. Is it a predictable one? No, though if you looked at it over several years you might see a reasonable average value per year. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: reporting currencies & integrity
-BEGIN PGP SIGNED MESSAGE-
> Lets say that our 'reporting currency' is USD. Lets say we live in
> france, and we bought IBM stock with FF. The user types in the
> shares bought, and the FF paid. (that's our first 'exchange rate').
>
> When user clicks on 'commit', a little GUI dialoge pops up, and says
>
> 'To correctly report this transaction in the main window account
>summary, we need to know the value of this transactin in USD. The
>last exchange rate we know of for USD is xx.yy FF per USD, which
>would value the transaction at $zzz USD. Use this exchange rate, or
>edit?'
I disagree. Instead I agree with Bill's three FASB59 methods. Which means
in this example: The user types in the shares bought, and the FRF paid,
and clicks on commit. That's it for the user -- no extra dialog is
necessary.
But at some point in time before, the user clicked on "Settings" -
"Currencies" and chose the "report currency" (say, Swiss Franks CHF) as
well as one out of three "methods to convert amounts to report currency".
This method determine what gnucash will do after the above transaction is
entered:
1) "convert the amount at the current exchange rate". Then gnc-prices will
be started to fetch the current price of IBM. This price might be in EUR,
so gnc-prices will also get the rate EUR to CHF (that one might
already be cached). The resulting price will be displayed. Note that the
result will not at all be stored anywhere; it is only for displaying
("reporting") purposes. Also note that the displayed value of the IBM
assets might change pretty soon, depending on the price update interval,
but almost surely on every new business day.
2) "convert component amounts at their historical exchange rate" Let's
assume that somewhere in the WWW there is a stock ticker which gives you
not only the prices for right now but also for any point back in history.
Then the actions under 1) will be performed by querieing that stock ticker
with the day of the above transaction. If there is no such stock ticker
those prices will have to be stored somewhere in gnucash and it remains to
be discussed where. Note that the displayed value of the IBM assets will
never change unless there is a new transaction with IBM shares.
3) "weighted-average exchange rate for the entire reporting period" (At
least that's how I would understand it: ) Let's assume that you didn't own
any IBM shares before. Then the price ("exchange rate") from IBM to FRF is
taken exactly from this transaction and you (the reporting code) has to
get from FRF to CHF. Let's further assume that the whole book began with
CHF, that is, there is only one equity account and it is in CHF. To own
any FRF at all you probably at some point in time have bought FRF for CHF,
e.g. you bought FRF 400 for CHF 100 and at a later point you bought FRF
1000 for CHF 200. Gnucash then builds the weighted average over all
CHF-FRF transactions and comes up with an exchange rate (e.g.
(400+1000)/(100+200)=4.66). By this means the report can calculate the
value of the IBM shares in the current report currency. Note that the
displayed value of the IBM assets will change everytime you buy more FRF
for CHF.
Recall that the "reporting currency" can be changed anytime (= I agree
with Bill on this). I disagree with Linas in that accounts should have a
"reporting currency". Reports show many accounts but they need one "report
currency" to give one single number at the bottom line. If you mean two
different things here then don't give them the same name.
I repeat my question from today afternoon: Where can I find more
information about the "price database" that you're talking about? I haven't
found it anywhere in the source. Or what kind of database do you mean,
Linas?
Christian
-BEGIN PGP SIGNATURE-
Version: 2.6.3i
Charset: noconv
iQCVAwUBOm53t2XAi+BfhivFAQFuEgP8Dl5wo5blikUG02s8fVQMgOUMfrQu7GLy
ZK6yE2eBugk6KSCC5h0Azr7+RHnYQJddr1tHE0oquTxWOi0fjjPsxS4oAUkej7KP
NxQlIF+rmo5dqWyOkCpXx2/OxEr8rt4Ed9fL6EKPbv9J4rKXQzMoT18+6DkeAJGO
tVN1WMlhPR4=
=0zo+
-END PGP SIGNATURE-
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: reporting currencies & integrity
Christian Stimming writes: > > I repeat my question from today afternoon: Where can I find more > information about the "price database" that you're talking about? I haven't > found it anywhere in the source. Or what kind of database do you mean, > Linas? It's not anywhere in the source, it doesn't exist yet. We are just getting around to making it. As you know, GnuCash currently stores prices in actual splits stored in accounts. We want to move away from that to storing prices separately from accounts -- hence the 'price db', where 'db' is used in a general sense, no sql implied. We plan on using the price db to record historical stock & currency prices. They will be used for reporting and graphing purposes. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: reporting currencies & integrity
On Tuesday 23 January 2001 17:59, Dave wrote: > Is this what you [Linas] are proposing: > > Account Security stays the same, with the same meaning. [1] > > Account Currency becomes Account Reported Currency and is > the currency used in the main window. [2] > > Transaction Currency is added and replaces the old > account currency/security for determining the common > currency of the transaction. [3] > > split damount == amount in account security, same as before > split value == amount in transaction currency [4] To remind the reader of the results of last fall's debate about currencies I dug out Bill's summarizing mail. Maybe that can be added as gnucash/src/doc/currencies.txt . Note that those proposals recommend [1], [3], and [4], but do not include [2]. From Bill Gribble <[EMAIL PROTECTED]> Tue, 3 Oct 2000 11:09:54 -0500 We need to fix a single way of dealing with this that addresses all of the concerns. Maybe we should list the problems/requirements to make sure we are talking about the same thing. I know I've repeated several times that I believe the "eliminate Currency accounts" problem-set is separable from the "global A=L+E" problem-set; I'll list them all together here, because I think it's just a "feature" of some particular solutions that they are separable. - we want to eliminate the need for currency trading accounts. From a user interaction perspective, this means we need to allow transfers directly between accounts denominated in different commodities. - we want transactions to have clear and unambiguous balancing semantics. - we want to store the actual amounts of commodities involved transactions rather than price and quantity. - we want to be able to globally check and display the terms of the accounting equation (and all account balances) in a user-selectable functional currency. I think the following bits will address the first three issues above. Basically I'm just agreeing with your last suggestion, Dave; Rob and I hammered on it on a white board and weren't able to poke any holes. - Eliminate the 'currency' from the Account structure. Add a 'currency' to the Transaction structure. Each transaction's 'currency' is by definition the balancing common currency for the splits in that transaction. - 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 balancing semantics of this approach are unambiguous, no existing balanced gnucash transactions would be disallowed (the transaction's common currency just gets saved in a pointer) and the fuzzy distinction between the account's currency, security, damount, value is cleared up. About the last point, the global accounting equation. Evaluating this equation requires the computation of current asset values and unrealized gains/losses. I believe this is possible in a straightforward way using the reporting framework, a user-selectable functional currency, accepted accounting policies, and a historical price database. There has been discussion about moving to a report-based main window; if that were to be the case, we could make the accounting equation readily visible to the user.
