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'. 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. ... ... 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? 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. 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. 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/msgid/beancount/e3e6445d-9f98-4e26-9b03-4c97fba70998%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
