Realized profit

[traderpards]

You know that number in the control center under the Strategies tab that tells you the Realized Profit? How can I retrieve that from the data structures?

I have a trade structure that saves the entry object and the exit object and I can get the actual realized trade profit/loss just fine. The problem is when I try to subtract commission from that. For the input parameter Cbi.Execution e in OnExecutionUpdate(), when I check e.Order.OrderState = Filled, it seems the commission is halved when there was a partial fill (of 1+1 for qty 2) and completely accurate when the entire order was entirely filled.

What's the best way to keep track of these commissions or can I get what the commission is for that instrument somehow (that would be best)?

I don't have any problem multiplying by however much I need to but I can't figure out how much I need to multiply by because I can't tell how the order was split. If that information isn't available, I'll settle for getting what Ninjatrader is figuring out, of course if there is a way to do that...

Note: I've already looked here so no need to refer me to this... https://ninjatrader.com/support/help...?execution.htm

Thanks!

[NinjaTrader_ChelseaB]

Hello traderpards,

Unfortunately, the commission is only available from the Execution object for each trade and would need to be custom calculated or can be found from the TradePerformance collection object.

Below is a publicly available link to the TradePerformance > TotalCommission property in the NinjaTrader 8 help guide.

https://ninjatrader.com/support/helpGuides/nt8/en-us/totalcommission.htm

Below is a link to a forum post with further information.

https://ninjatrader.com/support/forum/showthread.php?t=106102

[traderpards]

Thank you for your reply. I took your advice and have spent the past two days trying to figure out how I'm supposed to keep track of the profit/losses. I finally figured it out, I think. At least I get close enough, like within pennies if not on the money, most of the time.

I have figured out that I need to have calculation code when both e.Order.OrderState == OrderState.PartFilled AND when e.Order.OrderState == OrderState.Filled (That one is obvious.)

And I do - I have code that figures out how much I lost (or gained) in each case.

There is one special circumstance that causes me to get a wrong calculation. See the attached screenshot. It's that case where you have two exits at the same price. I'm not sure what is happening with the framework when that happens because you would think that since it's at the same price, the framework would get the quantity right and call it qty = 2 at that price. But even so, that shouldn't be a problem since just like all partial fills, the framework should call OnExecutionUpdate() for the partial fill and again for Filled if this is a partial fill, just like it does when the partial fill is at a different price than the other fills.

But it doesn't, not when the exits are at the same price. OnExecutionUpdate() is only called when e.Order.OrderState == OrderState.Filled, which means my calculation is off by that many ticks times point value minus commission and I'm at a loss as to how to correct that.

Would you have any ideas on how to do that? For me the problem is in one of two areas - either it should get the quantity right or it should call OnExecutionUpdate() for the partial fill order state. Either fix and my calculations would be correct.

[NinjaTrader_ChelseaB]

Hello traderpards,

Each part fill will show as a separate trade (attached with its exit) in the Strategy Performance. It will not combine orders into a single quantity.

If you script is calculating these with part fills before the order has fully filled, I would recommend using logic to not add the commission for each part fill and only apply the omission on the first part fill or after the order has fully filled.

With the orders and prices, you are not looking for specific prices and you are instead saving the order objects to variables and accessing these this way with first in first out, is this correct?

Are you finding that some NinjaScript properties or methods are not working correctly?

Unfortunately, in the support department at NinjaTrader it is against our policy to create, debug, or modify code or logic for our clients. This is so that we can maintain a high level of service for all of our clients as well as our partners.

This thread will remain open for any community members that would like to assist you with your custom calculations.

You can also contact a professional NinjaScript Consultant who would be eager to create or modify this script at your request or assist you with your script. The NinjaTrader Ecosystem has affiliate contacts who provide educational as well as consulting services. Please let me know if you would like our business development follow up with you with a list of affiliate consultants who would be happy to create this script or any others at your request

[traderpards]

Bad presumption: I will never ask you to debug my code. Ever. And I'm pretty sure there is nothing in my request that asked you to. That should have been obvious, since I didn't even attach any script.

With that being said, yes, I'm using a C# queue. I capture the order amounts using a Queue<double> and I'm dequeuing them with each fill or part fill based on e.Quantity passed in with OnExecutionUpdate(). Hence the problem...

Quick note: I was applying the commission with each fill and/or part fill and I'll modify the code to not do that. But that isn't the problem. I'm not complaining about being a little off. I'm reporting that something is wrong.

I'm telling you, on certain occasions the framework will fill an order of two with two part fills at the same price. If you don't believe me I gave you a screenshot that proves it in the previous post. I don't think it's such a problem necessarily that it fills an order on two separate part fills at the same price as long as it calls OnExecutionUpdate() for each fill. I'm also telling you that it is not calling OnExecutionUpdate() on the part fill for some reason and on the fnal Fill, the quantity is wrong. That is why I'm coming up with the wrong answer.

So either Ninjatrader needs to be smart enough to combine two orders filled at the same price into a single order with the correct quantity or it needs to call OnExecutionUpdate() for both orders. I really don't care which because if it did either of them, my code would give the right answer.

I will remove the part that adds commission on the part fills but there isn't anything I can do about Ninja not calling OnExecutionUpdate() when it should. I'm pretty sure that fixing that part about the commission will not somehow free Ninjatrader to behave properly.

Please don't make further assumptions about my code, especially if you haven't even seen it. And no, I don't need to pay someone to do something I'm perfectly capable of doing.

[bltdavid]

OnExecutionUpdate() is only called when e.Order.OrderState == OrderState.Filled

Really? Is that true in NT8?

It's certainly not true in NT7 ...

[traderpards]

Only for the case where there are two exits with the same price. It gets called when OrderState == PartFilled on any other case. That's the problem.

You too? I can't believe I wasn't clear. I wrote it very carefully.

I was clear. Read the rest of the sentence

But it doesn't, not when the exits are at the same price. OnExecutionUpdate() is only called when e.Order.OrderState == OrderState.Filled...

I need OnExecutionUpdate() to be called when OrderState = State.PartFilled when this case arises so I can finish the calculation and get it right.

This has to do ONLY when there are multiple orders on an exit and both of them have the same price. Please, please, please look at the screen shot.

[sledge]

I see no code in this thread to debug.

[bltdavid]

I see no code in this thread to debug.

Absolutely no offense, traderpards, but I agree with Sledge.

I mean, think about it this way:
The only way to really prove or disprove what you're saying is via
code, right? Good old-fashioned, short & sweet, example code.

Have you written a small sample strategy (with a greatly expanded
OnExecutionUpdate) that can illustrate the problem? Something
small that can be shared and used as the foundation for others
to reproduce and study the problem?

You want to nail down what you say is a bug? Well, provide some
sample code that proves it. I think you'd have some people jump
all over that kind of posting ... including NT support ...

(Otherwise, like Sledge gently implies, we don't know if the bug is
in your code or NT's code.)

[bltdavid]

Is this Managed or Unmanaged mode?

I presume you're using Unmanaged approach because
it appears from your screenshot that you have multiple
profit targets defined ...

I don't thing multiple targets are supported with a single
Managed mode order. They were not in NT7, and my
understanding is that NT8 didn't change that limitation.

My understanding is:
Scaling out via multiple limit orders for targets, from a
single entry order, is only supported with Unmanaged
mode.

[traderpards]

David, absolutely no offense but you don't understand the issue so please don't comment.

The issue is NOT, NOT, NOT about getting someone to debug my code. It's about wrong behavior in OnExecutionUpdate() in NT8.

[bltdavid]

David, absolutely no offense but you don't understand the issue so please don't comment.

The issue is NOT, NOT, NOT about getting someone to debug my code. It's about wrong behavior in OnExecutionUpdate() in NT8.

Calm down, no need to be rude, this is not traderpard's private help forum.

You've asked a question on a public forum.

Why are you here, if you don't wish to profit from public comments?

I recommend you send email to [email protected] if you want your problems kept private.

[bltdavid]

David, absolutely no offense but you don't understand the issue so please don't comment.

I think I do, at least for what you've written. You're seeing a target exit order with two fills (one of them partial) for the exact same price that don't seem to be properly accounted for vis-a-vis OnExecutionUpdate().

The issue is NOT, NOT, NOT about getting someone to debug my code.

True, but you're implying a bug may exist in NT8 codebase. My comments about using Unmanaged mode and Do-You-Have-Sample-Code are extremely on-topic.

These are valid questions whether you have 1 year of programming experience or 30 years.

It's about wrong behavior in OnExecutionUpdate() in NT8.

I agree, although until proven, a helpful bystander might wish for more evidence the problem is not with your code.

[NinjaTrader_PatrickH]

Hello traderpards,

Thank you for your patience.

We understand you are trying to bring forth that two partial fills of one order at the same price and time will not always trigger OnExecutionUpdate(). This should be straight forward enough to test for on our end.

If you did have an example or simplified script that reproduces this matter it would be most helpful in our testing.

Please let me know if you have any questions.

[traderpards]

Profit and loss calculation script (that actually works)

Thanks Patrick.

I finally figured out how to determine the profit/loss and have a working script that I’ve attached for use as an example because apparently, I’m not the only one who was interested. I get the exact same number as Ninjatrader gets with a caveat.

While trying to figure out if it was even possible to calculate profit/loss I was willing to settle on “close enough” – this was before I even thought of the queuing the entry and exit values - and I was playing around with AverageEntryPrice for the entry and exit Order objects. Of course, I needed to check if those objects weren’t null before I accessed them so I did. When I discovered those values weren’t as “close enough” as you would think, especially when you are dealing with a number of contracts, and that, that wasn't going to work, that's when I thought of putting entry and exits in their respective queues. But I left the checks for entry and exit != null in there by mistake. That turned out to be the reason why my breakpoints were never hit in OnExecutionUpdate()when OrderState = PartFilled, not because it was not getting called. Now, why the exit Order object was null is another question but I’ll let someone else figure that out since I now have something that works and since it’s only null when it feels like it and only when you’re in Market Replay. (Because there's no way I'm going to be able to figure out why the exit Order object is sometimes null on the first trip into OnExecutionUpdate().)

About that caveat I mentioned. I will admit that I don’t have the slightest idea how to fill out the Commissions dialog and the documentation isn’t much help – am I supposed to ask my broker how to fill that out? But when I fill it out like I’m showing in the attachment – note that Per-unit commission is half - I get the correct calculations because I’m multiplying the commission times two in OnExecutionUpdate(). You would think if I put the full commission in there and didn’t multiply the commission times two in OnExecutionUpdate(), it would work the same and the results would be accurate - same as Ninjatrader gives which is the correct calculations. But they’re not. The calculations only match Ninjatrader’s (which are correct calculations) when I do it like I’m showing, with half commissions entered in Commissions, Per-unit commission and multiplying times two in OnExecutionUpdate().

That was my Saturday, trying to figure out, by means of trial and error how to make something work. The good news is that as far as I can now tell, OnExecutionUpdate() is being called in Market Replay when OrderState == PartFilled.