Issue with bdh function using Rblpapi

[joe4go]

Hi,

I'm at my wits end trying to solve this issue. I would greatly appreciate any forthcoming help.

I'm trying to use the BDH function to call a historic data set for a BB mneumonic (CUR_MKT_CAP for example). My request returns data however I want to know the fiscal year associated with each reported value that is getting returned.

I'm able to resolve the issue in excel using the excel BB api however I can't seem to resolve this issue using Rblpapi.

When I run this R script:

date <- "19971231"
edate <- "20171231"
per <- "YEARLY"
per2 <- "FISCAL"
dys <- "NON_TRADING_WEEKDAYS"
fwd.fill <- "NIL_VALUE"
crncy <- "USD"
ov.rd <- c("periodicitySelection"=per,"periodicityAdjustment"=per2,"nonTradingDayFillOption"=dys,"nonTradingDayFillMethod"=fwd.fill,"currency"=crncy)

data <- bdh(securities="GLB ID EQUITY",fields="CUR_MKT_CAP",start.date=ymd(sdate),end.date=ymd(edate),options=ov.rd)

It returns:
date CUR_MKT_CAP
1 1998-01-03 640.3841
2 1999-01-03 904.1600
3 1999-12-31 343.5419
4 2000-12-30 153.8976
5 2001-12-29 348.9680
6 2003-01-04 441.6204
7 2004-01-03 803.6693
8 2005-01-01 1110.7837
9 2005-12-31 831.0861
10 2006-12-30 1144.7875
11 2007-12-31 1984.9340
12 2009-01-03 843.9186
13 2010-01-01 1215.8076
14 2011-01-01 1445.6788
15 2011-12-31 1765.4291
16 2012-12-29 3211.9088
17 2014-01-04 4444.5969
18 2015-01-03 4550.2143
19 2016-01-02 5452.2544
20 2016-12-30 4927.0542
21 2017-12-30 5303.0012

The problem I have is that I want to know what fiscal year each data point is for. I was able to achieve this in excel using this excel formula:
=BDH("GLB ID EQUITY","CUR_MKT_CAP","6/10/1997","07/10/2018","FX=USD","per=fy","DtFmt=FI","cols=2;rows=21")

which returns

FY1 1997 | 640.3841
FY1 1998 | 904.16
FY1 1999 | 343.5419
FY1 2000 | 153.8976
FY1 2001 | 348.968
FY1 2002 | 441.6204
FY1 2003 | 803.6693
FY1 2004 | 1110.784
FY1 2005 | 831.0861
FY1 2006 | 1144.788
FY1 2007 | 1984.934
FY1 2008 | 843.9186
FY1 2009 | 1215.808
FY1 2010 | 1445.679
FY1 2011 | 1765.429
FY1 2012 | 3211.909
FY1 2013 | 4444.597
FY1 2014 | 4550.214
FY1 2015 | 5452.254
FY1 2016 | 4927.054
FY1 2017 | 5303.001

I've been through the BB API documentation and I believe I need to add a variable for returnRelativeDate. When I add "returnRelativeDate" = "TRUE" to the options in the call I get the following error:

Error in bdh_Impl(con, securities, fields, start.date, end.date, options, :
Unexpected field returned.

Any help would be greatly appreciated.

[armstrtw]

overrides are not options.

[joe4go]

thanks for the response. what combination of overrides and options should I use then?
I tried adding the variable as an override rather than an option and it didn't work either.
As you can see from the code I've only added options so far (see below). But need to add the returnRelativeDate option/override.

data <- bdh(securities="GLB ID EQUITY",fields="CUR_MKT_CAP",start.date=ymd(sdate),end.date=ymd(edate),options=ov.rd)

[armstrtw]

feel free to post back when the bbg help desk provides you with an answer.

[joe4go]

thanks for your quick response. have bloomberg helpdesk started supporting the bloomberg R api? I'm able to work the excel api for this issue as described. However it won't work for the Rblapi. Therefore it seems to be an issue with this particular R package.

returnRelativeDate should be passed through as an option as far as I can tell. However I can't seems to pass through without an issue (as described). I think the underlying issue maybe related to options only accepting stings for this api.

I can't find anything in the rblapi documentation relating to this and the bb helpdesk won't assist on issues relating to an unsupported interface.

[armstrtw]

Rblpiapi does not expect a string for the date index. as the return type is a data frame, this assumption can possibly be relaxed, but that would require some work to change the underlying c++ implementation.

[johnlaing]

A recurring problem we have is that we don't know (ex ante) the shape of the thing that Bloomberg is going to give us back. My PR takes a one-off approach by reading the options and assuming certain behavior for returnRelativeDate=TRUE. I don't love this because:

• It assumes Bloomberg will be consistent in its behavior, which they may not be
• It forces us to own a series of one-off adjustments when we really should be simply parsing what we're given

Whit has toyed with genuinely building the result based on the data we get back, and I think that's a better approach long term. But that's not the construct in place (in this function, anyway) now, so I think we should go with the hacky patch.