Hi, caution: very long note. that, and I was rather irritated as I wrote it.
> > > Assets > > > Cash > > > COI > > > > > > Income > > > RG(L) > > > > > > Account Debit Credit Bal > > > ------------------------------------------ > > > Cash 100 100 > > > COI 100 100 <--- 10 shares @ $10 > > > ------------------------------------------ > > > RG(L) 100 100 > > > Cash 200 100 <--- 10 shares @ $20 > > > COI 100 0 > > > > > > In the above, the number of shares and the price/share is ancillary > > > information, and properly belongs in the Lot attributes. Therefore, in > > > our "Stock" accounts, we should be tracking the currency amount instead > > > of the number of shares. The above example misrepresents how gnucash currently works. A transaction indicates a 'balancing currency', which is used to value all of the splits to determine if the transaction balances. It is non-sensical to talk about 'balance' without indicating what the balancing currency is. Stock accounts *must* count the number of shares in the account. When a trade is performed, you are selling one type of object (a stock) for another type of object (dollar bills). What you must count is the number of objects. Value is gained/lost in the fluctuation of the exchange rates. Value is determined by expressing all quantities of all objects in one common currency. > > The problem with this model is that while you can easily track the > > gains/losses, you cannot track the "current value" of your holdings. Huh? the current value of your holdings equals the number of shares times the current price. value = quantity * price. The quantity of shares that you own is the balance of the account! That's what the words 'current balance' mean! > > At no time can you easily determine "I own N shares of XXXX", because > > that information is stored throughout the dataset. Maybe I'm quoting out of context, but this statement, taken out of context, is insane. I can determine that I own N shares of XXX because that is what the current balance of my account is. Determining the balance isn't always easy, especially after a large number of transactions. But this is exactly *why* one does accounting, and uses accounting programs: to determine the current balance of an account. There is no other way; one fundementally cannot make a categorical assertion as to the balance. (Other than 'possession is 9/10ths of the law' ;-) > I do seem to recall seeing, however, a complaint in a comment somewhere > about not being able to use C++, but the author was still intent on > proper opacity of object. =P There really isn't a reason we couldn't > subclass the Split entity into a StockSplit entity, or similar. That ?? This is off topic. Gnucash doesn't condon C++ style subclassing because C++ subclassing is a massive headache for the writers of the storage backends, never mind for the writers of the scheme reports. We provided the key-value pair mechanism precisiely to avoid the problems of C++ subclassing. > Another possibility is to calculate checkpoints much as the the PG > back-end does. The balance checkpoints are an SQL performance hack. The 'normal' way to compute the current account, based on generall accepted accounting principles is to take the opening balance, and to add/subtract the value of all transactions since then that affected the account. This gives you the current balance. Then, once a month, or once a quarter, one audits one's accounts, checks to make sure that the balance is correct, and then once 'closes the books'. The act of closing causes the balance to be recorded in a permanent way: it then becomes the 'opening balance' for the next book. Closed books mustn't be modified because that would screw up the opening/closing balances. By closing one's books every now and then, one can make sure that one doesn't have to zum a gazzilions transactions to determine the account balance. The PG backend 'checkpoint' is just a cheesy way of determining intermediate balances for performance reasons. The correct solution is to implement books, and allow them to be closed & etc. according to normal accounting principles. > Or extend the Lot instead of the Split (probably an > easier direction, but I haven't looked at it too hard). Create a > StockLot, and InventoryLot, etc. The Lot has some basic functionality: > extend it. That's one of the key principles in OO A & D. No. This is one of the key reasons why languages like C++ are broken. This is off-topic, but important to understand. Things like the OFX DTD define a set of 'classes'. If you mirror these classes in C++, then you have quick-set concrete: if OFX ever changes, then you have to recompile and reinstall a million clients, all on the same day. This makes for a very very fragile infrastructure. This is why people who do distributed client-server programs have invented things like 'Any' and 'DynAny' and object factories and ASN.1 and XML and the like: you avoid defining your classes at compile time; instead you define your classes at run-time, as best as you reasonably can. (This is one reason why the first gnucash ofx implementation was a bad idea: it created hundreds of compile-time C++ classes. It took a while before I really came to terms with why this was unmangegable.) > you do. The values used in net worth should be based on the recorded > purchase cost, plus or minus any adjusting transactions for unrealized > gains (loss). I don't get this. How do you plan to record a transaction for unrealized gain? > > Similarly, what you are asking for necessarily requires you to define > > a common currency for ALL your accounts. If you want to express your net worth in dollars, you must have a way of valueing *all* of your possession in dollars. This means both having a price on hand for every object, *and* declaring a 'common currency' for that *report*. Different reports may declare different common courrencies. This is a report issue, not an accounting issue. > You could have an account per exchange, I guess, and record figures in > the currency of the exchange. Multi-currency will always be an issue > regardless of the discussion at hand. Huh? From the accounting persopective, there is *no* difference between widgets, stocks and currencies. You merely count how many widgets, stocks, currencies you own. And this is how gnucash works. We simply use the word 'currency' as a convenience term: a currency is a widget that other people are willing tto accept as a payment of a debt. By convention, it is paper money issued by governments. > I had thought that there was some > effort being put toward a way to transfer money between accounts of > different currencies. The problem in gnucash with currencies was not in the accounting thereof, but in how the general ledger window displayed things. The multi-currency GUI needs work. In much the same way as the multi-stock general ledger needs work. > always have to deal with cross-currency transactions. In the gnucash accounting subsystem (the engine), cross-currency transactions are dealt with in *exactly* the same way as the sale of stock or widgets or any other items. Its just an exchange of N objects of type A for M objects of type B. This is the way it should be, and it shouldn't be changed. > > It means you have a "can't get there from here" issue, which means the > > register would have to be currency-aware and only allow you to make > > transfers across a common currency. Well, yess, in way, the register needs to be currency aware. The currenct registers still display things wrong or non-intutitely in many cases. Its one of those things that have been irritating me for a long long time. > > A Currency account would be > > "special", No. > > in that the transaction can be denominated in "either" > > currency. Transactions have only one 'currency', and one or more commodities. For example, I can trade N objects of type A for M objects of type B, and value the transacation in currency C. Niether type A nor type B need to be type C, although they may be. The types of A and B are recorded in the repsective accounts. The account can only hold objects of types A,B, ... The currency C is recorded in the transaction. There do not have to be any accounts that actually count type C. Type C is only used to declare the balancing currency for the transaction. For simple transactions, C is not needed and is irrelevant, but there are more complex transactions whose *valuation* would be ambiguous, which is why the currency type C must be recorded with the transaction. WhenI say *valuation*, I mean 'quantity' * 'price'. You can express the value in units of A, B or C. Certain rare, complex transactions require that the value be computed in C first, and then converted (by prices) to A and B. > > A stock account would still only be allowed to have > > transactions denoted in its currency. Stock accounts do not have currencies. This is an old and broken pradigm left over from gnucash-1.2/1.4 which is supposed to be eradicated real soon now. > > Well, Linas had lot's "done" for a while. I fixed a couple of bugs in > > them, but they are there and have been for a while. They just aren't > > being used by anything except A/R and A/P invoice/payment tracking. The next missing piece was to create the FIFO's, LIFO's and/or other accouting depreciation scehdule, etc. machines so that realized gains/losses & depreciation could be computed. (and so that books could be closed). The third missing piece is the GUI to deal with this. I have a pretty clear idea of what the FIFO's need to be like; and I think I can impement thim in under 40 hours of work. I have not really thought about what one needs/would like to have for a GUI. There's a *lot* of gui work, potentially, for dealing with opening/closing of books, selecting dprecation schedules, selectiong FIFO or LIFO accounting, etc. etc. etc. The GUI is the hard part. > > stock portfolio is NOT inventory. With inventory you want to know how > > much you paid for your assets, and subtract out depreciation. But Lots are designed to handle depreciation. That is one of the reasons they are there!! > > The reason is that there is not a 1:1 mapping of > > purchases and sales. The whole point of lots, and of FIFO's, is to deal with the fact that there is *not* a 1-1 mapping of sales and purchases. This is *exactly* the problem that lots are designed to solve. > Each transaction should be balanced monetarily. This is possible if you > track the balance in currency instead of shares, and track the purchase > cost vs. today's volatile market price. Which balance? the account balance or the transaction balance? the account balance is always expressed in shares. The transaction balance is always valued 'monetarily', in the transaction currency. The GUI register should show balances in *both* shares, and in some arbitrary currency R, the 'reporting currency'. Currency R has nothing to do with the currency C that a transaction is balanced in (although both will probably be dollars for americans.) (By contrast, C may be dollars for mexicans trading on the NYSE, but R will be pesos.) Lots and fifo's deal with the purchase-cost vs. today's price conundrum. > Record the number of shares and > price as we do now, and offer a warning if price * share != > debit/credit. ??? why is this a warning?? This is eactly the definition of unrealized gain/loss ! > > Now, let me show you how this looks from the LOT view. In paricular > > the Lot view has the following splits: > > > > (type) amt val (amt-bal) (val-bal) > > buy 10 $100 10 $100 > > sell -5 -$150 5 -$50 > > (gain) 0 $100 5 $50 > > > > The (new) invariant of a Lot is that it is "closed" when both the > > sum-of-amount _AND_ sum-of-value is zero. That way you know it is > > closed when you've accounted for all the shares _AND_ all the > > gain/loss. Yes, exactly. Except you didn't show the lots in the above example. The original buy of ten shares went into two lots: 5 shares into lot #1 and 5 shares into lot #2. There are were 5 shares removed from Lot #1 in the sale, and a realized gain made, and so Lot #1 is now closed. There are still 5 more shares in Lot #2, which is still open. Lot #2 has an unrealized gain, depending on todays prices. > > If we do it this way, then: > > > > a) you get your gain/loss split > > b) I get my "net value" and holdings balance > > c) it does not require a major architectural shift in the way gnucash works. yes, exactly. > > This would require two minor change to lots. First, you need to > > enforce that all transactions within the lot are denoted in the same > > currency. Umm, uhh, gurgle, yes, lots need to double-balance. But I this reminds me of an earlier problem that we had ... > This will always be a problem, at least until *everybody* is using the > same currency *everywhere*. No, one merely need to have registers, ledgers and reports know what thier 'reporting currency R' is. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
