Upgrade from Eikon -> Workspace. Learn about programming differences.
For a deeper look into our Eikon Data API, look into:
Overview | Quickstart | Documentation | Downloads | Tutorials | Articles
53
●6 ●3 ●6
When using get_timeseries for RIC FCPOJ0, the open, high and low are correct but the close is a duplicate of yesterdays close. This is not the case with for instance BOK0, where the behaviour is as expected.
Hello @eddy_de_groot,
Could you please give us a quick update on this:
Does the problem continue to occur?
Did you have a chance to contact Content Helpdesk to report the suspected issue and have it investigated by our content experts?
Let me describe the issue more clearly.
When I use ek.get_timeseries('FCPOc3') with no end date specified, iot returns me daily candles up to today. If the market is currently open , the OHLC of today show, but roughly towards mid-day the settlement of yesterday still populates the Close field (OHL are correct), whereas I would expect the last traded value. During the day it randomly changes to last traded value as expected.This holds not only for FCPOc3 but I've also seen this happening in BOc2, SMc2 abd Sc2 as well. The behavior is not consistent btw, e.g. there is no fixed time where this happens.
I now have a workaround in place where I grab the minute data candles of today and deduce from that the OHLC of today.
Hello @eddy_de_groot
Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?
If yes, please click the 'Accept' text next to the reply. This will guide all community members who have a similar question. Otherwise please post again offering further insight into your question.
Thanks,
AHS
Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.
Thanks,
AHS
18.2k
●21 ●13 ●21
The Excel formula retrieves data from Lipper webservice.
From my observation, it seems that it reports last trade price to excel output.
So I think it always update according to the TRDPRC_1
However, Eikon Data API retrieves data from UDF service.
And give out different data.
Moderators in this forum are not able to confirm nor clarify the data behavior.
Refinitiv Content Helpdesk(https://my.refinitiv.com/) would be able to explain or give you an authoritative answer as why the data behave as you mentioned.
I have submitted case no. 08364124 on your behalf.
thanks for your answer, however I dont understand the following:
"Moderators in this forum are not able to confirm nor clarify the data behavior. "
you are able to replicate it and you see it is wrong. I am asking for a fix, not an explanation as there is no alternative to get historical daily data through the python API and I am getting wrong data points.
Also I find it a bit depressing when you forward the issue to the help desk that the first question I get is what the query is I used, i.e. he/she had no idea what the story behind this query was..
I understand your frustration, however, this forum is monitored by API specialists and not content/data specialist. As you maybe aware Refinitiv offers a broad breadth and depth of data from various source via different data services / endpoint and each has its own support team.
My colleague has explained the data disparity - i.e. excel and the API source their data from different services - Lipper and UDF. Unfortunately, he is not in a position to explain the differences in data between the two services and has therefore raised a ticket on your behalf. This should allow the Lipper and UDF specialists to investigate the disparity and work towards a resolution.
Apologies that the helpdesk asked you to repeat information that you had already provided here - my colleague did include a link to this thread when he raised the ticket.
895
●3 ●8 ●3
Im off to Malaysia this week, so this is a nice timely question on Malaysian Palm Oil Futures, thank you! :)
Im not sure whether you are saying you think the HIGH and LOW is correct, but the settlement is wrong compared to another source. Or you are just worried that because the close/settlement price hasn't changed you think it could be incorrect?I have checked against the exchange website and it looks like the Settlement Price hasn't changed for the past two days. This is possible as while the Highs and Lows come from the trading data. The Settlement Price (close price) is calculated by the exchange and sent out based on their own internal algorithm, which means it is less affected by trade price fluctuations.
If you really do think the settlement price is wrong for this contract then its best to raise it via our support desk and then they can speak directly to the exchange to confirm what we have been sent by them. Do this using the Contact Us button.
53
●6 ●3 ●6
As I get no response let me clarify it once more what is happening. Again this morning (8:31) the same thing happens.
But now I also made a comparison between excel API and the python API.
On the left you see the excel output, exactly as expected.
The get_timeseries however returns the incorrect data. It returns a CLOSE value for a weekend day and the CLOSE is repeated for today as well. Both of which do not happen in excel.
The data requests are made at the same time so I would expect the same output. Like I mentioned earlier, the data issue is always resolved towards the end of the day and this happens in nearly all commodities I follow, but most severe in FCPO chain RIC.
When I query for minute data, this issue that the CLOSE is repeated is not present FYI.
Please help with/resolve this issue.
Best regards,
Eddy
