On Fri, Jan 6, 2017 at 8:38 AM, Christopher Singley <ch...@singleys.com> wrote: > > On Thursday, 5 January 2017 23:21:14 UTC-6, Martin Blais wrote: > >> There are two phases: parsing, and then booking. >> The parsing outputs incomplete costs, which are interpreted as aspects to >> be matched against the list of available positions during the booking phase. >> After booking, the postings all have instances of "Cost" resolved to >> match exactly against existing positions. >> Therefore, the Inventory code can afford to be simple and just look for >> an exact match. >> > > Sorry, could you point me in the direction of the relevant booking code? > Your code is very well organized, but I'm just a humble CFA type unburdened > by fancy computer science book learnin'. >
Here: https://bitbucket.org/blais/beancount/src/397e821a48c5db2700a8a66868c5d4 e68ca19bfb/src/python/beancount/loader.py?at=default&fileviewer=file-view- default#loader.py-436 The loader invokes the parser on all files ("recursively" is for the include files). Then runs the booking code. https://bitbucket.org/blais/beancount/src/397e821a48c5db2700a8a66868c5d4 e68ca19bfb/src/python/beancount/parser/booking.py? at=default&fileviewer=file-view-default#booking.py-19 This dispatches between old ("simple") and new ("full") booking codes. You can disregard the old version, it's flawed anyway, and not the default anymore. It's only there for transition, I'll remove it at some point. The new ("full") booking code is located here: https://bitbucket.org/blais/beancount/src/397e821a48c5db2700a8a66868c5d4 e68ca19bfb/src/python/beancount/parser/booking_full. py?at=default&fileviewer=file-view-default#booking_full.py-105 It's a bit gnarly, as it handles a lot of missing values ("interpolation") as well. The unit tests are perhaps more useful to try to understand it: https://bitbucket.org/blais/beancount/src/397e821a48c5db2700a8a66868c5d4 e68ca19bfb/src/python/beancount/parser/booking_full_ test.py?at=default&fileviewer=file-view-default But if you need to know the IRS rules about wash sales... there is indeed > an ambiguity in the revenue code, which is silent on the ordering of > replacement shares in wash sales. What the brokers do is use FIFO here, > and of course you'll want to tie your schedule D out to what the broker's > reporting to Treasury. Prior to 2010 (or the subsequent years' phase-in of > the broker cost basis reporting obligation by security type) it was up for > grabs; no guarantees that your broker's basis information (if they reported > it to you at all) is accurate in any way. I've got large deltas because of > pre-2010 return of capital distributions from lots still on the books, that > were never coded as such by brokers. As you can see, I'm not much of a day > trader. > I've read all the IRS documentation on wash sales and wrote code to reproduce its examples in Beancount. I have a complex case (monthly vesting of RSUs) where tons of little wash sales get generated and cascade each other through time. Once I realized their rules were ambiguous, it was clear this was an unintended consequence of the law. There's only one software on the market I've found that claims to be able to do this, and other people have tried resolving the madness here: https://github.com/adlr/wash-sale-calculator and here: https://github.com/bbreslauer/wash-sale-tracker I use a specific method - designed to be as disadvantageous to me as possible - to assign cost basis to replacement lots and track them using Beancount. The numbers are small so I don't care foregoing my loss deductions longer than I have to. I'm more concerned about avoiding using losses prematurely and then having to go through and audit and make backpayments. I'd rather it be the other way around (being owed to). ... ... > > Do you think beancount would fall over if I swapped out position.Cost.date > and position.CostSpec.date for Python datetime.datetime instead of > datetime.date? > Not sure. There's very little computation on the dates, mostly just comparisons for sorting and equality. - The would need to be some sort of new syntax for parsing the times - There are some invariants in the ordering of directives e.g. Balance directives need to appear before all transactions; having a time might mess with that and add complexity, that might create odd situations - Comparisons would have to be reviewed everywhere - All the unit tests would have to be ported In any case, it's not a quick hack and there are so many other more urgent things I doubt I'd have time to work on it for another 6 months or more. This is a fundamental requirement for those of us who use Interactive > Brokers, whose trade accounting is *very* granular. Since the other side > of every trade is always some algo trying not to show its cards, you wind > up with a zillion lots of 100sh at the same or slightly different prices, > and the same or slightly different millisecond. We always pick lots > algorithmically... besides FIFO/LIFO, maxcost and mincost are popular, for > obvious reasons. > Interesting. I'm considering joining the platform myself, mainly to take advantage of the low margins and leverage up. Do we have another IB user in the house? I think there's a possibility that you may be able to aggregate cost at the importer level and book an aggregate, simplified trade. Not sure, I'd have to see what the downloaded data looks like. My other brokers also split sales on matches, but not that much. It's not dramatic. BTW I'm not unfamiliar with this problem, I used to work for a few HFT shops (on various desks). Beancount isn't designed with that usage in mind. I think it can tolerate some, but like I said, if you have tons of trades/day, you're better off writing something custom. I also note the comment in your code about the choice to use indexed lists > instead of dicts to track inventory, on the assumption that these lists > will always be small. I don't really need high performance, but this > sounds like it might be a problem if you really started running some trade > volume through it. On pretty low-key trading activity I regularly maintain > 10K rows in inventory in 20 securities; figure I need to budget for > handling at least 1M rows. > Converting the inventory from a list to a dict should be very easy. In fact, it used to be this way. It would take about a day's worth of careful work to do it and port all the unittests to ensure everything still WAI. I guess I'm probably going to have to wind up writing my own. Too bad, > we're solving very similar problems and you appear to be a much better > programmer. > > > -- > 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 beancount+unsubscr...@googlegroups.com. > To post to this group, send email to beancount@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/beancount/e3e6445d-9f98-4e26-9b03-4c97fba70998%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/e3e6445d-9f98-4e26-9b03-4c97fba70998%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 beancount+unsubscr...@googlegroups.com. To post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhP6Puv0D8MyCPrWfF5Hxh-xfHD84NF_UZd_vJ2LASVE3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
