Question about differences in dividend reinvestment events in money market vs. non-money-market listed funds.
Closed this issue · 5 comments
Hi, I'm still playing with your vanguard qfx importer and have a question in how it handles investment/sale events for 'money_market' funds. For example, I have a vanguard importer setup under the following config:
'fund_data': [
('VMFXX', '922906300', 'Vanguard Federal Money Market Fund'),
('VMMXX', '922906201', 'Vanguard Prime Money Market Fund'),
],
'money_market': ['VMMXX'],
}
From there I'm noticing a difference between two similar reinvestment events where for VMFXX an event will look like:
<REINVEST>
<INVTRAN><FITID>999999999<DTTRADE>20200529160000.000[-5:EST]<DTSETTLE>20200529160000.000[-5:EST]<MEMO>DIVIDEND REINVESTMENTDIVIDEND REINVESTMENT</INVTRAN>
<SECID><UNIQUEID>922906300<UNIQUEIDTYPE>CUSIP</SECID>
<INCOMETYPE>DIV<TOTAL>-0.25<SUBACCTSEC>CASH<UNITS>0.25<UNITPRICE>1.0</REINVEST>
Will look like:
2020-05-29 * "DIVIDEND REINVESTMENTDIVIDEND REINVESTMENT" "[VMFXX] Vanguard Federal Money Market Fund"
file_account: "Assets:US:Vanguard:Brokerage"
Assets:Vanguard:Brokerage:VMFXX 0.25 VMFXX {1.0 USD}
Income:Vanguard:Brokerage:Dividends:VMFXX -0.25 USD
but an event for VMMXX:
<REINVEST><INVTRAN><FITID>999999999<DTTRADE>20200529160000.000[-5:EST]<DTSETTLE>20200529160000.000[-5:EST]
<MEMO>DIVIDEND REINVESTMENTDIVIDEND REINVESTMENT</INVTRAN>
<SECID><UNIQUEID>922906201<UNIQUEIDTYPE>CUSIP</SECID>
<INCOMETYPE>DIV<TOTAL>-0.25<SUBACCTSEC>CASH<UNITS>0.25<UNITPRICE>1.0</REINVEST>
will look like:
2020-05-29 * "DIVIDEND REINVESTMENTDIVIDEND REINVESTMENT" "[VMMXX] Vanguard Prime Money Market Fund"
file_account: "Assets:US:Vanguard:Brokerage"
Assets:Vanguard:Brokerage:VMMXX 0.25 VMMXX @ 1.0 USD
Income:Vanguard:Brokerage:Dividends:VMMXX -0.25 USD
Question 1: Why does VMMXX look different? Is it because I have it confugured as a money_market fund? I assume writing something like 1 XXX @ 1.0 USD only applied to selling an asset or am I wrong?
Question 2: This might be a semantics argument, but is there a reason you prefer writing the account as Income:Vanguard:Brokerage:Dividends:VMFXX instead of Income:Vanguard:Brokerage:VMFXX:Dividends?
Largely curious to understand your importer design/conventions better. I've wrote a csv-based vanguard importer a while back (slightly more featured to handle 'exchange' events but requires massaging the csv a bit and needs some small improvements to be open sourced), but considering what else has been done to be more collaborative and have looked through your other writings about why you're going the qfx route: https://reds-rants.netlify.app/personal-finance/make-importers-easy-to-write-and-write-lots-of-them/
Q1: Yes, exactly.
From this article:
money market transactions, to be detected: these should use price conversions instead of being held at cost, for simplicity
The {} vs @ notation are for commodities held at cost vs price conversions (independent of whether it's a purchase or sale). The {} notation creates a new tax lot. This is unnecessary and rather painful for money market transactions. The 1.XX @ 1.0 USD instead creates a price conversion.
Q2: All forms are completely valid, and I think this should ideally be flexible for the user to set it, eventually. Out of the box, I happen to use neither of those, but this format: Income:Investments:Taxable:Dividends:Vanguard:VMFXX because it works really well with for needs: it comes down to which of these two questions are more important and frequently asked for your use case:
- What is my overall dividend income (across all my funds, and then across all my accounts)
- What is the total income (dividends, capital gains, interest, etc.) I got via VMFXX within a particular account?
I ask the former far more often, and I don't need to run a query with this hierarchy: I simply glance at the total in fava. For the latter, I use Beangrow, where putting the commodity as the leaf works out really well. Does that help? I plan to write an article explaining my account hierarchy at some point :).
I used to use a csv importer for vanguard too, but qfx is so much better: I rarely spend time tweaking and fixing bugs in my importers after moving to qfx, and better yet is always having auto-generated balance assertions. I'm happy to make beancount-reds-importers work for others. One way to handle your exchange events is to have have beancount-reds-importers call back a user-supplied python function for each transaction. There, all you'd have to do is to catch exchange events and rewrite the transaction however you want. I suspect an exchange-event handler would be useful for others too, so perhaps that one can go into the main investment transaction builder code, even. Feel free to point me to a gist or post your code here, and I can consider integrating it (and other things your importer does).
Question for you: would you be okay if I moved your comment above as a comment thread to one of my articles above in https://reds-rants.netlify.app/ ? This might get it more attention, and perhaps collaborators with pull requests for the issues you brought up :). Let me know.
Yes, good with moving this into a comment thread.
For Q1: Good to know, my convention at the moment had been around just using {1.0 USD} everywhere along with the No Booking option on money market accounts (see https://docs.google.com/document/d/11a9bIoNuxpSOth3fmfuIFzlZtpTJbvw-bPaQCnezQJs/edit#heading=h.7vx9vzscwpdb ) so lots don't get accounted for (i.e. 2000-01-01 open Assets:Vanguard:Brokerage:VMFXX "NONE") - haven't sat to think if this is really the right approach though especially in consideration of taxes. For now just not listing anything in the money_market list to meet my personal existing conventions but noting this to see if I should change my setup later.
For Q2: Okay, curious to learn more about your hierarchy/conventions at some point. I had erred at the time towards using the commodity as a middle/parent account rather than as a leaf since I've tended to err towards things like dividends, interest, etc as properties of a given commodity rather than how the naming could help with reporting overall/totals. (i.e. ended up with Assets:Vanguard:Brokerage:VMFXX, Income:Vanguard:Brokerage:VMFXX:Dividends, Income:Vanguard:Brokerage:VMFXX:Interest, Income:Vanguard:Brokerage:VMFXX:ProfitAndLoss ...) - another tradeoff is how easy it is to refactor namings and such when needed. Will have to think about this more.
Q1: that approach works as well. The downside: it does end up with a bunch of positive and negative lots, which I personally prefer to not see when making queries. But that's minor, and a personal preference.
Q2: Given you have the account and commodity somewhere in your account name, account hierarchy is trivial to change later on using global text replacement. Personally, I went with any reasonable hierarchy until it become intuitively obvious as to what worked best later on. Meanwhile, I did plenty of account renames (I used sed -i, and also use revision control) to play around and experiment as I found what worked best for me.
You probably already realize this, but to clarify: the lots do get created with booking set to NONE. It's just that that they don't get reduced when you sell. Instead, a negative lot gets created.