get_data() inconsistent between an index and a single stock

(1) get_data() on an index:

ek.get_data('.TOPX', fields=["TR.PriceClose.date","TR.PriceClose.value"], parameters={'SDate':'2020-01-01', 'EDate':'2020-03-31', 'Frq':'D'})[0]

(2) get_data() on a single stock

ek.get_data('5411.T', fields=["TR.PriceClose.date","TR.PriceClose.value"], parameters={'SDate':'2020-01-01', 'EDate':'2020-03-31', 'Frq':'D'})[0]

I have two questions about inconsistency between the two requests above.

Question 1: Starting date

(1) stats from 2019-12-30

nstrument Date Price Close

0 .TOPX 2019-12-30T00:00:00Z 1721.36

1 .TOPX 2019-12-30T00:00:00Z 1721.36

2 .TOPX 2019-12-30T00:00:00Z 1721.36

3 .TOPX 2020-01-06T00:00:00Z 1697.49

(2) starts from 2020-01-06

Instrument Date Price Close

0 5411.T 2020-01-06T00:00:00Z 1394

1 5411.T 2020-01-07T00:00:00Z 1388

2 5411.T 2020-01-08T00:00:00Z 1402

3 5411.T 2020-01-09T00:00:00Z 1445

Why is that? Is there any way of correcting this inconsistency?

Question 2: Duplicated entries for (1)

You can already see duplicated entries for (1) on 2019-12-30. The same thing happens on other days such as 2020-02-21 and 2020-03-19.

Could you check it and let me know why this duplicated returns happen? Is there any way of correcting it?

Thank you!

Find more posts tagged with

python

eikon

workspace

eikon-data-api

refinitiv-dataplatform-eikon

workspace-data-api

Accepted answers

veerapath.rungruengrayubkul

Below is the resolution provided by Content specialist in the case: 08558851.

Upon checking, this is due to the logic behind these two TR items
TR.ClosePrice - calendar logic built in and delivers data in-line with Exchange specifics
TR.PriceClose - calendar holidays are not mapped to the data series

However please notice that there's a parallel issue ongoing with a TR.PriceClose series feeding NULL data for holidays by multiplication of the previous day price .
This is a known issue that concerns a list of indices (and indices only): .SP500, .5SP45, .FTSE, .TA25, .BAK, .TOPX and a few others. For the fact that there's a valid workaround of appliance of a TR.ClosePrice data item instead, the issue is not treated as a priority. I'm therefore not in position to provide a possible data of a fix deployment.
Thus, in these circumstance, please use a TR.ClosePrice data item which has the calendar logic built in and delivers data in-line with Exchange specifics or alternatively TR.PriceClose field, with a reminder that calendar holidays are not mapped to the data series.

I have updated the excel file with TR.closeprice and the data is showing correctly.

All comments

unknown

iwasakI

Hello, Iwasaki

F.Y.I.

https://community.developers.refinitiv.com/questions/57386/reply-wrong-datatopx-yesterday-close-data.html

I think better to use TR.ClosePrice.

chavalit-jintamalit

Hi @iwasaki

This seems to be a same content issue as posted on https://community.developers.refinitiv.com/questions/57386/reply-wrong-datatopx-yesterday-close-data.html

I have raised ticket no. 08558851 on your behalf.

In the meantime, please use the TR.ClosePrice field. (However, I also think there is a problem on this TR.ClosePrice field too, it should not be close from 31-12-19 to 05-01-20)

chavalit-jintamalit

Hi @kengo_takahashi_deprecated_0

Thanks a lot for your answer.

I am sorry that I didn't see your answer before I submitted my answer.

So I ended up posted the same content with your answer.

veerapath.rungruengrayubkul

Below is the resolution provided by Content specialist in the case: 08558851.

Upon checking, this is due to the logic behind these two TR items
TR.ClosePrice - calendar logic built in and delivers data in-line with Exchange specifics
TR.PriceClose - calendar holidays are not mapped to the data series

However please notice that there's a parallel issue ongoing with a TR.PriceClose series feeding NULL data for holidays by multiplication of the previous day price .
This is a known issue that concerns a list of indices (and indices only): .SP500, .5SP45, .FTSE, .TA25, .BAK, .TOPX and a few others. For the fact that there's a valid workaround of appliance of a TR.ClosePrice data item instead, the issue is not treated as a priority. I'm therefore not in position to provide a possible data of a fix deployment.
Thus, in these circumstance, please use a TR.ClosePrice data item which has the calendar logic built in and delivers data in-line with Exchange specifics or alternatively TR.PriceClose field, with a reminder that calendar holidays are not mapped to the data series.

I have updated the excel file with TR.closeprice and the data is showing correctly.

EXPLORE OUR SITES