The help says that PTM is defined as (4,TTM), but the EPSExclXorPTM factor is not always equal to EPSExclXor(4,TTM). (I haven’t checked for other factors than EPSExclXor). See this screen: https://www.portfolio123.com/app/screen/summary/154200?mt=1.
The problematic stocks all seem to report semi-annually. The PTM figure is NA, while the value of (4,TTM) is not. The (4,TTM) value is actually equal to (4,QTR) + (6,QTR) for these companies.
I don’t know if this is a bug or not, but it’s a little strange.
EDIT: NetIncBXor(1,QTR) is also not always equal to NetIncBXorPQ, so this issue does not only occur with TTM and EPSExclXor. At a glance it seems to affect the same companies.
The right answer should be NA for EPSExclXorPTM & EPSExclXor(4,TTM)
There’s a slight difference in the way pre-built factors (EPSExclXorPTM ) are calculated vs. their formula counter-parts (EPSExclXor(4,TTM)). Pre-built factors do not fallback if the implied offset is greater than 0. The formula counter part is falling back even if the offset is not 0 when the third parameter is set to FALLBACK (the default). This is not right since falling back should only allowed for the most recent period. We’ll have a fix for the formula version soon.
PS. the effect should be minimal. Under normal cases falling back with offset >0 will result in another NA. It’s more of a waste of compute cycles more than anything else. It’s mostly a problem with ADR’s since Compustat gives us alternating values and NAs due to the semi-annual reporting. In this case falling back vs not falling back results in two different values.
Thanks for the explanation, makes sense now. EPSExclXorPTM is indeed identical to EPSExclXor(4,TTM,KEEPNA) and NetIncBXorPQ is identical to NetIncBXor(1,QTR,KEEPNA).
I agree that the impact is minimal. Nevertheless, it’s a good idea to fix it and thanks for taking the time to do so.