[This message was posted by David Armstrong of Platform Technologies <[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/3b7ac3ad - 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 -~----------~----~----~----~------~----~------~--~---
