You use the fields of the trade repository object to create messages to be sent to a trade repository.
Since each trade repository has its own rules governing the creation of messages, the number of fields listed here is greater than the number of fields that would be derived from the technical description for EMIR.
The following table provides an overview of the fields of the trade repository object. For each field, you can see the corresponding field under EMIR, the meaning of the field or the expected values, and how the field is filled by the delivered implementations BADII_TLR_TARO_FILL_CONTENT
and BADII_TLR_TARO_FILL_DER_CNT
.
Note
And since each trade repository has its own regulations, you can add more fields and use a BAdI to fill them with values. (To do this, you need to create your own BAdI implementation.) However, you can also use the derivation tools to change how the fields are filled so that the requirements for the relevant trade repository are met.
You can also use these fields to create trade repository messages using a different legal basis to EMIR. Given that a different legal basis may require different fields, you can add these fields and use a BAdI to fill them with values, or you can use the derivation tools to change how the fields are filled so that the requirements for the relevant trade repository are met.
Mandatory Fields in the Delivered Implementation:
In the delivered implementations, the check methods of the BAdIs check whether the following fields are filled. If one of the mandatory fields is not filled, the trade repository object acquires the status 02
Incompletely Created
.
External Trade ID or Interim Trade ID
(See also: External Trade ID and Interim Trade ID)
Counterparty ID and the related ID type
Other counterparty ID and the related ID type
The Domicile Not in Validity Area of LB
field must be filled.
If the broker ID is specified, the relevant identifier must also be filled.
If the beneficiary ID is specified, the relevant identifier must also be filled.
If the ID of the clearing party is specified, the relevant identifier must also be filled.
If the ID of the central counterparty is specified, the relevant identifier must also be filled.
Field in the Trade Repository Object | Field in EMIR | Meaning (Acc. to EMIR) | Data Filling By delivered BAdI implementations |
---|---|---|---|
Administrative Data The values in these fields are filled by SAP. You cannot change these field values. However, all of the fields can be used for the creation of trade repository messages. | |||
Company Code | Internal Data | Identifying a TARO Uniquely in the System | From Transaction Data |
Transaction | Internal Data | From Transaction Data | |
Trade Repository | Internal Data | The trade repository is derived on the basis of the settings made in the Customizing activity | |
TARO Number | Internal Data | TAROs for a financial transaction are numbered sequentially. | |
External Trade ID | Table 2, Section 2b, Field 8 | A unique ID at the European level, delivered from the reporting company. If there is no unique ID, a unique code needs to be generated and agreed upon with the counterparty for that transaction. | Value from the financial transaction, You can fill the field by using the BAdI |
Interim Trade ID | The interim trade ID is used to uniquely identify a financial transaction. You can use it in messages to the trade repository as long as no external trade ID has been officially agreed upon. If you want this field to be filled, you need to allow use of interim trade IDs in the Customizing activity The system determines interim trade IDs as follows:
The system determines the interim trade ID when the transaction is saved. Note The business partner ID is read from the business partner master data of the business partner that represents the company code. You can assign business partners to company codes in the business partner data (in the End of the note. | ||
Planned Send Date | Internal Data | The planned send date is derived from the action type of the TARO: Action Type -> Date
| |
Sending Date | Internal Data | Filled with the date on which the TARO switches to the status | |
Status (of the TARO) | Internal Data | A TARO can have the following status:
| |
Action Type | Section 2i, Field 58 |
| The action type explains the cause for a trade repository object:
The BAdI implementation derives from the action type which format tree ID is used in the
|
Comment | Internal Data | Not filled In the TARO Monitor, you can enter a comment for the TARO. | |
Investment | Internal Data | Not filled In the TARO Monitor, you can upload a file for the TARO. | |
Contract Conclusion Date | Internal Data | From Transaction Data | |
Time of Contract Conclusion | Internal Data | From Transaction Data | |
Product Type | Internal Data | From Transaction Data | |
Transaction Type | Internal Data | From Transaction Data | |
Created By | Internal Data | From Transaction Data | |
Creation Date | Internal Data | From Transaction Data | |
Last Changed By | Internal Data | From Transaction Data | |
Last Changed On | Internal Data | From Transaction Data | |
Last Changed At | Internal Data | From Transaction Data | |
Origin of Processing | Internal Data | Filled with the trade with which the table entry was changed | |
Origin of First Entry | Internal Data | Filled with the trade with which the table entry was filled for the first time | |
Trade Repository: Error Code | |||
Trade Repository: Description Error Code | |||
Sending Date | Internal Data | ||
Trade Repository Object Sent At | Internal Data | ||
Content Data | |||
| |||
Mark-to-Market Value of the Contract | Table 1, Field 17 | Mark-to-Market Value or Mark-to-Model Value of the Contract Test | The system reads the values from table VTVBAR. Here you can enter the MtM value manually using transaction |
Currency of the Mark-to-Market Value | Table 1, Field 18 | Currency of the Mark-to-Market Value | |
Last Valuated On (UTC) | Table 1, Field 19 |
| |
Last Valuated At (UTC) | Table 1, Field 20 | Time for the date of the last valuation | |
Last Valuation Type | Table 1, Field 21 | Specifies how the mark-to-market value is determined:
| Always filled by the system with |
Collateralization | Table 1, Field 22 | Provides information about whether collateralization has occurred. U = Without Collateralization PC = Partially Collateralized OC = One-Sided Collateralization FC = Fully Collateralized | Always |
Collateral Portfolio | Table 1, Field 23 | Y = Yes N = No | Not filled |
Collateral Portfolio Code | Table 1, Field 24 | Unique code for the collateral portfolio | Not filled |
Collateral Value | Table 1, Field 25 | Total Value of Collateral | Not filled |
Collateral Currency | Table 1, Field 26 | Currency of the Collateral Value | Not filled |
| |||
Counterparty | Contains the ID of the counterparty for the financial transaction. This field is used to read the unique ID (such as the BIC or LEI) from the business partner data. This ID is then stored in the derived content data (see under Note In the Customizing activity End of the note. | ||
Broker | Contains the ID of the broker for the financial transaction. This field is used to read the unique ID (such as the BIC or LEI) from the business partner data. This ID is then stored in the derived content data (see under | ||
Clearing Member | Filled with the internal ID of the counterparty for all financial transactions that have the clearing status This field is used to read the unique ID (such as the BIC or LEI) from the business partner data. This ID is then stored in the derived content data (see under | ||
Central Clearing Partner | Not filled by SAP. If you want to fill this field, you need to enter the internal ID of the central clearing partner to apply this field in the derivation of the unique ID, such as the BIC or LEI, which is then stored in the derived content data (see under | ||
External Action Type | The external action type, corresponding to its trade repository reporting legislation, such as EMIR, may possibly be required to distinguish reports to your trade repository. You must maintain relevant fields for mofications with an action type other than M in Customizing under You assign the (internal) action type and the external action type to each field. As the Trade repositories that report modifications to ESMA are divided into three subtypes:
| ||
Action Type Details | User-Defined Text Field | ||
Latest Error Message | |||
External Account | |||
| |||
Taxonomy | Table 2, Section 2a, Field 1 | Derives the value from the settings made in the Customizing activity | |
Product ID 1 | Table 2, Section 2a, Field 2 | Filled with the value of the superordinate product classification type of the product classification type assigned in the activity If you have assigned a product classification that does not have a superordinate product classification type, the value of the assigned product classification type is entered in the field. | |
Product ID 2 | Table 2, Section 2a, Field 3 | Filled with the value of the product classification type assigned in the activity If you have assigned in this activity a product classification type that does not have a superordinate product classification type, no entry is made in this field. | |
Underlying | Table 2, Section 2a, Field 4 | Not filled | |
Notional Currency 1 | Table 2, Section 2a, Field 5 | Filled with the currency of the outgoing side (if one exists). Otherwise, the field is filled with the transaction currency. | |
Notional Currency 2 | Table 2, Section 2a, Field 6 | Filled with the currency of the incoming side (if one exists). Otherwise, the field is not filled. | |
Settlement Currency | Table 2, Section 2a, Field 7 | Currency of the cash settlement flow | |
| |||
Asset Class | Not a field in EMIR, but may be required by trade repository | Derives the asset class from the product type, the transaction type, and the trade repository from the settings made in Customizing for | |
Venue of Execution | Table 2, Section 2b, Field 10 | This field is filled with the stock exchange (table
If the For all other contract types and product types, the field is filled with | |
Compression | Table 2, Section 2b, Field 11 | Not filled | |
Price | Table 2, Section 2b, Field 12 | Filled with the security price (percentage-quoted or unit-quoted) of the financial transaction. | |
Price Quotation | Table 2, Section 2b, Field 13 | Filled with | |
Notional Amount | Table 2, Section 2b, Field 14 | Filled with the payment amount of the financial transaction. | |
Price Multiplier | Table 2, Section 2b, Field 15 | Filled with | |
Quantity | Table 2, Section 2b, Field 16 | Filled with | |
Advance Payment Amount | Table 2, Section 2b, Field 17 | Filled with the payment amount of another flow that was paid in advance. | |
Currency of Advance Payment Amount | Table 2, Section 2b, Field 17 | Currency in which the advance payment was made. | |
Delivery Type | Table 2, Section 2b, Field 18 | Specifies how the contract was fulfilled: C = Cash Settlement P = Physical Exercise O = Optional for Counterparty | Derived from "Settlement" indicator. |
Execution Date (UTC) | Table 2, Section 2b, Field 19 | Filled with the date on which the contract is concluded for the financial transaction (UTC). | |
Execution Time (UTC) | Table 2, Section 2b, Field 19 | Filled with the time at which the contract is concluded for the financial transaction (UTC). | |
Validity Date | Table 2, Section 2b, Field 20 | Filled with the start of the term for the financial transaction. | |
Maturity Date | Table 2, Section 2b, Field 21 | Original maturity of the financial transaction (not the date of a premature termination/notice of the transaction) | Filled with the end of the term for the financial transaction. |
Termination Date | Table 2, Section 2b, Field 22 | Termination date of the contract. If the termination date is the same as the maturity, this field remains empty. | Filled with the OTC termination date. |
Settlement Date | Table 2, Section 2b, Field 23 | Filled with the exercise date. | |
OTC Notice Date | |||
Master Agreement Type | Table 2, Section 2b, Field 24 | Filled with the value in the | |
Master Agreement Version | Table 2, Section 2b, Field 25 | Refers to the year of the master agreement version. | The year is read from the master agreement data. |
Delegation |
The standard implementation fills the field with | ||
Nominal Currency | Is filed with the currency of the payment amount | ||
| |||
Confirmation Date (UTC) | Table 2, Section 2c, Field 26 | The date of the confirmation or counterconfirmation, depending on which is the latest. | |
Confirmation Time (UTC) | Table 2, Section 2c, Field 26 | Time relating to the date of the confirmation | |
Confirmation Means | Table 2, Section 2c, Field 27 | Specifies whether and how the contract was confirmed: Y = Non-electronically confirmed N = Non-Confirmed E = Electronically confirmed | If the confirmation date is not filled, this field is filled with the value |
| |||
Clearing Obligation | Table 2, Section 2d, Field 28 | Specifies whether the reported contract is subject to the clearing obligation.
| Derived from the clearing status of the financial transaction. If the status is |
Cleared | Table 2, Section 2d, Field 29 |
| Derived from the clearing status of the financial transaction. Accepted = |
Clearing Date (UTC) | Table 2, Section 2d, Field 30 | Time when the clearing partner accepted clearing. | Date when the clearing partner accepted clearing. |
Clearing Time (UTC) | Table 2, Section 2d, Field 30 | Time when the clearing partner accepted clearing. | |
ID of the Central Counterparty | Table 2, Section 2d, Field 31 | BIC or LEI of the Central Counterparty | Not filled |
Intragroup | Table 2, Section 2d, Field 32 | Specifies whether the transaction is an intragroup transaction.
| Filled with the value |
| |||
Fixed Rate of Leg 1 | Table 2, Section 2e, Field 33 | Filled with the percentage of the condition. | |
Fixed Rate of Leg 2 | Table 2, Section 2e, Field 34 | Filled with the percentage of the condition. | |
Daily Calculation of Fixed Rate Leg 1 | Table 2, Section 2e, Field 35 | Filled with the interest calculation method of the condition of the financial transaction Leg 1. | |
Daily Calculation of Fixed Rate Leg 2 | Table 2, Section 2e, Field 35 | Filled with the interest calculation method of the condition of the financial transaction Leg 2. | |
Payment Frequency of Fixed Rate Leg 1 | Table 2, Section 2e, Field 36 | Filled with the payment frequency of the condition in months or days. | |
Payment Frequency of Fixed Rate Leg 2 | Table 2, Section 2e, Field 36 | Filled with the payment frequency of the condition in months or days. | |
Variable Interest Payment Frequency Leg 1 | Table 2, Section 2e, Field 37 | Filled with the payment frequency of the condition in months or days. | |
Variable Interest Payment Frequency Leg 2 | Table 2, Section 2e, Field 37 | Filled with the payment frequency of the condition in months or days. | |
Variable Interest (Adjustment) Frequency Leg 1 | Table 2, Section 2e, Field 38 | Filled with the payment frequency of the interest adjustment condition in months or days. | |
Variable Interest (Adjustment) Frequency Leg 2 | Table 2, Section 2e, Field 38 | Filled with the payment frequency of the interest adjustment condition in months or days. | |
Daily Calculation of Variable Interest Leg 1 | Table 2, Section 2e, Field 35 | Filled with the interest calculation method of the condition of the financial transaction Leg 1. | |
Daily Calculation of Variable Interest Leg 2 | Table 2, Section 2e, Field 35 | Filled with the interest calculation method of the condition of the financial transaction Leg 2. | |
Floating Rate of Leg 1 | Table 2, Section 2e, Field 39 | Reference Interest Rate of Condition Leg 1 | |
Floating Rate of Leg 2 | Table 2, Section 2e, Field 40 | Reference Interest Rate of Condition Leg 2 | |
Internal Daily Calculation of Fixed Interest Leg 1 | |||
Internal Daily Calculation of Fixed Interest Leg 2 | |||
Internal Daily Calculation of Variable Interest Leg 1 | |||
Internal Daily Calculation of Variable Interest Leg 2 | |||
| |||
Currency 2 | Table 2, Section 2f, Field 41 | Filled with the following currency. | |
Exchange Rate 1 | Table 2, Section 2f, Field 42 | Filled with the spot rate of the transaction. | |
Forward Rate | Table 2, Section 2f, Field 43 | Filled with the forward rate of the transaction. | |
Exchange Rate Basis | Table 2, Section 2f, Field 44 | The currency pair | |
| |||
Commodity Base | Table 2, Section 2g, Field 45 | Identifies the type of the underlying commodity: AG = Agricultural EN = Energy FR = Freight ME = Metals IN = Index EV = Environmental EX = Exotic | The system fills this field with data from the commodity master data (transaction 001 Metals -> ME 002 Base Metals -> ME 003 Inferior Metals -> ME 004 Grains -> AG 005 Oilseeds -> AG 006 Livestock -> AG 007 Softs -> AG 008 Energy -> EN 009 Electricity -> EN 010 Gas -> EN 011 Oil -> EN 012 Weather -> EV |
Commodity Details | Table 2, Section 2g, Field 46 | Details of the particular commodity beyond field 45. Agricultural Economy GO = Grains/Oilseeds DA = Dairy LI = Livestock FO = Forestry SO = Softs Energy OI= Oil NG = Natural Gas CO = Coal EL = Electricity IE= Inter-Energy Metals PR = Precious Metals NP = Non-Precious Metals Environment WE = Weather EM = Emissions | The system fills this field with data from the commodity master data (transaction 001 Metals -> NP 002 Base Metals -> NP 003 Inferior Metals -> NP 004 Grains -> GO 005 Oilseeds -> GO 006 Livestock -> LI 007 Softs -> SO 008 Energy -> EL 009 Electricity -> EL 010 Gas -> NG 011 Oil -> OI 012 Weather -> WE |
Delivery Location | Table 2, Section 2g, Field 47 | Not filled | |
Interconnection Point | Table 2, Section 2g, Field 48 | Not filled | |
Load Type | Table 2, Section 2g, Field 49 | Not filled | |
Delivery Start Date | Table 2, Section 2g, Field 50 | Not filled | |
Delivery Start Time | Table 2, Section 2g, Field 50 | Not filled | |
Delivery End Date | Table 2, Section 2g, Field 51 | Not filled | |
Delivery End Time | Table 2, Section 2g, Field 51 | Not filled | |
Contract Capacity | Table 2, Section 2g, Field 52 | Not filled | |
Unit of Measure | Table 2, Section 2g, Field 53 | Not filled | |
Price Time Interval Quantities | Table 2, Section 2g, Field 54 | Not filled | |
| |||
Option Type | Table 2, Section 2h, Field 55 | Displays whether the contract is a put or a call. | Derived from the "Put/Call" indicator set for the financial transaction:
|
Option Style | Table 2, Section 2h, Field 56 | Provides details about how the option is exercised: A = American B = Bermudan (multiple exercise times) E = European S = Asian | Derived from the option style of the financial transaction: 1 European -> E 2 American -> A |
Strike Currency | Table 2, Section 2h, Field 57 | Filled with the strike currency. | |
Strike Price | Table 2, Section 2h, Field 57 | Filled with the strike amount of the option. | |
| |||
Counterparty ID | Table 1, Field 2 | Identifier of the reporting company LEI or BIC or an interim entity identifier or a client code | Not filled by SAP |
Counterparty ID Identifier | The abbreviation specifies which ID code applies. Examples:
| ||
ID of the Other Counterparty | Table 1, Field 3 | Identifier of the other business partner LEI or BIC or an interim entity identifier or a client code | LEI, BIC, and so on, of the counterparty Note In the Customizing activity End of the note. |
Other Counterparty ID Identifier | The abbreviation specifies which ID code applies. Examples:
| ||
Counterparty Name | Table 1, Field 4 | Not filled | |
Counterparty Domicile | Table 1, Field 5 | Not filled | |
Corporate Sector of the Counterparty | Table 1, Field 6 | Not filled | |
Counterparty Financial Sector | Table 1, Field 7 | Display whether the reporting company is a financial or non-financial counterparty (NFC).
| Not filled |
Broker ID | Table 1, Field 8 | If the broker involved is not a business partner. | Filled when the transaction has a partner in this role assigned on the |
Identifier of the Broker ID | The abbreviation specifies which ID code applies. Examples:
| ||
ID of the reporting entity | Table 1, Field 9 | If the entity that is required to report has delegated communication of the message to a third party, this field must be filled with the LEI or the BIC of the reporting entity. | Not filled |
Identifier for the ID of the reporting entity | The abbreviation specifies which ID code applies. Examples:
| ||
Clearing Member ID | Table 1, Field 10 | If the reporting entity is not a clearing member, the LEI or BIC of the relevant clearing member needs to be entered here. | The system fills this field with the counterparty of the financial transaction (= counterparty of the clearing account) for all financial transactions for which clearing has been performed. |
Identifier of the Clearing Member ID | The abbreviation specifies which ID code applies. Examples:
| ||
Beneficiary ID | Table 1, Field 11 | LEI or BIC of the party subject to the rights and obligations arising from the contract when this party is not a counterparty of this contract. | Not filled |
Identifier of the Beneficiary ID | The abbreviation specifies which ID code applies. Examples:
| ||
Trading Capacity | Table 1, Field 12 | Specifies whether the reporting business partner has concluded the financial transaction as the principal (P) or as the agent (A). | Always filled with |
Counterparty Side | Table 1, Field 13 | Specifies whether the contract is a buy or a sell.
| This field is filled on the basis of the value of the transaction category of the financial transaction:
|
Domicile Not in Validity Area of Legal Basis | Table 1, Field 14 | Specifies whether the other counterparty is domiciled outside the EU.
| Filled with To fill the field, the system applies the settings made in the Customizing activity |
Linked to Commercial Activity | Table 1, Field 15 | Provides information about whether the transaction is linked directly with exercising the commercial activity or whether it is purely a financial transaction. If the reporting entity is a financial counterparty, the field must remain empty.
| Filled with |
Clearing Threshold | Table 1, Field 16 | Provides information about whether the reporting company is above or below the clearing threshold.
| Not filled |
Derived Content Data | |||
You can use the derived content data structures for your own fields. You can fill the fields using the BAdI and the derivation tool provided. |