Cost basis of short option (opening covered call transactions) is improperly calculated
I see an earlier comment on this subject, opened in February, 2023 and closed in August, but no resolution or response is indicated. The cost basis for an open covered call is a huge number which I am unable to duplicate in any useful manner. I am currently on MD 2024.2 but have seen the problem at least since 2020.
Is there something that needs to be entered in the security record that I'm missing, or is this a bug? An explanation would be helpful, even if there's no fix.
Thanks.
-- David
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
1 Posted by Stuart Beesley ... on 05 Jun, 2024 05:43 PM
Well... In simple terms, the system does not have any special coding that allows it to properly handle short/covers....
It's odd that you cannot replicate/duplicate the issue?
What are the txns' detail for this and the result / correct result?
2 Posted by david.d on 05 Jun, 2024 06:24 PM
Hi, Stuart. It’s not that I can’t replicate the bug, it’s that I can’t figure out where the number shown as “cost basis” comes from. It happens every time I sell a covered call. In this case, it was Tesla $230, expires 12/20/24, ticker is TSLA241220C00230000. Sold 4 contracts (400 shares) @13.00/share, gross proceeds $5200, fees $4.14. Portfolio View (and Securities Detail) shows a cost basis of $-30,764,390.77 (sure do wish I had that kind of money).
I’m not actually sure what the cost basis should be for an out-of-the-money call, but that’s not it. I would think it should be the same as any other position: the price you paid/got when you opened the position.
I’ve seen these outlandish numbers before, has the look of an unitialized variable but since I have no idea what the code looks like (I’m an unreconstructed C developer), I’m just guessing.
— David
3 Posted by Stuart Beesley ... on 05 Jun, 2024 07:09 PM
As I say. The short/cover txns are not coded in MD (which is Kotlin/Java). Basically a sell assumes (for cost basis) that the buys were made before the date of the sell (not after). Hence any calculation will be wacky.
4 Posted by Stuart Beesley ... on 05 Jun, 2024 08:00 PM
If you create a dummy dataset (File/new dataset) which contains a few txns and a wacky cost basis, then file / export backup and upload it, I can look at it and tell you how the calculation is derived.
You switch back to the original using file/open.
5 Posted by david.d on 05 Jun, 2024 08:00 PM
Well, then, I’d say that’s a bug, if they’re not coded. The transaction types are there. It doesn’t have to be anything fancy, just a reasonable set of assumptions. It should be on a schedule for a future release, at least.
6 Posted by Stuart Beesley ... on 05 Jun, 2024 08:02 PM
Bug, oversight, missing.. whatever your definition… I agree it should be coded…
7 Posted by david.d on 12 Jun, 2024 12:10 AM
OK, I've created a test database, real simple, and added the transaction duplicating my original. Updated pricing so there was a change in value.
Observation: The cost basis that it shows is -30,769,230.77, the same as on my original. No clue where it comes from.
Update: tried to upload file "Test_Database-20240611-2001.moneydancearchive", rejected with comment "has contents that are not what they are reported to be". Can probably send via email.
8 Posted by david.d on 12 Jun, 2024 12:12 AM
Per my comment posted via the website, file was rejected.

— David
9 Posted by dtd on 12 Jun, 2024 12:52 AM
Zip the file/package up and try again.
10 Posted by david.d on 12 Jun, 2024 02:43 AM
Zip attached.
System closed this discussion on 11 Sep, 2024 02:50 AM.