Table A3.2 not fully loading

[MattCowgill]

This should result in 11 unique series, not 7:

a3_2 <- readrba::read_rba("A3.2") 

length(unique(a3_2$series_id))
#> [1] 7

^{Created on 2022-05-16 by the reprex package (v2.0.1)}

Thanks to Matt Crocker for reporting this issue via email

[MattCowgill]

a3_2 <- readrba::read_rba("A3.2") 

# These are the series IDs in the A3.2 spreadsheet
rba_series <- c(
  "RBASLI",
  "RBASLISIN",
  "RBASLCR",
  "RBASLMD",
  "RBASLFV",
  "RBASLT",
  "RBASWI",
  "RBASWISIN",
  "RBASWCR",
  "RBASWMD",
  "RBASWFV"
)

# These are the series IDs in the spreadsheet that are not in our tibble
rba_series[!rba_series %in% unique(a3_2$series_id)]
#> [1] "RBASLI"    "RBASLISIN" "RBASWI"    "RBASWISIN"

^{Created on 2022-05-16 by the reprex package (v2.0.1)}

[MattCowgill]

The problem is that several series in table A3.2 are non-numeric. read_rba() coerces value columns to numeric, and drops any that are NA.

[MattCowgill]

I think the conceptual problem is that this data is already 'tidy', unlike other RBA sheets. Each row is an observation, each column a variable.

[cromj006]

Thanks for taking a look Matt.

I've just discovered the same issue appears for several series in Stat Table A3 as well (e.g. for "OMO outright transaction detail" and "Bond Purchase Program"). The problem looks to be the same as the issue for A3.2 - the data is already tidied.

Sorry if you've already noticed this too.

[MattCowgill]

Thanks @cromj006! I wasn't aware of that - thanks for letting me know.

I'm torn between three options here:

1. read_rba("a3.2") returns an error, saying that table cannot be imported
2. read_rba("a3.2") returns a table that looks like the one you can open from the RBA website, with separate columns for Bond Issuer, Identifier, Coupon Rate etc
3. read_rba("a3.2") returns a table with the same columns as any other table you load using read_rba(), with the various bits of metadata (bond issuer, identifier, coupon rate, etc.) pasted together into the series column

[cromj006]

@MattCowgill option 2 sounds good to me, but I of course don't know if there would be consequences of this more broadly. Option 3 sounds like it could work too if you were somehow able to add the separate_series function from read_abs?

[MattCowgill]

thanks @cromj006. I am drawn to option 2 as well. My hesitation is just that it would return quite a different-looking tibble for A3.2 (etc) than for other RBA tables. I like the fact that read_rba() returns a tidy tibble with consistent column names, regardless of what the underlying table looks like

[MattCowgill]

After thinking about this some more, I don't like option (2) because it would return an object different to the one you usually get when you call read_rba(). So that leaves options (1) and (3)

[MattCowgill]

Tables that appear to have an issue in which the number of unique series IDs in the tibble returned by read_rba() does not equal the number of columns in the Excel sheets:

• A3
• A3.1
• A3.2
• B12.1.1
• B12.2.1
• B13.1.1
• B13.1.2
• B13.2.1
• D14.1
• F7
• F8
• F11.1
• H3
• H5