[This message was posted by Hanno Klein of Deutsche Börse Systems <[EMAIL PROTECTED]> 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/6c61c4ee - PLEASE DO NOT REPLY BY MAIL.]
John, I have a couple of comments to your suggestion. Your model could work if one sees the Order Cancel/Replace request as two requests within a single message. In the given case, the cancel would be successful (an ExecutionReport confirms that) and the replace would be unsuccessful (an Order Cancel Reject confirms this part). The link between the two is the ClOrdID of the Order Cancel/Replace Request. it would need to be used in both responses and the OMS would need to be prepared to get more than one response for a singel request. In general, this should not be a problem as multiple executions following from a New Order Single or Order Cancel Replace can result in multiple Execution Reports. The difference obviously is that there are two different messages types being returned for a single request. The message flow would need to change to allow the following scenarios for an Order Cancel/Replace request: 1) Request cannot be executed at all --> send Order Cancel Reject 2) Request can be executed completely --> send Execution Report 3) Cancel can be executed but not the replace without violating OrdQty=CumQty+LeavesQty --> send Execution Report confirming the cancel followed by Order Cancel Reject rejecting the replacement I do not know if there had been discussions at the time and why the third scenario is not part of the standard. One argument might be that it increases the number of response messages which is something at least exchanges are never fond of. The alternative I prefer is to omit the Order Cancel Reject message as it does not add new information. The ER confirming the cancel can carry the total as well as the executed quantity and is allowed to violate OrdQty=CumQty+LeavesQty due to the following. For OrdStatus "Canceled" takes precedence over "Partially Filled" (as opposed to "Filled" which has precedence over "Canceled"), i.e. you only need to change ExecType from Replaced to Canceled to express that the replace request has been changed to a cancel request. LeavesQty can be set to zero as an exception to the rule above due to the values of OrdStatus and ExecType both being "Canceled". The ClOrdID ties the response to the request. The OMS would need to cope with a response to a replace request that does not have ExecType="Replaced" but ExecType="Canceled". The upside of this variant is that OrdQty is not changed to a value never sent and the response is equal to the one for a cancel request, i.e. it is no longer an unsolicited cancel. This way it stays closer to the current FIX concepts I believe. Interesting discussion, unfortunately about some of the fundamentals of FIX concepts which makes it quite hard to change. That does not mean it cannot be changed. Regards, Hanno. > Deviating from the subject somewhat, I must admit that I don't > particularly like the way the FIX standard stipulates that you manage a > cxl/replace request where OrderQty is reduced to less than (or equal to) > the already executed quantity. > > FIX stipulates, as Sri correctly mentioned in the last post, that you > issue an ExecReport with ExecType=replaced; OrdStatus=filled; > OrderQty=CumQty; LeavesQty=0. For examples of the standard, please see > FIX.5.0 SP1 Volume 4 example c.3.b and c.3.c. > > I don't like the concept of altering the OrderQty on an ExecReport and I > believe many simplistic OMS engines wouldn't even be looking for this to > change and might get angry if you return an OrderQty value that wasn't > what they submitted. > > I prefer handling the issue in a non-standard way that has a much higher > probability of keeping even the simplest of OMS in sync with the correct > order state. Please notice that this method works just fine with all > versions of FIX. > > I send out two messages: > 1. Unsolicited cancel of the original order. > 2. CancelReject for the cxl/replace request. > > This should guarantee that the OMS handles the situation correctly and > the order ends up in the correct state. The only downsides are: > A. Not obeying the FIX standard. I therefore strongly disapprove > of myself. > B. The OMS may alert users upon receipt of an unsolicited cancel. > > Comments? > > JohnP [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
