[This message was posted by Sri Thayaparan of Millennium Information Technolog <[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/ab906cef - PLEASE DO NOT REPLY BY MAIL.]
Hi everyone, I just thought to share my views with regard to repeating groups as my perception varies slightly from whats being discussed here. As far as I understand, if a "No<repeating block name>" field has a greater than 0 value, generally the first field in the repeating group referred to, by the <repeating block name> is a required field. This is because, it is the delimiter between individual sub-messages. But, within a repeating sub message, you can have non-required fields in-between which gives the user the flexibility to *not* send such tags always. My stance is, you can have repeating group fields skipped (and technically even out of order) so long as the first field in the repeating group is always stamped first and is made required. > > >For example, in TradeCaptureReport message, we are sending a > > >stipulation block. NoSides(552)=1|Side(54)=1|NoStipulations(232)=1|Sti- > > >pulationType(233)=TEST|StipulationValue(234)=N With reference to the 4.4 spec, Order ID is a required field of the side block. Hence, it has to be there. But then again I assume, its a custom spec for which you are connecting, where Order ID is made non-required in the side block. If thats the case, the side block looks fine, because you have the first field "Side" stamped properly. As for the stipulation sub-sub block, only the first field "StipulationType" is required. This also looks fine since you again have the first field stamped properly. I would emphasize, that a FIX sub-message parser should not deviate much from the main body parser except for the enforcing of the first field, thats to make it the delimiter rather than introducing an additional repeating group delimiter character. Please provide feedback on your views. Thanks! Regards, Thaya. > OK, I'm humble enough to eat some pie here. > > I didn't notice that the Stipulations themselves were a member the > repeating group TrdCapRptSideGrp and thus the order of fields becomes > significant. > > You are absolutely correct. I thought it strange that you were making a > mistake in the first place. I should have known better. > > JohnP > > > > Greg, I respectfully suggest that you may have misread the original > > > question. > > > > John, > > > > Okay, I may be missing the boat here, but the original question says: > > > > >For example, in TradeCaptureReport message, we are sending a > > >stipulation block. NoSides(552)=1|Side(54)=1|NoStipulations(232)=1|Sti- > > >pulationType(233)=TEST|StipulationValue(234)=N > > > > > >The other side is rejecting our message, and is saying stipulations > > >"need to be sent later in the message - after the account (tag 1)". > > > > > >In addition, they also complain that we send OrderID tag out of > > >place. They claim we need to send tag NoSides(552), then Side(54), > > >then 37 (OrderID). We are sending tag 37 after PartyRole(452). > > > > In a TradeCaptureReport, the sequence of tags would need to be 552, > > 54, 37, ... 1, ..., then 232... > > > > Stipulations needs to follow Account since it is part of the > > TrdCapRptSideGrp and that is the order defined in the spec. > > > > Kind regards, Greg. [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 -~----------~----~----~----~------~----~------~--~---
