On Sun, Jul 30, 2023 at 8:39 AM Martin Blais <[email protected]> wrote:
> On Sat, Jul 15, 2023 at 11:19 AM Eric Altendorf <[email protected]> > wrote: > >> ... >> > I'd like to run my own rules for booking (mostly HIFO, except able to >> select a slightly lower basis lot if it qualifies for long term instead of >> short term cap gains .. maybe some other special cases). I'm guessing I >> will need to implement these rules in my importer somehow, and have the >> importer label each lot and sale? Or should I implement the rules in >> Beancount directly? >> > > Those are not pluggable (but it would be a good idea to restructure some > of my code to make it so). > You'd have to make the change to the "master" branch, if you mirror the > other methods I'd welcome a PR (it should be easy I think). > I took a look at the code -- looks like it should be pretty easy to add new methods there. I'm not that far along yet, but when I get there I'll be in touch about it. ... >> > You don't reimport the same material. Updating your Beancount input file > should be an incremental process. Don't overwrite that you already > imported. Similar to my previous comment -- if you're going to automate > importing everything from scratch every time you might as well build > something distinct; I did that myself with github.com/blais/johnny. > Understood. For now I'm using the Beancount engine, data structures, and query language as a way to batch process the transactions, which I know is not the intended use. So far it's been OK, and what Beancount offers has been useful, but we'll see how far it takes me. It does seem like the core engine is amenable to use in a variety of workflows... I saw in the docs somewhere that transaction merging isn't well supported. >> Is that still the case? This is something I'll encounter since transfers >> between an exchange and a cold wallet will result in one leg being imported >> from the exchange and the other from the cold wallet. >> > > That's still the case. For context: by "merging" what is meant here is > that the two halves of a two posting transaction are inserted in the input > as two distinct transactions and automatically merged into one. (It just > requires a feature that matches the transactions and inserts postings to > transfer accounts, a bunch of design questions would come up.) > As mentioned elsewhere, I'm startinng to feel this is better addressed by the ZeroSum pattern than implicit merging. So far I'm happy with that. > >> I was a little surprised that Beancount doesn't deal with times or >> timezones :) Are there cases where ordering of intraday transactions can >> mess things up? >> > > That was an explicit design decision to (a) keep things simple (it can get > pretty hairy), (b) because the various institutions don't usually include > time and we're just trying to represent the data from the institutions. At > this stage my sense is that all we need is a way to resolve ordering. > Given that balance checks are done sparsely on the flow of transactions > changes in ordering don't cause dramatic problems, but like the ability to > resolve the mismatch in dates from two sides of a transaction, it would be > nice to eventually solve this properly. > Yeah, i get it. :) I do agree that ordering is the primary issue; if we got correct ordering without timestamps and timezones that would probably be good enough. Since crypto trades 24/7 and in exchanges in different timezones, discrete nominal days don't reflect the underlying reality very clearly. I ran into a number of cases where ordering was an issue because negative balances simply aren't treated the same. However, it was pretty easy to work around by attaching a timestamp on the metadata and sorting the transactions myself by that. > ... >> > thanks, eric -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFXPr0tvZYGUbtz-vGauhPFdCKiAoGCA-eHeC-f7bntFXO7gOQ%40mail.gmail.com.
