Imported from previous forum
My company is in the preliminary stages of a project to integrate a FIX engine into a prospective client’s back-office accounting system so that OMS communications to these back-office systems can utilize the FIX protocol. An additional aspect of the project is the creation of a translation function to translate FIX messages to the native message format of the back-office system. The back-office system and its native message formats cannot be changed.
My question pertains to guidelines or best practices in mapping order IDs. The back-end system requires three pieces of information to uniquely identify an incoming order: Firm ID, Terminal ID and Sequence Number. In the case of a change order, the Terminal ID and Sequence Number of the original order must also be supplied (The Firm ID is assumed to be the same.)
In terms of mapping this order identification information to the associated FIX messages, we have identified several alternatives, two of these being:
a) For new orders, concatenate the Firm ID, Terminal ID and Sequence Number (to be supplied from the OMS) into the CIOrdID field. In the case of a re-order, map the original order’s Firm ID, Terminal ID and Sequence Number into the OrigCIOrdID field. The translation function would then parse the CIOrdID and OrigCIOrdID fields into the discrete fields required by the back-office accounting system. Issue: Does field concatenation conform to protocol standards and/or best practices?
b) Utilize discrete fields in the FIX messages for each field. Specifically, map Sequence Number to CIOrdID, Firm ID to SenderCompID and Terminal ID to SenderLocationID. For a re-order, map the Original Sequence Number to OrigCIOrdID field. Issue: For a re-order where do we map the Original Terminal ID? Establish a custom field?
Any guidance as to standard or best practices in handling this type of mapping issue would be greatly appreciated.
Don Kulle