% of profit calculation includes commission only on one part of the calculation

[antamy]

When calculating % of profit, the code subtracts the commission from the total profit, but not from the max profit. It should deduct it from both, since your max profit obviously also is reduced by commissions you pay.

func (o *Option) CalculateTotalProfit() float64 {
	exitPrice := 0.0
	if o.ExitPrice != nil {
		exitPrice = *o.ExitPrice
	}
	profit := math.Floor((o.Premium - exitPrice) * float64(o.Contracts) * 100)
	return profit - o.Commission // Subtract commission for accurate net profit
}

func (o *Option) CalculatePercentOfProfit() float64 {
	if o.Premium == 0 {
		return 0
	}
	maxProfit := o.Premium * float64(o.Contracts) * 100
	actualProfit := o.CalculateTotalProfit()
	return (actualProfit / maxProfit) * 100
}

I think also that commissions in general need beefing up, since the data entry dialog requires you to manually total the commission for opening and closing the position. This could be a configurable item so it is not needed to be entered at all.

[MarkT1065]

Ack. I've long known commissions were meh accurate at best but good enough when it was just me and I let my broker take care of the penny level detail.

But now that others are looking at Wheeler, I'll look at commissions again and/or review pull requests.

[antamy]

I've taken a quick look at the commissions. It is not clear what the Commission field on the option entry dialog requires. Is it the commission per contract? The commission paid on entry and on exit? Or the total commission for entry and exit?

In the code, it is treated as the total commission for the entry and the exit, even if the option expired (ie no commission paid). So, that needs to be corrected. I'd propose that the Commission entry field is per contract, since that would be consistent with the other fields on the option entry dialog.

That then leaves the industry fee. That fee is usually 1c per contract, but sometimes I get charged say 3c for 3 contracts, sometimes 4c. I guess it is minor in the big scheme of things and could be ignored.

I can make these changes if you are aligned on the thinking.

[MarkT1065]

As far as I understand it, the $0.65 commission is per contract, so it'd be $1.30 for a sold-to-open and then buy-to-close, but it'd be just $0.65 is the option got assigned.

This is the only fee I pay when I trade. Commissions/fees may be different across brokers? $0.65 is also hardcoded as a default, which could be moved to the Settings section for configurability.

[MarkT1065]

There are unit tests included in the codebase. This would be a good one to test, too, if the commission logic were contained to a single function.

[antamy]

I've been doing some more analysis now that I'm getting to grips with the codebase and Claude! My mistake on the basic Commission handling - it is per contract and is stored as contracts * commission in the database. However, there does appear to be some flaws in the logic:

1. there are 2 methods that close a trade. Both ALWAYS add the closing commission, regardless of whether the option:

• Expired worthless (exitPrice = 0, no commission should be charged)
• Was bought to close (exitPrice > 0, commission IS charged)
• Was assigned (no commission charged)

2. maxProfit should account for the full round-trip commission

With my broker, I only get charged a per-contract commission on an actual trade, not on an expiration or assignment (which is expiration followed by a position buy/sell).

I'll have a look at the unit tests - again another new aspect of this for me!

[MarkT1065]

We're in agreement on the logic you wrote above.

I had claude write tests, but I was able to run them manually. I use GoLand and ran them in the IDE. Check out make test. It has Claude remnants left over from the original attempt with GTK before I switched to the easier webapp implmentation. make test should successfully run your tests for you.

See TestMetricService_ComprehensiveSnapshot https://github.com/MarkT1065/wheeler/blob/main/internal/models/metric_test.go#L13 for a pure in-memory database example.

[antamy]

I'll give it a whirl. I now have a 29 page spec and plan that Claude prepared! We've been going back and forth on some nuances, but I'm finding it loves to over-complicate things. More to come ...

[MarkT1065]

i've been using Claude at work for the past few months. It can be VERY verbose and often goes off the rails.

[antamy]

We're in agreement on the logic you wrote above.

On the Symbol > Options table, the Commission column just displays the commission rate per contract (which is stored in the database). This doesn't seem to be particularly useful, so I propose changing it to display the total commission. I also propose showing total commissions paid per symbol in the header of this page.

Any objections?

This brings up the question of what should be stored in the database. Currently it is just the base data, and everything else is calculated on the fly from that. It seems to me it would be more useful (cleaner code, easier metrics etc) to store actual commission paid, and then reverse engineer that into the commission rate if need (which is only on the Edit option modal). I don't know how many people are using this right now, but obviously such a change would impact current users and an upgrade script would be needed.

Thoughts?

[MarkT1065]

I agree on all points. Yes for the table to show the total commission for that trade (using the logic previously described). I agree, too, it can be calculated and stored in the db.

It's a bit of a "migration" to go from calcualted-on-the-fly to calculate-and-store.

Claude recently added a "migrations" function that runs on start. This might be a good place to add the commission migration logic: https://github.com/MarkT1065/wheeler/blob/main/internal/database/db.go#L63