Universal Close Price of -9999401in TimeSeriesExtractionRequest for exchange holidays using REST API

When requesting Universal Close Price for some futures contracts on exchange holidays, the price is returned as -9999401 or -9999402. I get this when using the REST API. The prices are invalid, is there a way I can determine from the API that the day in question is an exchange holiday?

Here's some Postman code:

{
"ExtractionRequest": {
"@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.TimeSeriesExtractionRequest",
"ContentFieldNames": [
"Universal Close Price",
"Trade Date",
"Asset Status",
"Trading Status",
"Official Close Price"
],
"IdentifierList": {
"@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.InstrumentIdentifierList",
"InstrumentIdentifiers": [
{"Identifier": "CCc1", "IdentifierType": "Ric"}
]
},
"Condition": {
"StartDate": "2019-05-09T00:00:00.000-05:00",
"EndDate": "2019-05-12T00:00:00.000-05:00"
}
}
}

Find more posts tagged with

dss

pricing

dss-rest-api

datascope-select

exchange-holidays

Accepted answers

veerapath.rungruengrayubkul

@michaeljbutton,

I have done some research and found that the returned value is NULL codes. Please see this link for definitions. You may use the values to get reason of null value.

All comments

Christiaan Meihsl

@michaeljbutton,

Official Close Price:

I just ran your query in Postman, it returns 2 records (9th and 10th May):

    "Contents": [
        {
            "IdentifierType": "Ric",
            "Identifier": "CCc1",
            "Universal Close Price": 2330,
            "Trade Date": "2019-05-10",
            "Asset Status": "ISS",
            "Trading Status": 1,
            "Official Close Price": null
        },
        {
            "IdentifierType": "Ric",
            "Identifier": "CCc1",
            "Universal Close Price": null,
            "Trade Date": "2019-05-09",
            "Asset Status": "ISS",
            "Trading Status": 1,
            "Official Close Price": null
        }
    ],

Strangely, I cannot reproduce the negative value for the UCP field you mention, I get either a positive or a null value. I get exactly the same output if I replace the Timeseries call with a PriceHistory call (as per the note below).

Can you still reproduce the issue in Postman ? If yes, can you post the complete output here please ?

Important side note:

Please note that the legacy TimeSeries Pricing extraction will be removed end February 2020, the more powerful PriceHistory extraction replaces it. Our tutorials, and the Postman collection, were updated in May 2019 to reflect this. If you are using the TimeSeries call, you must plan to modify your code. As part of the migration process, it is important to understand that, in some instances, field content extracted from the TimeSeries report will be available under different field names in the PriceHistory report. It is also possible that some previously populated values in the TimeSeries report will be blank in the PriceHistory report. This is due to data mapping changes. For more information, please refer to the Product Change Notification PCN 10897.

veerapath.rungruengrayubkul

@michaeljbutton

I am able to replicate the same value, -9999401. If I uncheck the "Return Null Code Values in Extraction Pricing Fields" in the User Preferences, the "Universal Close Price" field will return null instead.

Please directly contact DSS support team via MyRefinitiv.
In the product field, select "Reuters DataScope Select".

Christiaan Meihsl

The preference setting is interesting, and might be the key to a solution.

veerapath.rungruengrayubkul

@michaeljbutton,

I have done some research and found that the returned value is NULL codes. Please see this link for definitions. You may use the values to get reason of null value.

michaeljbutton

Thank you both for your replies. Useful to know that TimeSeriesExtractionRequest is being removed, and VERY useful to understand about the "Return Null Code Values in Extraction Pricing Fields" user preference, I didn't know that existed and now it makes sense. And also where the documentation was.

I am interested to see how Price History handles values for which negatives are acceptable e.g. spreads? I will look through the docs though once I have been given access.

EXPLORE OUR SITES