[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/9404a022 - PLEASE DO NOT REPLY BY MAIL.]
Mahesh, I agree that there is benefit in doing this but this would be a major undertaking for FPL and is a task that is far from trivial. There are many reasons for a conditional requirement and these would still have to be described in the comment column. A special (and trivial) case of a conditional requirement are the repeating groups where the first field is always required when using the tag=value syntax and other fields are required for every instance of a repeating group (Conditionally required when NoXXX>0). Less trivial are conditional requirements that FPL cannot pre-define but that are still needed in the rules of engagement. For example, the ExecutionReport has an optional InstrmtLegExecGrp which becomes conditionally required when you convey a multi-leg execution on the leg level and not on an instrument level. What I am trying to say is that a large number of fields are conditionally required for semantic reasons that may or may not be relevant for any given implementation. This should be left for the Rules of Engagement to describe. It might make sense and be a reasonable effort to automatically flag message fields in the Req'd column that have the term "conditionally required" in their comment column. This would give a heads up to developers that they really need to read the comment column :-). Regards, Hanno. > Hanno, > > In FIXimate / FIX specifications, presently the required column just > says yes or no. I think this should be changed to have the words > > Reqd - The field has to be present in the message - there are no > ifs and buts > > Cond - The field is conditionally required based on presence or absence > of other fields or values in other fields > > Opt - The field is optional > > I have come accross many people interpreting the Required = N without > looking at the comments column. Having value Cond would make these folks > look further towards conditions in which the field is required. > > Regards, Mahesh > > > I think this needs to be clarified to avoid confusion. The column > > "Req'd" in the spec is not the only way for FIX to declare a field to > > be required or not. The comment column is another possible source. The > > position of a field in a repeating group is a third possible source > > when using the tag=value syntax. The previous poster actually quoted > > from the comment in the spec. > > > > What happens if you do not send tag 11 in the Execution Report > > responding to a New Order Single? The submitter of the order will have > > a hard time to know which report refers to which order entry message > > if he does not wait for a response before sending another new order. > > From then on he could use the exchange order ID (tag 37) but it is > > neither permitted nor recommended to omit tag 11 in the Execution > > Report in the plain vanilla cases. There are very few exceptions where > > tag 11 is not available and thus cannot be returned. > > > > What advantage does it have to suppress tag 11 on an ExecutionReport? > > I would like to understand why that makes life easier for the > > recipient of order messages, regardless of what the spec says. > > > > Thank you, Hanno. > > > > > According to the FIX protocol spec, tag 11 is not required in the > > > execution reports, yes almost all firms send this tag in the > > > execution reports but it is not a required tag, it is only required > > > in the New Order messsges. > > > > > > > Tag 11 ClOrdID is required in all execution reports which are sent > > > > in response to electronically submitted orders. > > > > > > > > Tag 41 OrigClOrdID is required when Tag 150 ExecType is > > > > PendingCancel > > > > (6), Replaced (5) or Canceled (4), for other ExecTypes, sending > > > > Tag 41 is meaningless as many FIX engines would not be looking > > > > for it in ExecReports. > > > > > > > > > > > > > > When you say execution report do you mean the response to the > > > > > Cancel/Replace message(i.e Pending or Replaced msg)? If so, then > > > > > tag 41 is required and tag 11 can be sent but is not required. > > > > > If you mean sending executions (fills) on a modified order, then > > > > > tag 41 and 11 can be sent, it is not against the FIX protocol, > > > > > but they are not required. [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.
