Imported from previous forum
We are sending FIX messages to another company who has very strict FIX parsing for the order of the fields.
For example, in TradeCaptureReport message, we are sending a stipulation block.
NoSides(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(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).
Unfortunately we don’t have control over this. We are using TransactTools which orders these automatically. We have tried contacting their support and they say order does not matter in FIX except for in repeating groups and there is nothing we can do.
So what is the official word on ordering here?
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Ali,
Your response TransactTools is correct. Send this (from vol 1 of the FIX 4.4 spec) to your counterparty:
vvvvv
Except where noted, fields within a message can be defined in any sequence (Relative position of a field within a message is inconsequential.) The exceptions to this rule are:
. . .
4. Fields within repeating data groups must be specified in the order that the fields are specified in the message definition within the FIX specification document. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.
. . .
^^^^^
We are sending FIX messages to another company who has very strict FIX
parsing for the order of the fields.For example, in TradeCaptureReport message, we are sending a
stipulation block.NoSides(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(233)=TE-
ST|StipulationValue(234)=NThe 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).Unfortunately we don’t have control over this. We are using
TransactTools which orders these automatically. We have tried contacting
their support and they say order does not matter in FIX except for in
repeating groups and there is nothing we can do.So what is the official word on ordering here?
I thought there was also wording (but I don’t recall where specifically) that tags defined as part of the header should come before any body tags. There is no ordering requirement within header or body tags except as it relates to specific repeating groups as already mentioned.
I know this behavior is part of the way QuickFIX expects to parse messages.
Ali,
Your response TransactTools is correct. Send this (from vol 1 of the FIX
4.4 spec) to your counterparty:vvvvv Except where noted, fields within a message can be defined in any
sequence (Relative position of a field within a message is
inconsequential.) The exceptions to this rule are:
. . .
4. Fields within repeating data groups must be specified in the order
that the fields are specified in the message definition within the
FIX specification document. The NoXXX field where XXX is the field
being counted specifies the number of repeating group instances that
must immediately precede the repeating group contents.
. . . ^^^^^We are sending FIX messages to another company who has very strict FIX
parsing for the order of the fields.For example, in TradeCaptureReport message, we are sending a
stipulation block.Sides(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(233)=TE-
ST|StipulationValue(234)=NThe 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).Unfortunately we don’t have control over this. We are using
TransactTools which orders these automatically. We have tried
contacting their support and they say order does not matter in FIX
except for in repeating groups and there is nothing we can do.So what is the official word on ordering here?
[ original email was from John Prewett - jprewett@lavatrading.com ]
TransactTools support is correct (although field order is also important for BeginString, MsgLength, MsgType & CheckSum too).
The other company isn’t obeying FIX protocol standards that basically permits fields to occur in any order.
JohnP
We are sending FIX messages to another company who has very strict FIX
parsing for the order of the fields.For example, in TradeCaptureReport message, we are sending a
stipulation block.NoSides(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(233)=TE-
ST|StipulationValue(234)=NThe 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).Unfortunately we don’t have control over this. We are using
TransactTools which orders these automatically. We have tried contacting
their support and they say order does not matter in FIX except for in
repeating groups and there is nothing we can do.So what is the official word on ordering here?
[ original email was from Greg Orsini - greg.orsini@orcsoftware.com ]
I agree with the counter-party - order is enforced in this case.
The question relates to repeating groups. Note the fields in question:
NoSides(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(233)=TE-
ST|StipulationValue(234)=N
NoSides(552) is a NumInGroup type that defines the number of ‘TrdCapRptSideGrp’ elements to follow. The order of the tags in this element is fixed and must follow the order in the specification.
Greg.
TransactTools support is correct (although field order is also important
for BeginString, MsgLength, MsgType & CheckSum too). The other company
isn’t obeying FIX protocol standards that basically permits fields to
occur in any order.JohnP
We are sending FIX messages to another company who has very strict FIX
parsing for the order of the fields.For example, in TradeCaptureReport message, we are sending a
stipulation block.Sides(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(233)=TE-
ST|StipulationValue(234)=NThe 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).Unfortunately we don’t have control over this. We are using
TransactTools which orders these automatically. We have tried
contacting their support and they say order does not matter in FIX
except for in repeating groups and there is nothing we can do.So what is the official word on ordering here?
[ original email was from John Prewett - jprewett@lavatrading.com ]
Greg, I respectfully suggest that you may have misread the original question.
The original posting indicates that the receiver is obligating that the Stipulations repeating group (in its entirety) must appear in the message after the Account tag. I still believe this doesn’t match with standard FIX protocol.
The original posting has nothing to do with the order of fields within a repeating group or the repeat count that must occur prior to the repeating group. Incidentally, the sender does indeed correctly honor the repeat count field followed by the repeating block fields in the correct order according to his original posting.
JohnP
I agree with the counter-party - order is enforced in this case.
The question relates to repeating groups. Note the fields in question:
des(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(233)=TE-
ST|StipulationValue(234)=NNoSides(552) is a NumInGroup type that defines the number of
‘TrdCapRptSideGrp’ elements to follow. The order of the tags in this
element is fixed and must follow the order in the specification.Greg.
TransactTools support is correct (although field order is also
important for BeginString, MsgLength, MsgType & CheckSum too). The
other company isn’t obeying FIX protocol standards that basically
permits fields to occur in any order.JohnP
We are sending FIX messages to another company who has very strict
FIX parsing for the order of the fields.For example, in TradeCaptureReport message, we are sending a
stipulation block.des(552)=1|Side(54)=1|NoStipulations(232)=1|StipulationType(233)=TE-
ST|StipulationValue(234)=NThe 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).Unfortunately we don’t have control over this. We are using
TransactTools which orders these automatically. We have tried
contacting their support and they say order does not matter in FIX
except for in repeating groups and there is nothing we can do.So what is the official word on ordering here?
[ original email was from Greg Orsini - greg.orsini@orcsoftware.com ]
> 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|StipulationType(233)=TEST|StipulationValue(234)=NThe 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.
[ original email was from John Prewett - jprewett@lavatrading.com ]
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)=NThe 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.
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” field has a greater than 0 value, generally the first field in the repeating group referred to, by the 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)=NThe 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.