On Thu, 2003-01-09 at 11:23, Derek Atkins wrote: > Matthew, Conrad, > > First, I should point out that it was Linas that first suggested Lots, > and indeed, Linas wrote the (current) code for Lots. I'm just the > only one using them -- indeed I use them to track A/R and A/P. An > invoice is put into a lot, and then payments are applied to that lot. > In this manner I can tell when an invoice has been paid. But credit > should go to Linas, not I, for Lots.
Indeed. OK. Well, they are *still* a great idea! ;) With a little extension, perhaps, they would be even more useful. > > Matthew Vanecek <[EMAIL PROTECTED]> writes: > > > come to as well. That conclusion is that we should be tracking the > > dollar amounts of securities, relegating the quantities to an ancillary > > position (e.g., part of a Lot). > > There is a clear tradeoff here. Which do you want to be easier to > see, the current dollar-value of your holdings or your realized > gains/losses? The problem is that when you track the dollar-amount of > stock transactions you have to perform a lot of work to determine how > many shares you currently own. That means calculating Current Net > Worth is a lot of work. > I want to have a clear view of realized gains (loss) in my accounts. The current dollar value of my holdings fluctuates hourly, in the current economy. Sometimes minutely. Current value of securities should be calculated in a report. Recorded value of securities should be fairly static. Except in the case of other than temporary changes in value, of course, in which case an adjustment should be made and the offset recorded in UN-realized gains/losses. The value of a purchase should never change in the account itself, without an adjusting transaction. That's just wrong on one hand, and violates GAAP on the other. > Also, Matthew, I think you misunderstand how LOTs work. Lots just > link a set of transactions (actually a set of Splits) together. There > is no additional data in the Lot (amounts, values, etc). A Lot > consists of a list of splits.. That's all. Also, LOTs enable more > than just FIFO -- because you can (with the right interface) > specifically state which set of shares you are selling. > There's nothing to stop us from adding attributes, though. At the very least (and I think this is a preaching/choir moment) an interface is needed to edit the relationships. And I thought I mentioned specific selection of Lots as a way to reduce realized gains... Also, I do recall asking if Lots were an entity that would need to be recorded in the back-end. You answered quite positively. :) > > My proposal is this: track the *number* of shares in the Lot, and the > > *dollars* of shares in the Stock account. This will allow proper > > accounting of the money trail, while also tracking numbers of shares. > > It has the side benefit of *not* backtracking to the 1.6.x model of a > > Security and Currency per account. > > You again misunderstand how Lots currently work -- there is no data in > a Lot -- it's all in the splits. This does not mean that it cannot > change to meet your request, but what you are asking for is a HUGE > architectural change in the way ALL transactions are handled. > Lots have to have attributes; otherwise, there is no way to relate the Splits in a single lot. At the very least you have to have an identifier and a list of Splits. > Now, let's assume that we change how "stock" accounts work such that > we now track both a commodity and a currency (again). This means we > would necessarily need to keep TWO balances, a balance of "amount" > (i.e. shares) and a balance of "value" (i.e. dollars). At least > internally that's what we would need to do, but "externally" I think > the user always wants to see the "current value" of the account, which > means the share-balance * current-price-from-pricedb. > I would rather calculate the number of shares dynamically, and keep the purchase value of the stocks in the account (the 'value' field). Note that there is no requirement to constantly update the balance of the investment account. Indeed, the value shouldn't be changed except via a properly formatted adjusting transaction. Current values should only be only be on "how much is this stock worth right now" reports. Which, looking at it, isn't very far removed from the current implementation. > > 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. And you can use just one COI account for many > > different stocks. > > The problem with this model is that while you can easily track the > gains/losses, you cannot track the "current value" of your holdings. > At no time can you easily determine "I own N shares of XXXX", because > that information is stored throughout the dataset. The other problem > is that LOTS tie splits together in an account, but in this particular > case the "account" for the "associated" splits are different, making > it even more difficult to track your current holdings. As I said > at the beginning -- tradeoffs. This is true. Unfortunately, the above is the true and correct model for investment accounting, albeit somewhat simplified. 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 would provide one direction of change to help track quantities in a cumulative balance. Another possibility is to calculate checkpoints much as the the PG back-end does. 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. > > > Now, from an implementation perspective, it certainly makes sense to > > follow the generally accepted accounting principles. To track the > > dollar amount *instead* of number of shares alleviates the current > > multi-currency issues with stock accounts. It makes life somewhat > > It alleviates the gain/loss issue. It exacerbates the > current-holdings (net worth) issue. To-MAY-toe, To-MAH-toe. > I wouldn't say "exacerbates", but I look at it differently than it seems 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). The value of a given stock *today* should not be used, unless *today* is the day you decide the security has had an other than temporary change in value, and record the adjustment appropriately. > Similarly, what you are asking for necessarily requires you to define > a common currency for ALL your accounts. The reason is that you are > now requiring all your transfer to be in a common currency (you need > this in order for all your books to balance). Any account that wants > to track a "holding" in another commodity/currency necessarily needs > to be a stock/currency account. You cannot have "bank" accounts in > multiple currencies, nor could you track income or expenses in > multiple currencies, because you'd lose your gain/loss information if > you ever made a transfer across currencies. > 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. I had thought that there was some effort being put toward a way to transfer money between accounts of different currencies. Perhaps I thought wrong...in any case, we will always have to deal with cross-currency transactions. > Sure, you could apply logic so that you can only apply a transaction > across accounts of similar currency, and then you have special stock > and currency accounts to perform the proper commodity transfers. But > we're now back to the 1.6 dual-commodity (at least for Stock, MMF, and > Currency accounts). Not that I'm against this concept, mind you -- > I'm just pointing it out. > > 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. A Currency account would be > "special", in that the transaction can be denominated in "either" > currency. A stock account would still only be allowed to have > transactions denoted in its currency. > Which is really how it should be anyhow, IMO. My Ameri-centric understanding is that when you buy stock from an exchange you pay for it in the exchange's currency. > > easier when generating reports--there is no longer a need to run through > > many Lots to get a total of realized gains/losses for a period. You can > > see at a glance the dollar amounts for gains/losses and current invested > > amount. Net worth calculations are also simpler to implement. Also, > > Ok, I'll bite. How are net worth calculations simpler to implement? > Right now all you need to do is get a current price on all your > commodities and then perform a multiplication across all your > accounts. How does your method make it any easier to track net worth? Net worth is not calculated based on the current value of shares across accounts, but rather it is based on the purchase cost +/- adjustments (i.e., the running balance of the asset account, same as in other accounts). You don't have to do the price retrieval, nor the multiplication. There could be an option, perhaps, allowing for use of current price. I'm not opposed to having an account per security--mainly because I don't have enough to make it annoying. That rapidly becomes unscalable, though, which is why I would prefer to be able to enter investment purchases in a single account, or an account per exchange. It's probably simpler to (re)implement it as a stock-per-account, though, because with the addition of 1 field (stock balance) and a few methods, we can track both the share balance *and* the purchase balance. Which is what I had in mind when I suggested a StockSplit subclass above... > > Accountants generally are more interested in dollar amounts, not number > > of shares (I've seen many questions from Gnucash users about how to get > > info in a form appropriate for Accountants). And to retrieve the number > > Well, sure, the Accountants want this information..... once a year! > The rest of the year I want to know "how well is my portfolio doing, > and what is it worth?" Shouldn't we optimize for the "likely" > operation, not the once-a-year operation? > If you want to know how your portfolio is doing today, you bring in the current price and run a report. If we're able to subclass Split, the point is moot. I myself would prefer to adhere to GAAP as closely as possible. I feel it gives me a better grip on my finances and one less thing to worry about in today's economy. Others may not be so stringent. *shrug* life choices. I believe we can accommodate both sides, though, and make *most* people happy. > > of shares and other Lot information, all you have to do is add the > > Transaction GUID to the GUID list in whatever Lot, or possibly more > > appropriately, add the GUID of the Lot as an attribute of the > > Transaction (foreign key, as it were). > > > I don't know how far Derek has gotten on the Lot development. I > > 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. > > > able to do so. We would want to record the number of shares in the Lot, > > of course, but that is a required interface in any case. The security > > No, lots tie splits together. There is no "share" information in a > Lot. You determine the number of shares by looking at the "first" > Split->amount in the lot. > > > mnemonic could also be stored in the Lot, which would allow us to > > combine security investments in one account, instead of a separate > > account for each security. > > This _sounds_ like a good idea, but it makes account valuation HARD. > As conrad says, this might be a good way to hand Inventory, but a > stock portfolio is NOT inventory. With inventory you want to know how > much you paid for your assets, and subtract out depreciation. But > that's NOT what you want to know about your stock holdings. > Actually it is. You want to maintain a static balance, and create adjusting transactions when the value as apparently permanently changed. Current values should be calculated on the fly and relegated to a report. The reports, of course, help you decide when to make adjusting transactions. > But let's assume for a moment that we do store the stock commodity in > the Lot instead of the Account -- you still cannot store the number of > shares in the Lot. The reason is that there is not a 1:1 mapping of > purchases and sales. I could have a Lot that contains the following > Splits (note that I'm leaving out the date, and the "account" is > assumed)): Yeah, you may be right, if we don't extend Lots. I realized that, and came up with the above StockSplit idea. > > > In the current register, as far as I can tell, the only immediate change > > that should be made is to record a dollar amount in Balance instead of a > > number of shares. That's the first step torwards aligning with > > accounting practices. Derek's work with Lots will go a long way to > > making this a reality, if he agrees with my assessment (well, he *is* > > the one writing the code!). > > What it sounds like you REALLY want (and you don't need Lots to do > this), is a DOUBLE BALANCE. You want to accumulate a balance in > SHARES as well as a balance in VALUE. But that is still not > sufficient to do what you are asking. The problem is still that you > need to balance each transaction. 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. Record the number of shares and price as we do now, and offer a warning if price * share != debit/credit. Assuming no value adjustments, though, the amount of a credit should equal the original purchase price, with the rest of the money (or lack thereof) being recorded in realized gains (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. > > 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. > > 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. Second, it would also require a change to how > gnc_lot_is_closed() works. > Well, the entire goal is to be able to record a gain/loss amount in a Split under a gain/loss Income account. I would prefer that Stock accounts be tracked in monetary terms, too, if possible. Maybe there's a way to do both... > Unfortunately it also would mean that any multi-curency transaction > would need a lot as well (for the same reason -- to track gains/losses > in currency transfers). But I'm not convinced this is a bad thing. ;) > This will always be a problem, at least until *everybody* is using the same currency *everywhere*. > I certainly don't have all the answers, but I don't see Gnucash as a > tool for accountants -- I see it as a tool for PEOPLE. Interfacing to > accountants should be a secondardy goal, not a primary goal. I think > I've shown how we can do both. It's definitely important for the average Joe to be able to adapt Gnucash to personal needs. I've seen enough questions about how to export data to this or that format, or provides thus-n-such a report, in a format for the accountant, that I believe maintaining tight compatibility is very important. Not only that, but the compatibility really *does* help provide a clearer financial picture. Please understand I'm not suggesting we should provide a tool suitable for use only by accountants. Where possible I think we should provide as simple an interface as possible, while still maintaining the (hidden) data in an accounting-suitable format. I also think that we should provide the capability for an accomplished accountant to dive right in and start using Gnucash with minimal fuss. Perhaps a pipe dream--but a worthwhile goal nonetheless. I think I've used my quota of college words for the day, so I'm gonna stop now... -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ******************************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something...
signature_asc_DEFANGED-58115.DEFANGED-73443
Description: application/defanged-73443
