Just wrapping my head around the lay of the land. I’ve been trying to load directly from ThinkOrSwim and it keeps failing but I think I understand why now. Let me know if I have this correct:
Broker Sync - Sidesteps all issues and imports options trades w/o issue. (Requires Schwab giving user a Developer API which can take up to two days)
Generic Options Format - Main solution for options. Require a custom format, so after exporting from ThinkOrswim, ideally I create+automate an ETL process moving forward
ThinkOrSwim export - Is set up perfectly for stock but doesn’t work at all with options
Schwab export - Spotty when it comes to options. Just an ‘also ran’ basically
The exported .csv is unrecognized because it has a header that the backend doesn’t account for. Might need to offset the initial row(s) here.
Deleting the header allows TT to recognize it as ThinkOrSwim but it fails during the import w/ `Unexpected description format: “BOT +8 MSTR 100 15 MAY 26 105 PUT @4.90 …” - ThinkorSwim expects “BOT/SOLD +qty SYMBOL @price”`
I am using Linux, and also have a Futures + Forex account that I don’t trade but is populated for every export.
Below is a screenshot of what I have selected in ToS
I have gotten it working w/ a python script from Claude to restructure the data and import it w/o issue fwiw but looking to reduce the middle step in the long-term in case there are some bugs in it that I don’t see yet
Thank you for providing that CSV. I have added support for Options with this parser. Could you please pull the tradetally:nightly image for the change in about 5 minutes once it is done building and test it again?
Kinda worked for the example file I shared in spite of receiving an error about Type not being populated. In retrospect, there was only one actual trade present which perhaps wasn’t the best test case.
It doesn’t work at all for exports w/ more than one trade. I believe the issue resolves around the offset area. My uneducated guess is that it is conflating/compounding range of trades to process w/ number of rows to offset:
And here is the actual location it’s trying to parse: it is skipping the trades and trying to process the subtotals as trades, hence an attempt to process the subtotals as trades and TYPE failure being due to subtotals passing a NULL for the column
(Lower priority, but error msgs also show that log user permissions are off so I have to go upstream to docker container logs tradetally-app to troubleshoot instead of Settings→ System Logs inside the app)
That did the trick and logs are working! (There is still a visible TYPE error that is pushed after the trades are processed and it attempts to parse the subtotal row, but that’s more UX that can be set to skip/silently fail in a future release)
