Bug in handling reverse stock splits from vanguard

[emin63]

I found another bug in handling reverse stock splits from Vanguard.

I owned 200 shares of LPI (CUSIP 516806205) which did a 20-for-1 reverse split. I should end up with 10 shares of LPI. Instead I end up short 190 shares of LPI and long 200.0 shares of "516806106".

I think the relevant OFX data is below

<FITID>881201203<DTTRADE>20200602160000.000[-5:EST]<DTSETTLE>20200602160000.000[-5:EST]
<MEMO>REVERSE SPLITREVERSE SPLIT</INVTRAN>
<SECID><UNIQUEID>516806205<UNIQUEIDTYPE>CUSIP</SECID>
<SUBACCTSEC>CASH
<UNITS>-200.0<TFERACTION>OUT<POSTYPE>LONG</TRANSFER>
<TRANSFER><INVTRAN>
<FITID>881209203<DTTRADE>20200602160000.000[-5:EST]
<DTSETTLE>20200602160000.000[-5:EST]
<MEMO>REVERSE SPLITREVERSE SPLIT</INVTRAN>
<SECID><UNIQUEID>516806205<UNIQUEIDTYPE>CUSIP</SECID>
<SUBACCTSEC>CASH<UNITS>10.0<TFERACTION>IN<POSTYPE>LONG</TRANSFER>
<INVBANKTRAN><STMTTRN>

Btw, if you could add some mode where it is possible to dump the OFX for a particular transaction or simplify the massive OFX file I get from ofxclient which causes problems for ledger-autosync, I could try to produce better test cases for you.

For example, if you have a unit test which includes the skeleton of an OFX file where I could dump in something like the above to get you a minimal test case, that would be great for lots of reasons.

Similarly, if somehow the txn object could carry along the raw OFX that produced it, that would also be really useful for debugging. As it is the txn object in converter.py has some fields like memo, security, and so on but if you could just keep the raw OFX in there it would be much easier to both set breakpoints to find how problems are being parsed and also dump out the offending OFX. I'm not sure how easy that is to do since OFX seems like an ugly format but just a thought.

Finally, thanks for your work on ledger-autosync. It's an awesome idea! Possibly my brokerage accounts are a bit too funky but I'm hoping we can get close. Thanks.

[egh]

Hm, this seems like an interesting case. l-a looks up the ticker symbol to use as the commodity, using the info provided in the SECLIST section of the ofx file. If it can't find anything there, it uses the CUSIP number for the commodity. It seems that would have switched in the reverse stock split, from 516806205 to 516806106. I wonder if the SECLIST includes that same ticker symbol (LSI) for both? That would create some wrong transactions, I believe.

l-a uses the https://github.com/jseutter/ofxparse library for parsing OFX files. I don't believe it passes on the ofx for a particular transaction. I agree that would be helpful! It is really hard to diagnose problems.

There do exists fixtures for OFX files in the codebase (e.g. https://github.com/egh/ledger-autosync/blob/master/fixtures/cusip.ofx#L1) and tests for them (https://github.com/egh/ledger-autosync/blob/master/tests/test_ofx_formatter.py#L249) Perhaps that can help? You can run the tests using nose (I'd like to switch to pytest, but haven't had the time).

Glad it's working for you! I only use it for my retirement accounts so I know it's all a little raw. I really appreciate the detailed bug reports.