Statement is a document that contains summary information on agreements/reports/master agreements in the registry for a certain period of time. Client receives astatement report at the end of the operation day, if any documents were registered during the day. The statement report is also sent to the client upon request, which can be created in the Message Preparation form. To find details about statement format, refer to NSD’s trade repository messages specifications. In the Web-client statements are displayed in tables (Fig. 1), where each row contains information about one message thread: statement request→statement.
Fig. 1 – Statement form
These tables are subject to information display settings, described in section General Settings.
The Statements form contains the following information about documents:
Date – the date of the statement/report;
Party 1 – name of the company, acting as the first party to the contract, transaction, master agreement;
Party 2 – name of the company, acting as the second party to the contract, transaction, master agreement;
Name of the user’s company, for which the current user is an RA or a party MA, is written in green.
Hovering the mouse pops up a toolbar. Description of the toolbar buttons is shown in Table 1.
Table 1 – Toolbar buttons
Button | Function |
---|---|
Print statement | |
Keep the first message of the chain in the xml file | |
Add a comment | |
Mark as read | |
Mark as unread |
There are two ways to view report or statement:
Section contains information about the processing of messages.
Fig. 1 – Registration form
The Registration section contains Processing, Rejected, Requests, Registered and Pending subforms. Each form includes information about the individual registration chains – a sequence of messages between the party (reporting agent) and the repository associated with the registration of a single contract/report/master agreement. The registration of changes to the contract or master agreement is a separate chain.
The information on which registration chains contain subforms is provided in Table 1.
Table 1 – Description of the Registration section subforms
Form | Description |
---|---|
Processing | Contains chains in an idle state from the Web-client user’s viewpoint. There are two types of chains:
|
Rejected | Contains:
|
Requests | Contains incoming request chains that for the given party start with an Approval request sent by the repository. This means that the registration process was initiated by the other party and the repository sent a request for approval to the current party. If a user sends a message containing a mistake, then, according to its type, the following will happen:
|
Registered | Contains completed chains of registered documents |
Pending | Contains the electronic workflow system messages, encrypted on the party certificate and the servers of the Web-client cannot decrypt and display their contents to the user. Users must decrypt them on their own |
Chains of messages are displayed in tables. Fig. 2 shows an example of a Registered form table.
Fig. 2 – example of a Registered form table
Each row corresponds to one registration chain.
A set of columns of the main table of the registration section form table is shown in Table 2.
Table 2 – Registration chain data
Column | Description |
---|---|
Date | Date of the last message in the chain (the date of receipt of the Pending form package) |
Product | Financial instrument |
Type | Chain object |
Master agreement | Master agreement identification code |
Transaction number forparty 1 | Number of transaction assigned to the first part of the master agreement (optional) |
Transaction number forparty 2 | Number of transaction assigned to the second part of the master agreement (optional) |
Repository transaction number | Number the repository assigns when processing a transaction |
Party 1 | Name of the organization, acting as a party to the Master agreement |
Party 2 | Name of the organization, acting as a party to the Master agreement |
RA of party 1 | Name of the organization, designated the first party’s RA |
RA of party 2 | Name of the organization, designated the second party’s RA |
Сomment | Comment to the chain |
BRA of party 1 | Name of the organization, designated the first party’s BRA |
BRA of party 2 | Name of the organization, designated the second party’s BRA |
Status | Chain status. Depending on the tab can be either Processing, Rejected or Registered |
Correlation ID | Chain ID number. If the chain has child chain of changing or cancellation, the ID of this chain is displayed in the column |
To view all messages associated with the chain, click on the row in the main table. An additional table with the entire message chain will appear to the right of the main table (Fig. 3).
Fig. 3 – example of a Registered tab table
The messages that belong to a child chain are displayed in red. If the sent message hasn't been delivered to the repository then the "" element will be displayed next to the message name. When the message will be delivered the "" element will be displayed (Fig. 4). If the system has not identified which program the message was sent with (via personal user's system or the Web-client) the "" element will be displayed. Clicking on the icon or putting a mouse cursor over (Fig. 4) displays the message ID number.
Fig. 4 – the message ID number
Each message can be viewed by clicking on its name, an active link (Fig. 5).
Fig. 5 – viewing messages
During message exchange process the user receives notifications. One of them is Matching differences report. For convenience of viewing of the data the background color of rows filled by user are orange, the background color of rows filled by contractor are violet (Fig. 6).
Fig. 6 – matching differences report
Clicking on the message button you can view the file in XML-format. This format is used for importing files.
The principle of filtering data in the table described in Filter settings. In the Statement form the following filters are available: