Thanks for the guided tour of beancount, I will puzzle through its workings. So far I like what I see very much; I'm just trying to see if I can fit it to my use case.
On Friday, 6 January 2017 22:59:11 UTC-6, Martin Blais wrote: > 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). > I've got some wash sale logic, but nothing that's ready for prime time. This is a reasonably hairy problem. The thing to keep in mind is that the accounting treatment here is different for GAAP vs. tax basis. The way CPAs handle this is to keep the books on GAAP basis, to produce GAAP financial statements, and then there's a separate workflow involving book-to-tax adjustments (with its own journals) to produce tax reports. They keep all this shit off the main ledger. So the general solution involves a reporting function that can ingest a separate journal of adjusting entries, with its own equality constraints, to accommodate different accounting bases. No fun. Often the amount of the disallowed loss is judged not worth the effort to track it, and it's just written off. > ... ... >> >> 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. > I tend to stick with strict ISO 8601 across the board. If beancount could reasonably be generalized to be fit for purpose, it is my hope that I would be able to do much of the work myself - who likes a crasher that brings nothing to the party? However, looking at your code, it might take me more than 6 months to hone my amateur programming skills to match your quality of work! 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? > If you're an active trader, Interactive Brokers is the best on many metrics (not all of which are important to me). They are the UNIX of stockbrokers. However, although they'e improved a lot over the years, their tax accounting leaves much to be desired; they struggle with these data structures too. 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. > We did this for years (aggregating trades by day); it's very undesirable. It caused a lot of manual spreadsheet reconcilation to tie our books out to brokerage statements that didn't aggregate trades... I could give you many examples. I've been much happier since we started matching broker cost-lot accounting. > 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 suspect that's the case, and not just because of the problem of matching trades to accounts. In any case it's good to talk; it's clear I have much to learn from beancount. > > -- 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/cce5e7d5-6807-4114-a131-caf7b5191263%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
