Historically we have used a combination of PROD_PERM, RECORDTYPE and RDNDISPLAY to determine how to map raw FIDs to our internal data model members. Obviously this needs to be done because every exchange publishes data differently and adding different asset classes only further complicates where data lives in the incoming ticks. CONTEXT_ID seems to help a bit, but I'm still finding RICs that don't follow the published spec in Data Model Discovery. I'm curious how others are managing these mappings and if CONTEXT_ID is truly the new standard for grouping like RICs where similar data is consistently published to the same FIDs.
A simple example here would be were a "price" lives. Could be TRDPRC_1, BID, ASK, SEC_ACT_1, PRIMACT_1, MID_1, MID_PRICE, GEN_VAL* (based on GV*_TEXT) and so on....
Yes, Eikon has its own logic to map fields to CF fields and the mapping can be different among exchanges.
You need to contact the content support team via MyRefinitiv to verify the field mappings used in exchanges.
Hello @JTHIEDE ,
As a developer, my thinking would be that your suggested combination of PROD_PERM, RECORDTYPE and RDNDISPLAY is at least a very good starting point, if not a total coverage of the use case. By finding any instances where differentiation is not covered and mapping is still different and working into these specific cases with content experts, you should be the complete the required map, is my thinking.
I would think also that any additional delineating factors would be asset-specific, i.e. the next level of fid to look into should differ between asset types, based on the ones you already have identified for example, for bonds there are specific types of bond defined and BOND_TYPE defines this info. However, suggesting to work through this with Refinitiv content as suggested by @jirapongse.phuriphanvichai.