On Fri, Jan 6, 2017 at 12:22 PM, Christopher Singley <[email protected]> wrote:
> Securities trading is basically a special case of inventory/cost of goods > sold bookkeeping. It's a bit funkier than plan-vanilla flow-of-funds type > bookkeeping. > > You can read up on it at the website for which beancount is named: > http://www.dwmbeancounter.com/BCTutorSite/Courses/Inv/lesson02-2.html > Actually, Beancount isn't named after this, thought I did read it a long while ago, it's a great site. In terms of that tutorial, we're essentially talking about "FIFO Perpetual > Inventory" accounting... except that for securities inventory, we relax the > requirement to maintain a consistent scheme for booking out inventory units. > > Essentially, we need to maintain a journal which is a list of (asset, > datetime, units, cost [or cost per unit]). > That's what Beancount does, except it's in terms of position = (units, currency, cost & cost currency, date, label) Your datetime is quantized to days. The label is there to help identify a particular lot by name if you need to. > Summing for cost [or cost*cost/unit] ties out to balance sheet accounts. > What do you mean by "ties out"? > For trading marketable securities, a normal chart of accounts will have > current asset subaccounts for every issue owned (identified by ticker, > CUSIP, ISIN, or what have you), and current liability subaccounts for each > issue sold short. > That's what I recommend. Each trading account I use has a subaccount for every particular commodity, e.g. Assets:US:InteractiveBrokers:Trading:AAPL > Each of those subaccounts will have a subaccount for cost, which ties out > to the journal with the constraint that sum of cost for a given asset has > to equal the costs posted to the relevant balance sheet subaccount on the > general ledger. > Instead of using a subaccount, each of the position has its cost attached to it. This representation allows us to think of aggregating any type of position. This then allows us to formulate queries using something simple like SQL. "Sum up all the contents - whatever it is - under those accounts" is a working idea. Entries to the inventory journal are not double-entry accounting, and > they're not necessarily money-denominated at all. Weird stuff happens to > inventory in the real world (if you can call the stock market the real > world). > > When you reduce or close a position, somebody needs to look through the > list of lots, and choose which lot(s) to get rid of, based on some logic. > Based on that choice, whoever's controlling the inventory will return a > figure for the cost booked out, and the guy maintaining the general ledger > will post a transaction decreasing the balance-sheet cost of the asset (on > one side) and increasing the cost of goods sold on the income statement (on > the other side). > That's exactly what the lot reduction process is like in Beancount. The information you provide is matched against the list of available lots right before the transaction is applied. There's even a debugging tool to print out the contents of the accounts affected before and after (bean-doctor context). Because the cost basis is kept attached to each lot, it is summed and balanced against the other postings of the transaction. It seems to me that what you want is a Python dict of {asset: [lot, lot, > lot, ...]}, where lot=(datetime, units, cost). > The "Inventory" object is essentially that, it's a mapping from (currency, cost, acquisition-date, label) -> units Same thing. More generally, you keep a journal like that for each brokerage account, so > you'd either want to key the dict above by (account, asset), or a better > way would be to use nested dicts e.g. portfolio[account][security] = [lot, > lot, lot, ...]. That way you can quickly & naturally sum costs for a > security in an account (via hash map lookup & list comprehension), and roll > those up into total cost for a brokerage account. > You can do the same for units. This corresponds to the way this stuff gets reported by brokers and the way we set up these charts of accounts. It's a little bit less ideal for reporting aggregates of securities across accounts, but still way better than an unstructured list. Inventory's representation is equivalent, but also allows a well-defined aggregation of any position. I see no disadvantage in the way Inventory represents it compared to a hierarchical representation. > Unfortunately the list structure seems to be baked into the application > interface of inventory.py... the inventory control logic isn't locally > encapsulated, so the dumb objects here return list pointers back to where > the smarts actually reside. I think this means I can't change this without > completely forking the project and ripping up things nobody wants ripped > up. > > Oh well. > Actually no. Converting Inventory to a dict is not very difficult, very minor changes in the interface would need be done. BTW encapsulation in this case would be a bad thing... the inventory matching logic is much better left factored out of the container. Baking and "encapsulating" the logic in a method "abstraction" is something I'd have done in the 90's when I was much less enlightened and in love with OO and Design Patterns (I'm almost ashamed to admit, there was once a time...). A better way to build this is to keep the containers dumb and the algorithms outside, it's a much more flexible and elegant design. It's on purpose. > On Friday, 6 January 2017 09:50:54 UTC-6, Simon Michael wrote: >> >> Interesting discussion. >> >> hledger is the least sophisticated of the three when it comes to >> trading, currently. Beancount seems to be leading the way here. One of >> these days I hope to understand better what y'all are talking about here. >> >> On 1/5/17 9:18 PM, Martin Blais wrote: >> > The TL;DR is that Ledger doesn't attempt to book reducing lots against >> > specific positions. >> > Furthermore, it doesn't distinguish between currency exchange and >> positions >> > with a cost basis. >> > Tracking of cost basis is therefore quite limited. >> > AFAIK HLedger repeats those same design choices (though I haven't >> looked >> > for a while). >> >> >> -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beancount/c3a9d027-0e12-4717-9f27-0dde48a39e31%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/c3a9d027-0e12-4717-9f27-0dde48a39e31%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhNxq%3DjmYJiSKA1GucZJqLqii4BjjKc5PtOJPp8En9XOCA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
