Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Key Principles

Principle

Decision / Discussion

Status

Aggregation

  • transaction values can be aggregated to segment or portfolio level

SPECIFIED

Scope is Portfolio

  • the interface should always deliver data on the scope of a single portfolio

SPECIFIED

Currency

  • all figures are delivered in reporting currency

SPECIFIED

Benchmark Data

  • no benchmark data needed

SPECIFIED

Breakdown Segments

  • same as in Valuation

SPECIFIED


Interface "PortfolioTransaction"

Status

IMPLEMENTED

Usage & Contents

  • used to produce transaction tables (CF003)

Path

/portfolio/transactions

Parameters

portfolioId

string

The id of the portfolio (or consolidation) in the data source

startDate

string (date)

The start date the reporting is produced for

endDate

string (date)

The end date the reporting is produced for

Example call

/portfolio/transactions?portfolioId=E0002&startDate=2019-01-01&endDate=2019-03-31

Response structure

If the API can fulfill the request (response status code 200 = OK) the response must follow the below json-schema.

  • The request part of the response has to match the path and parameters used in the API call/request

  • The json schema currently excludes the schema for dataVersioning (should be designed by CSAM)

Schema

https://bitbucket.org/banknotes/ngr/src/df61b39d18a16581cd95aed9694991bbe39c5fb1/ngr-csamsolution/src/Model/schema/PortfolioTransactions.schema.json?at=release%2Fcurrent

Error handling

If the request can't be fulfilled an appropriate response status code (4xx or 5xx) must be used. Possible errors could be

  • bad request structure → expected status = 400

  • portfolioId not found or reportingDate in future → expected status = 404

  • etc.

The body of the response should contain information about the reason of the error in plain text or as json object.

Consistency rules

The following rules should be adhered to by any response and will eventually be checked when consuming a response:

  • transactions' date must be within requested date period

Reporting Business Logic

Data does not get manipulated. Filtering is out of scope.


  • No labels