[This message was posted by Hanno Klein of Deutsche Börse Systems <hanno.kl...@deutsche-boerse.com> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/c85a1fc3 - PLEASE DO NOT REPLY BY MAIL.]
John, quick answer on OrigClOrdID. The spec says "ClOrdID(11) of the previous non rejected order (NOT the initial order of the day) when canceling or replacing an order." My interpretation of this is that you can only determine whether an order transaction (new, replace, cancel) was rejected or not when you have received an answer (ExecutionReport). In your case this has not happened yet, i.e. B has not been confirmed yet. This would suggest that you cannot use it. However, the scenarios in Volume 4 suggest differently. If you look at D.2.x you will see that the two requests issued prior to receiving ERs use (Y,X) and (Z,Y). This is the "optimistic" approach I guess. D.2.c shows what to do when things go wrong. The second ER returns (Z,X) and not (Z,Y) because at this point Y has been rejected and X is the last valid ClOrdID. This would answer your second question. If B does not get rejected, the last ER should return B and not A. So it seems that the sender and receiver both use their "personal" view, possibly being different. The sender progresses from X to Y to Z without knowing whether they will be accepted. The receiver always returns the last one he accepted. Regards, Hanno. > I am ashamed to admit that I am being unsure of ClOrdID usage > when canceling an order that is in a pending replace state. Here > is a scenario: > > ->NewOrderSingle(ClOrdID=A) <-ExecReport(OrdStatus=New; ClOrdID=A) <- > ReplaceRequest(ClOrdID=B; OrigClOrdID=A) <-CancelRequest(ClOrdID=C; > OrigClOrdID=A) > > My first question: Is the CancelRequest bad? I would have expected the > CancelRequest to have OrigClOrdID=B. But officially, order A is still > alive and so it might be appropriate to try and cancel it. > > Now let's move onto the second issue, which presumes the CancelRequest > is acceptable (which I may say I would disagree with). If the > CancelRequest is accepted and the ReplaceRequest is completed first, how > do you respond to the CancelRequest? Example: - > >NewOrderSingle(ClOrdID=A) <-ExecReport(ExecType=New; ClOrdID=A) <- > ReplaceRequest(ClOrdID=B; OrigClOrdID=A) <-CancelRequest(ClOrdID=C; > OrigClOrdID=A) ->ExecReport(ExecType=Replaced; ClOrdID=B; OrigClOrdID=A) > ->ExecReport(ExecType=Canceled; ClOrdID=C; OrigClOrdID=?) > > Should the final ExecReport indicate OrigClOrdID=A, matching the > CancelRequest? If so, surely that would be bad as order A is definitely > no longer live. Should the final ExecReport indicate OrigClOrdID=B? If > so, this wouldn't match the CancelRequest. > > I appreciate light being shed upon this darkness. > > JohnP [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to FIX-Protocol@googlegroups.com To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
