Purpose: This article provides a more streamlined and focused guide to getting performance from the Orion Reporting Scope api endpoint. See other article on Reporting Scope for a much more detailed guide to the range of solutions that can provide.
In Orion there are several levels to a portfolio. Performance can be calculated on demand for each of these levels: Household, Registration, Account, Asset, Asset Class, Asset Category and Risk Category
Simple Use Case: Firm wants to create a custom dashboard that allows a user to view Performance in a variety of ways with multiple groupings. This dashboard will call the Orion API based on the parameters entered and will retrieve the performance data for display.
Scope and Outputs: The Orion performance engine will always use the default options set for the database when calculating performance, unless overrides are specified in the POST instructions to the API.
Process Overview:
- Construct the JSON set of instructions.
- POST to the Orion /Reporting/Scope endpoint.
- Receive the Performance results data.
Process Steps:
Using the /Reporting/Scope endpoint, you can POST a json set of instructions for what portfolio record(s) you want to use, how the performance should be returned, and how the data should be grouped.
For example, you can specify 1 or more household records and request the performance to be returned grouped by Household and Account. This will return a set of performance results for the Household, plus for every account owned by that household.
Here is an example POST body message to get performance for 3 accounts. Notice the outer calculations array only has one item, a grouping by Account that itself has 2 calculations. So this will return Month-to-Date and Year-to-Date performance for each of the 3 accounts.
Code:
{
"entity": "Account",
"entityIds": [19, 20, 53],
"asOfDate": "2020-02-29",
"calculations": [
{
"id": "Accounts",
"$type": "grouping",
"grouping": "Account",
"calculations": [
{
"id": "Month-to-Date Performance",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"quickDate": "MTD"
}
},
{
"id": "Year-to-Date Performance",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"quickDate": "YTD"
}
}
]
}
]
}Notice also that in this example every calculation item has an “id” property. This property is not used by the calculation at all. It will simply be passed through to the response to make it easier for the caller to match up the numerous calculation responses with what was requested.
Here is an example of getting performance for a Household, plus all the accounts owned by the household. Notice how each level has calculation objects included. If these are omitted the performance being requested at that level will not be calculated.
Code:
{
"entity": "Household",
"entityIds": [8],
"asOfDate": "2020-02-29",
"calculations": [
{
"id": "HH Month-to-Date Performance",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"quickDate": "MTD"
}
},
{
"id": "HH Year-to-Date Performance",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"quickDate": "YTD"
}
},
{
"$type": "grouping",
"grouping": "Account",
"calculations": [
{
"id": "Month-to-Date Performance",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"quickDate": "MTD"
}
},
{
"id": "Year-to-Date Performance",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"quickDate": "YTD"
}
}
]
}
]
}And that is it.
Context Change
A note on the context change object. In the examples on this page you saw reportCategoryId is always set to 1. That is because 1 is the reporting category for performance. The report category is what the numerous managed/unmanaged settings resolve into. All the reporting categories are:
1: Performance
2: Activity Summary
4: Allocation
8: PortfolioDetail
16: TaxDetail
You will notice the examples on this page set the quickDate property to either MTD or YTD. The date these use is the asOfDate the is specified on the outermost object. The best practice with that date is to set it to whatever “today” is considered to be. If you are trying to report as of the end of last quarter it should be set to the end of last quarter. The full list of quick dates can be found here.
There are additional properties if you need more control over what date range is used. You can specify a date expression string for the start and end dates to handle many scenarios. Using a date expression you can move from the specified “asOfDate” forward (+) or backward (-) by days (d), weeks (w), month (m), quarters (q) or years (y). You can also round to the start (/) or end(\) of the week, month, quarter, or year. For example if you wanted the performance for the quarter two years ago you could do this:
{
"id": "Quarter performance for this quarter 2 years ago",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"dateRange": {
"$type": "date-range",
"startDateExpression": "-2y/q",
"endDateExpression": "-2y\\q"
}
}
}You can also specify a fixed date to date like this:
{
"id": "Mid-January to Mid-February",
"$type": "performance",
"contextChange": {
"reportCategoryId": 1,
"dateRange": {
"$type": "date-range",
"startDate": "2020-01-15",
"endDate": "2020-02-15"
}
}
}If you find that the On Demand performance is not available do to lack of transactional data, the following will provide stored performance.
Stored performance is not generated day of and will likely be 1-2 days behind the on demand performance.
Stored performance should only be used if:
A) The transactional data for that time period does not exist/is unobtainable
B) Orion and the advisor have deemed the transaction data unusable
The following endpoints will return the stored performance for the level indicated using a GET:
/v1/Reporting/BI/Performance?groupEntity=Household
/v1/Reporting/BI/Performance?groupEntity=Registration
/v1/Reporting/BI/Performance?groupEntity=Account
Below is a sample of the response. The response will be the same structure for all 3 entities (household,reg,account). The entityId refers to the Orion ID for the record. So when running for household, it is the Orion ClientID, for Account, the Orion AccountID, and for Registration, the Orion RegistrationId.
[
{
"entityId": 806,
"entityEnum": 5,
"parentId": 0,
"groupName": "Mariela Tellez",
"marketValue": 36623.25,
"day": null,
"mtd": 0.07330073552950367,
"qtd": 0.07330073552950367,
"ytd": -0.11587324032871749,
"oneYear": -0.03442694465924401,
"threeYear": 0.06943974444330814,
"fiveYear": null,
"tenYear": null,
"inception": null
},
{
"entityId": 807,
"entityEnum": 5,
"parentId": 0,
"groupName": "Mona Moussa",
"marketValue": 66720,
"day": null,
"mtd": 0.06931253862378184,
"qtd": 0.06931253862378184,
"ytd": -0.09925781412126566,
"oneYear": -0.005814441671845305,
"threeYear": 0.08011687475632388,
"fiveYear": null,
"tenYear": null,
"inception": null
},
{
"entityId": 809,
"entityEnum": 5,
"parentId": 0,
"groupName": "Angelica Alvarez",
"marketValue": 1570.73,
"day": null,
"mtd": 0.09743793973184701,
"qtd": 0.09743793973184701,
"ytd": -0.10262972971428862,
"oneYear": -0.028837316728567153,
"threeYear": 0.08426859823536258,
"fiveYear": null,
"tenYear": null,
"inception": null
},…