EViews.com

Hi, I am experiencing some trouble in fetching series from CEIC db: it shifts the series one cell below. In practice, data referring to 2001 is assigned to 2002 and so on.
in the past, I encountered a similar problem using quarterly data. CEIC support replied as follows:

***
Our tech team confirmed that this is a limitation with how eViews handles fetch statements, it does not have to do with CEIC interface.

Could you please try to use full date format for start date following the format below:
wfcreate ceicdata q 3/1/1998 @now

Using statement "q 1998q1 @now" makes the quarter slip by one period, so please avoid using this format!
***

Now the issue is with yearly data:
wfcreate gdp_contribution a 1978 2018
copy(link) ceic::SR1886323 cons_contr

the outcome is a series starting with a NA in 1978 and the number referring to 1978 flipped to 1979.

did anybody experience similar problem? any idea?

thx

When match merging a series whether it be from an external data source such as CEIC or from another workfile page, there is the issue on how to merge 2 series which have A)different frequencies and B)different start dates for the same frequency.

I will not address A) since it is discussed in our docs and here http://www.eviews.com/Learning/freqconv.html

For B) however, if the beginning of the periods of the source and destination series do not coincide with one another, there are 2 possible methods for aligning the data. You can either 1)take the start date from a period in your workfile and look for a match in series or do the opposite and 2)take the start date from a period in your series and look for match in the workfile.

For now I am going to use the reported problem as an example to illustrate. The line creates a workfile that begins on January 1, 1978. If I were to fetch a series that starts on April 1st, 1978, EViews currently uses the first method and attempts to locate an observation in the series that matches Jan 1 1978. Since Jan 1 1978 does not exist in the series, it sets the value for Jan 1, 1978 to NA. The next observation in the workfile is Jan 1, 1979. The observation in the series which covers Jan 1, 1979 is the 2nd observation which spans from April 1, 1978 to March 31, 1979 and therefore sets the second observation in the workfile equal to the first observation in the series. And so forth and so on…

Alternatively, EViews could have used the second method and the data would have been as you expected. In this case, EViews would have taken April 1, 1978 from the series and identified the first observation in the workfile as the destination location (since the first observation spans from Jan 1, 1978 to March 31, 1978). But technically this isn’t correct. The data starts on April 1, 1978 and the data Jan 1, 1978 does not exist and therefore the value for Jan 1, 1978 should be NA.

Secondly if the series started on December 1, 1978 (December fiscal year), would you still want the 1978 observation in the workfile to be set to the 1979 fiscal year value?

Both methods have their merits and issues. To be consistent with other methods and functions, EViews uses the first.

I am assuming series SR1886323 does not begin on Jan 1, 1978 and therefore what you are seeing is a general match merge issue and by design. I do not have access to SR1886323 and cannot confirm with certainty this is what is happening in this specific case, but we have seen similar issues and this usually the reason.

To resolve the issue, if you know the series being imported does not align with the workfile, you will have to create a workfile that spans beyond the last observation in the series and then manually adjust the data after fetching.

Got it. Found the solution.

thank you very much!

ok, I bumped in another issue, quiet annoying to be honest.
assume the following code:

***************************************************************************
wfcreate test q 03/01/2000 12/31/2022
copy ceic::SR90481787 exp_good

' This is a series NOT seasonally adjusted, starting in 1978 and,
' according to how ceic shows quarterly data, 2000Q1 data is dated
' 03/01/2000 (first day of the last month of the quarter). Last date is 2019Q4
' or, 12/01/2019
' Now I run x13

exp_good.x13(save="d11",outtype="all",tf=log) @x11 @x11arima
***************************************************************************

Eviews does return a series ending in 2019Q3. Looking more deeply, it appears that the whole d11 series is shifted one period ahead.
Is there a possibility that x13 gets confused when the sample is expressed in the way CEIC needs? is there a solution to it?

The next patch will have it fixed.