Annex G ITL Administrator Application

Transcription

1 Annex G ITL Administrator Application Table of contents Table of contents System Overview Technical Architecture Security ITL Menu Core Functionality Actions and Security for Each Module Navigation and Usability Sorting Data in Grids Filters Referential Integrity and Required Elements Home Page and Login Module Queue Management Registry Management Registry Information Registry Information Actions Add a Registry Editing a Registry Registry Status Actions Eligibility Eligibility Actions Registry Eligibility Filter Government Accounts Government Account Actions Government Account Filter Registry Running Totals Editing Running Totals for a Manual Intervention Viewing Running Totals History Running Totals Filter Supplemental Trading Programs Transaction Management Transaction Log Actions Transaction Filter Unit Block Information Editing a Unit Block Unit Block Actions Unit Block Filter Reconciliation Snapshots Inconsistent Blocks Reconciliation Totals Reconciliation Unit Blocks Reconciliation Audit Trail Manual Intervention Reconciliation Actions Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-1

2 Reconciliation Filter Log Management Log Filters Projects Project Actions Project Filter Notifications Adding a Notification Notification Follow-up Notification Actions Notification Filter Jobs Reconciliation Jobs Administration Jobs User administration Security Actions Security Filter Identifier Codes and Lookup Tables Identifier Code Actions Identifier Code Filter Import Data Change Management Change Management Actions Change Management Filter System Management Tickler Tickler Actions Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-2

3 List of Figures Figure 1: ITL System Administrator Roles (example)...5 Figure 2: Access Codes for Security...6 Figure 3: Menu structure and privileges (example)...6 Figure 4: Action Icons...7 Figure 5: Example of Save Action...8 Figure 6: Suggested Basic Template Navigational Properties...9 Figure 7: ITL AA Login Screen (example)...10 Figure 8: Home Page of the ITL AA (example)...11 Figure 10: Registry Information (example)...12 Figure 11: Add a Registry (example)...13 Figure 12: Edit a Registry (example)...14 Figure 13: View and Change Registry Status (example)...15 Figure 16: Eligibility Requirements (example)...16 Figure 17: Registry Eligibility Filter (example)...16 Figure 18: Government Account (example)...17 Figure 19: Registry Government Filter (example)...18 Figure 20: Registry Running Totals (example)...19 Figure 21: Editing Running Total Warning (example)...20 Figure 22: Running Totals History (example)...20 Figure 23: Running Totals Filter (example)...21 Figure 24: Adding a Registry to a Supplemental Trading Program (example)...22 Figure 25: Trading Program Filter (example)...22 Figure 29: Transaction Log with Transaction Log History Detail (example)...23 Figure 30: Transaction Log with Block Detail (example)...24 Figure 31: Transaction Filter (example)...25 Figure 32: Unit Block Information (example)...26 Figure 33: Unit Block Detail (example)...27 Figure 34: Editing a Unit Block Warning (example)...28 Figure 35: Unit Block Filter (example)...29 Figure 36: Reconciliation Log Screen (example)...30 Figure 37: Snapshot Grid (example)...31 Figure 38: Snapshot Filter (example)...31 Figure 39: Inconsistent Blocks (example)...32 Figure 40: Reconciliation Totals (example)...32 Figure 41: Reconciliation Unit Blocks (example)...33 Figure 42: Reconciliation Audit Trail (example)...33 Figure 43: Manual Intervention Screens (example)...34 Figure 44: Reconciliation Log (example)...35 Figure 45: Log Management with Audit Log Detail (example)...37 Figure 46: Message Log Detail (example)...38 Figure 47: System Log Detail (example)...38 Figure 48: Routing Log Detail (example)...39 Figure 49: Audit Log Filter (example)...40 Figure 50: Message Log Filter (example)...40 Figure 51: System Log Filter (example)...41 Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-3

4 Figure 52: Routing Log Filter (example)...41 Figure 53: Project Grid with New Project Detail (example)...42 Figure 54: Adding a Project Action (example)...43 Figure 55: Project Filter (example)...44 Figure 56: Notification Home Page (example)...45 Figure 57: Creating a New Notification (example)...45 Figure 58: Notification Filter (example)...46 Figure 59: Reconciliation Job Grid (example)...47 Figure 60: Job with Job Detail Form (example)...49 Figure 62: Identifier Table with Detail of Table and Add Action (example)...51 Figure 63: List of Identifier Tables...52 Figure 65: Change Management with Add Version Change (example)...54 Figure 66: Tickler Grid with Add Tickler action (example)...55 Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-4

5 1. System Overview The ITL Administrative Application (ITL AA) is the administrative tool that provides the ITL manager the capability to review logs and manage back-end administrative processes. This tool is designed for a small number of users: a primary ITL administrator, and a limited number of alternate administrators. The application should be secured because it has the capability to manipulate data within the ITL database. All figures in this document are indicative. 1.1 Technical Architecture The ITL AA will be developed as a Web application. The specifications within this document are not limited to a specific platform. The ITL schema is the application level database that stores all information needed for the support and implementation of the International Transaction Log (ITL). See Annexes B and C for further information on the ITL database design. 1.2 Security Use of the ITL AA will be limited to a secure group of users. Users of the ITL AA will have access through their personal ITL account and password as defined in Section of the ITL Software Specification. The application will enforce at least three levels of security roles. The table below suggests one way of assigning privileges to roles. This example will be used throughout this document. It will be possible to define additional roles and to assign different sets of privileges to roles as defined in Section of the ITL Software Specification. This flexibility is necessary to reflect organizational changes within the Secretariat. Figure 1: ITL System Administrator Roles (example) Role System Administrator (SA) Registry Administrator (RA) Auditor (A) Privileges Has authority to manage logs, review ongoing transactions, create and manage users and resolve discrepancies. Has authority to assist registries with initialization and startup procedures. Has the authority to review reconciliation logs and perform manual intervention tasks to correct data problems. Has the authority to start reconciliation batch jobs Ability to review any log or report, but cannot perform any database transactions. There will likely be only one ITL System Administrator with an alternate as backup. Each ITL AA user can have more than one role and acquires the total rights within each role. The ITL System Administrator has the capability to manage these roles. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-5

6 1.3 ITL Menu The basic layout of forms for the ITL AA is a left framed main menu with child menus associated within each parent menu. Access to these menus depends on the roles of a user and the privileges associated with the roles. Menu items which a user is not allowed to access should be disabled and displayed in a different style. The following table shows an example how the menu structure could look like and how privileges to use the underlying functionality could be assigned to roles. Figure 2: Access Codes for Security Access Code CRUD CU U R Description of Access Full access; add, edit and delete Add and edit Edit only Read only Parent Menu Figure 3: Menu structure and privileges (example) Child Menu System Admin Registry Admin Queue Management - R R R Registry Management Registry Information CRUD R R Initialization CRUD CU R Eligibility CRUD CU R Government Accounts CRUD CRUD R Running Totals CRUD CU R Supplemental Trading Programs CRUD CU R Transaction Management Transaction Log U U R Unit Block Information U U R Reconciliation Reconciliation Log R R R Snapshots R R R Manual Intervention CRUD CU - Log Management - R R R Projects Project Information CRUD CU R Project Action CRUD CU R Notifications - CRUD CU R Jobs Reconciliation CRUD CU - Auditor Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-6

7 Parent Menu Child Menu System Admin Registry Admin Administrative Jobs CRUD R - Security - CRUD R R Identifier Codes - CRUD R R Import Data - CRUD - - Change Management - CRUD R R System Management Tickler CRUD R R Auditor 2. Core Functionality The ITL AA uses a series of grids and filters that allow the administrator to manage the ITL application data. The application is divided into modules, each module may have one or more forms associated with it. Each module contains the functionality to perform several actions. Some of these actions are shown in the table below along with the icon that represents the action. These icons are shown throughout the screen designs. Figure 4: Action Icons Icon Action Description Add Edit Delete View Download Add a new record to table. Edit an existing record in table. Delete a record from the grid. View details of the record without editing record. Extract and download a portion of the data in the grid as specified by the filter criteria. Options for this function allows the users to specify data to be exported in CSV (comma delimited text), HTML or XML format. 2.1 Actions and Security for Each Module Modules are accessible based on the privileges assigned to a user s security roles. In addition, the ability to perform certain actions within a module is also restricted by the privileges assigned to a user s security role. In this document for each module the basic functionality and relevant business logic are described. In addition, the actions that are available on each screen are identified. The screen designs show all the actions available. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-7

8 2.2 Navigation and Usability The user is expected to use either the back button (if using a browser for this application) or to use the menu to navigate back to previous pages. All "Save" actions refresh the page and do not navigate to another page. A timestamp and editorial comment that the data have been committed are displayed in the relevant grid or the detail frame. See Figure 5 for an example of this action. All "Cancel" actions clear the page of any changes and restore the original data if the user has not already submitted data to be saved. No pages should be cached, but refreshed each time a user returns, reflecting the latest data changes that have occurred in subsequent pages. Figure 5: Example of Save Action Status Saved Successfully - 11:38:47 AM Registry Status: Date of Change : Full Operation 15-Jan-05 DD-Mon-YY In most cases, there are action buttons below a parent form. When clicked, these action buttons display a grid of child record information. These child grids often have additional actions buttons. By clicking on these action buttons, the space below the grid shows the form that allows the user to perform that action. See Figure 6 for an example of a parent form with a child grid and a child grid action displayed in one frame. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-8

9 Figure 6: Suggested Basic Template Navigational Properties Parent Grid Column Headings: Single Column Sort Capabilities with Column Heading Click Main Selection Main Selection Sub Menu Sub Menu Main Selection Sub Menu Sub Menu Parent Entity Record Child Relationships Area Menu Selection - Parent Records Actions Column 1 Column 2 Column 3 Column 4 Parent Record Action Icon Area Parent Record - Selected Action Parent Grid of Data Parent Record Attributes Parent Table Functions: Add, Filter and Other Parent Table Specific Functionality Parent Record Functions: Completion of Parent Record Action: Save, Cancel Child Grid Column Headings: Single Column Sort Capabilities with Column Heading Click Child Records Actions Column 1 Column 2 Column 3 Column 4 Child Record Action Icon Area Child Grid of Data Child Table Functions: Add, Filter and Other Child Table Specific Functionality Child Record - Selected Action Child Record Attributes Child Record Functions: Completion of Child Record Action: Save, Cancel Sorting Data in Grids 2.3 Filters Every grid includes column headers that allow the user to sort the data in these columns by clicking the small ascending or descending triangle in the column header. By clicking on the " " on the column heading, the sort order is reversed. Only one column can be sorted at a time. Should the user download the data, it will be constructed in the sort order that appears in the grid. All grids have search capabilities through the use of filters. Many of these filters are reused throughout the application. Once a filter has been set, it remains in effect until the user clears or resets the filter. For example, once any of the filters that contain a registry selection have been set to "Spain," all screens and grids that utilize the registry data will be preset to "Spain" until the user clears the filter. All filters include the capability to either match the filter conditions or hide the filter conditions. A user can filter for a particular status code and then click the "Hide Matches" to exclude those records from the search filter. Unless otherwise stated, all filters by default are executed as "AND" conditions (e.g., REGISTRY_CODE = "SP" and STATUS_CODE = "1"). Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-9

10 2.4 Referential Integrity and Required Elements On all forms in which a user is adding or editing a record, required fields are identified with a small red asterisk to the right of the text or combo box. If the user fails to provide this information and saves the record, the action is rejected and the user is prompted that required data have not been provided. 2.5 Home Page and Login Module The Home page is accessible when a user logs into the application. Figure 7 shows an example of an ITL AA login screen. The current version number of the ITL AA and the Data Exchange Standards (DES) is displayed on the login page. Additionally it must be displayed in which environment the ITL AA runs: live, initialization or test. Passwords are entered as encrypted strings. Figure 7: ITL AA Login Screen (example) ITL Administrative Application ITL Administrator Version 1.0 DES Version 1.2 Type in your account and password below : Account: Password : ITL ********** Login Once a user has logged into the application, the user has access to the home page (Figure 8). The menu items shown to a user are dependent on the privileges assigned to the user s security roles. The user s security account and roles are displayed in the upper right hand header frame. Information about approaching deadlines is shown in the center frame. The information in this frame is driven by the TICKLER table. The tickler data includes approaching dates and activities. The tickler data will be displayed in descending order. For further information on the Tickler module, see Section Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-10

11 Figure 8: Home Page of the ITL AA (example) Home Logout Documentation System Information Queue Management Registry Management Registry Information Initialization Eligibility Government Accounts Running Totals Supplemental Trading Programs Registry Contacts Transaction Management Transaction Log Unit Block Information Reconciliation Reconciliation Log Snapshots Manual Intervention Log Management Projects Project Information Project Action Notifications Jobs Reconciliation Administrative Jobs Security Identifier Codes Import Data Change Management System Management Tickler STL Checks Reports Registry Units Transaction Yearly Aggregated Data Reconciliation Notifications Administrative Projects ITL Administrative Application Today: 30 October, 2004 ITL Administrative Application Outstanding Units All outstanding units are identified and a report is sent to C+A administrator. 31 December, 2004 Initialisation Deadline for EU Trade Scheme Registries participating in the EU trade scheme must complete initialisation tests. User ID: cgf Security Level: System Administrator 2.6 Queue Management Authorized users must be able to monitor and manage the ITL message queues. They must be provided with current detailed information about the number of pending messages in each queue and detailed information about each pending message. Also statistics about errors and the performance of the queue processing must be provided. Management of queues includes prioritizing queues and deferring the processing of queues. If 3 rd party software is used to implement, configure and monitor the Communications Hub then there is no need for a queue management module within the ITL AA. This is based on the assumption that the ITL Administrator will get sufficient access to the queue management software as part of the 3 rd party software. If no 3 rd party product is used then the queue management module must provide the necessary functions. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-11

12 2.7 Registry Management The Registry Management module has the following main functions: Basic core information regarding a registry (this Section); Recording of eligibility requirements (Section 2.9); Management of registry government accounts (Section 2.10); Recording of running totals (Section 2.11); Allocations for other data sources and trading scheme participation for a registry (Section 2.12) Registry Information The registry information page is also the Registry Management default page when the user clicks the parent menu link. The screen consists of a grid of all current registries and their current status. Once the user has selected a registry, all registry filters within this module are preset to that registry code. Figure 10 shows the parent grid of the registry home page. Figure 10: Registry Information (example) Registries Add Actions Registry Current Status Most Recent Status Date Austria Full Operation 5-Jun-05 Belgium Full Operation 4-Jun-05 France Full Operation 1-Jan-05 Spain Reconciliation Only 17-Jun-05 Sweden Not Operating 19-Jun Registry Information Actions The actions available on this form are "Add", Delete, "Edit" and "View." The Delete function is not enabled if there is child data for the registry in the database Add a Registry When adding a new registry to the REGISTRY table, checks are performed to prevent a duplicate registry from being added. Checks also prevent a registry's production and test Web service URLs from being duplicated. Required fields are indicated with a red asterisk. Additional fields may be necessary. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-12

13 Figure 11: Add a Registry (example) Add a Registry Registry Code: Registry Name: Web Service URL: Web Service Port: Test Web Service URL: Test Web Service Port: Type New Registry Name Here * * Initial Registry Status: Status Date: 05-Jun-05 DD-Mon-YY * * Save Cancel Editing a Registry Figure 12 shows the functionality available for editing a registry entry. The top form shows the detail information for a registry including production and test URLs for Web services. Additional information may be necessary. The most recent registry status and date/time of change is displayed. The status and status date/time are read-only when in edit mode and require the user to select the "View Status History" button to change the current status of a registry. See Figure 13 for the Status Change form. A change of registry status creates an entry into the REGISTRY_STATUS_HISTORY table. Clicking the "View Status History" button will display a read-only grid in descending order of all status history records to date. A registry cannot have duplicate REGISTRY_STATUS_CODEs with the same date. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-13

14 Figure 12: Edit a Registry (example) Registry Saved Successfully - 11:38:47 AM Registry Name: Sweden Web Service URL: Web Service Port: 443 Test Web Service URL: Test Web Service Port: Current Registry Status: Status Date: 80 Full Operation 15-Jan-05 DD-Mon-YY Save Cancel View Status History Registry Status Actions The action available on this form is "Change Status". There is no filter for the Registry Status grids. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-14

15 Figure 13: View and Change Registry Status (example) Registry Status History - Sweden Change Status Status Temporarily Restricted Not Operating Date of Change 06-Jul Jun-04 Status Saved Successfully - 11:38:47 AM Registry Status: Date of Change: Full Operation 15-Jan-05 * * DD-Mon-YY Save Cancel 2.9 Eligibility In addition to a registry passing initialization tests, a registry must meet other criteria to be eligible to participate in trading. These eligibility requirements are recorded in the REGISTRY_ELIGIBILITY table and contain the date and eligibility criteria that had been met. The data is needed by certain transaction checks. When a new registry is being added, the user may create the appropriate set of eligibility records and set the initial status to "unknown." The approval source identifies the individual that approved or disapproved the eligibility requirement Eligibility Actions Checks prevent two entries for the same approved eligibility criteria for the same or overlapping time periods. A criterion with any status other than unknown must have a begin date. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-15

16 Figure 16: Eligibility Requirements (example) Eligibility - Austria Add Download Filter Approval Begin End Actions Criteria Status Source Date Date Kyoto Party Approved ITL 03-Jun Dec-05 National Registry Approved Approved ITL 01-Jun Dec-04 Emissions Estimation Protocol Unknown ITL 12-May-05 Add Eligibility Status Criteria: Eligibility Status: Begin Date: to DD-Mon-YY Approval Source: Assigned Amount Calculation Approved * * * Save Cancel Registry Eligibility Filter The Registry Eligibility filter allows the user to select on Registry, Eligibility Criteria, Eligibility Status and any combination of these criteria in which the action occurred within a specific date range. See Figure 17. Figure 17: Registry Eligibility Filter (example) Selected Registry: Sweden Eligibility Criteria: Status: Kyoto Party Approved Date Performed: 03-Jun-05 to DD-Mon-YY Clear Show Matches Hide Matches Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-16

17 2.10 Government Accounts The registry must submit the account numbers and Commitment Period for their retirement, cancellation and replacement accounts as specified in Section 9.11 of the DES. The data is needed by certain transaction checks within the ITL. These data may be submitted and loaded through the data import module or can be manually entered through this interface. These data are stored in the GOVERNMENT_ACCOUNT table. Figure 18 displays the basic functionality for adding or editing a government account for a registry. Figure 18: Government Account (example) Government Accounts - Sweden Add Download Filter Account Registry Account Actions Number Government Account Type SE678 Retirement 1 Retirement First SE543 Retirement - 2 Retirement Second SE234 Retirement 3 Retirement Third SE235 tcer Cancellations Cancellation First SE453 tcer Replacement Failure tcer Replacement Account for Expiry First Commitment Period SE509 tcer Replacement Failure lcer Replacement Account for Reversal of Storage Second Edit Government Submit Account Cancel Account Number : Account Name: Account Type: Commitment Period: SE678 Retirement 1 Retirement First Commitment Period * * * Save Cancel Government Account Actions Accounts may be deleted only if there are no account IDs present in the Transaction Unit Block table. Checks prevent duplicate accounts, duplicate account IDs, or more than one retirement account for a registry for a Commitment Period Government Account Filter The Government filter allows the user to select on registry, account type, Commitment Period and a like search on account name. All text boxes are treated as like searches where the text specified is treated as a CONTAINS search pattern. See Figure 19. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-17

18 Figure 19: Registry Government Filter (example) Registry: Sweden Account Number: Account Name Like: Account Type: Commitment Period : tcer tcer Replacement Account for Expiry First Clear Show Matches Hide Matches 2.11 Registry Running Totals Due to the volume of data stored and processed in the TRANSACTION_BLOCK table, determining running aggregate values for unit blocks is process intensive. To minimize calculation processing time and to store values received from other data sources, these running totals and aggregate sums of unit data are stored in the REGISTRY_UNIT_SUM table. The aggregate values in this table can be added, edited or deleted. In general, those values in which the data source is the ITL must not be edited as the system automatically adjusts these totals and updates the history file whenever a transaction is processed. When the data are input from another data source such as the CDM or C&A database, these values may be entered manually (or updated through remote procedures) and will not have a supporting transaction history record in the Registry_Unit_Total_History table. The history records are for the levels that change with transactions. Editing the running total for the Commitment Period Reserve Limit may trigger a notification to be sent to the affected registry. If the CPR was revised upwards and the registry no longer holds enough units to comply with the limit, a Commitment Period Reserve notification (type 7) will be sent. The notification will indicate how many units the registry must acquire in order to be in compliance with the new limit (see CPR_Change function in Annex E). Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-18

19 Figure 20: Registry Running Totals (example) Registry Running Totals Time Period Data Computation Total Unit Last Action Actions Registry Period Value Source Type Units Type Date Sweden Sweden CP CP 1 1 C&A C&A Reserve Limit Unit Type Issuance Level 2,000 5,200 AAU AAU 07-Jul Jun-07 Sweden CP 1 C&A Unit Type Issuance Level 7,200 RMU 04-May-08 Sweden CP 1 C&A Converted Level 6, Sep-08 Edit Running Total Registry Name: SWEDEN * Last Action Date: 07-Jul-08 Period Value: 1 LULUCF Code: Time Period : Data Source: CP ITL * Total Units: Linked to Project: 2,000 Unit Type: AAU Computation Type : Reserve Limit * Save Cancel View History Editing Running Totals for a Manual Intervention If a Reconciliation Manual Intervention requires an adjustment to the running total due to a corrective action taken by the ITL administrator, a history record will not be created with a corresponding transaction ID, since a transaction has not occurred. Any time the user tries to edit a record in which the data source is the ITL, the user will be warned to track these changes through the Reconciliation Manual Intervention Interface. In general, manual adjustment to the running totals should be avoided. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-19

20 Figure 21: Editing Running Total Warning (example) Running Totals - Edit You are about to edit critical data in the REGISTRY _UNIT_SUM table. This is not recommended unless it is necessary to correct a transaction as part of the reconciliation process. You must track this change through manual intervention to record and acknowledge the corrective actions performed. Continue Cancel Viewing Running Totals History The user can review each transaction that modified a running total by clicking the "View History" button. This will show a read-only grid of the records in the REGISTRY_UNIT_TOTAL_ HISTORY table that are associated with the REGISTRY_UNIT_SUM record. The "Net Result" figure should calculate the sum of the original value plus the sum of the adjusted value. See Figure 22 for details. Figure 22: Running Totals History (example) Download Original Adjusted Transaction Transaction Value Value Date ID Notification ID Jul-08 SE Jul-08 SE Jul-08 SE Jul-08 SE140 Net Result of Running Total Running Totals Filter The Running Totals filter allows the user to select on registry, data source, time period and time period value, unit type, computation type and any combination of these criteria in which the action occurred within a specific date range. See Figure 23. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-20

21 Figure 23: Running Totals Filter (example) Selected Registry: Sweden Computation Type : Time Period : Reserve Limit CP Period Value: Data Source: 1 ITL Begin Date: End Date: DD-Mon-YY Clear Show Matches Hide Matches 2.12 Supplemental Trading Programs A registry may participate in other trading arrangements in addition to the Kyoto Protocol. Clicking the "Supplemental Trading Program" menu option displays a grid that shows the trading schemes in which the registry is participating. These data are stored in the REGISTRY_TRADING_SCHEME table. Figure 24 shows the display details of a user clicking the "Add" action. Checks prevent a registry from having duplicative trade schemes records. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-21

22 Figure 24: Adding a Registry to a Supplemental Trading Program (example) Supplemental Trading Programs - Sweden Add Download Filter Actions Trading Program Participating Date European Commission GHG Trading Asian Commission 01-Jun Jun-06 New Trading Program Trading Program : * Date Participating: DD-Mon-YY * Save Cancel The actions on this grid are "Add," "Edit" and "Delete." The Trading Program filter allows the user to select on registry, trading program or any combination of these criteria in which the action occurred within a specific participating date range. See Figure 25. Figure 25: Trading Program Filter (example) Selected Registry: Sweden Trading Program : European Commission GHG Trading Participating Date: to DD-Mon-YY Clear Show Matches Hide Matches 2.14 Transaction Management The core of the ITL system is the tracking of all transactions that are in process. The user can toggle between two basic views, the transaction log details and the transaction block details. Due to the volume of data for these tables, the grid defaults to transactions that have occurred in the last 24 hours. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-22

23 The data displayed in this grid are derived from the TRANSACTION_LOG, TRANSACTION_STATUS_CODE, SUPP_TRANSACTION_TYPE_CODE and TRANSACTION_TYPE tables. Figure 29 shows the transaction log grid with the transaction log history tables toggled showing data from the TRANSACTION_LOG_HISTORY table. Figure 29: Transaction Log with Transaction Log History Detail (example) Transaction Log Download Filter Select ID SE101 SE523 SE301 BE411 SE412 Trans Type Issuance Conversion Issuance Issuance Retirement Supp Trans Type 54 Acquiring Registry SE SE SE BE SE Acquiring Account Type Holding Holding Holding Operator Holding Retirement Acquiring Account ID SE2000 Transferring Registry SE SE SE BE SE Transferring Account Type Holding Holding Transferring Account ID Transaction Date & Time 06-Jun-05 09:14:12 06-Jun-05 09:14:18 06-Jun-05 09:14:35 06-Jun-05 09:15:03 06-Jun-05 09:15:12 Most Recent Status Proposed Terminated Proposed Checked-No Discrepancy Checked-No Discrepancy View Block Detail View Transaction Log History Transaction Log History - Transaction SE523 Status Proposed Checked Discrepancy Terminated Status Change Date 12-May-05 12:37:52 PM 12-May-05 12:40:30 PM 12-May-05 12:47:52 PM If the user selects the Block Detail view, the details of the units involved are displayed in the child grid. This data are derived from the TRANSACTION_BLOCK, LULUCF_CODE, ACCOUNT_TYPE_CODE, COMMITMENT_PERIOD_CODE, REGISTRY and UNIT_TYPE_CODE tables. Any checks performed on this transaction shows in the unit block history grid below the unit block grid. This unit block history grid shows all records in the TRANSACTION_BLOCK_HISTORY table. Figure 30 shows the Transaction Log grid with block Details shown in the subsequent child grids. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-23

24 Figure 30: Transaction Log with Block Detail (example) Transaction Log Download Filter Select ID SE101 SE523 SE301 BE411 SE412 Trans Type Issuance Conversion Issuance Issuance Retirement Supp Trans Type 54 Acquiring Registry SE SE SE BE SE Acquiring Account Type Holding Holding Holding Operator Holding Retirement Acquiring Account ID SE2000 Transferring Registry SE SE SE BE SE Transferring Account Type Holding Holding Transferring Account ID Transaction Date & Time 06-Jun-05 09:14:12 06-Jun-05 09:14:18 06-Jun-05 09:14:35 06-Jun-05 09:15:03 06-Jun-05 09:15:12 Most Recent Status Proposed Terminated Proposed Checked-No Discrepancy Checked-No Discrepancy View Block Detail View Transaction Log History Transaction Block Detail - Transaction SE523 View All Block History Unit Unit Originating Start End Unit Original Applicable Project Action Party Block Block Type CP CP ID Track AT ERU 1 2 SE -1 SE ERU 1 2 SE -1 BE ERU 1 2 SE -1 SE ERU 1 2 SE -1 SE ERU 1 2 SE -1 Block History - All Blocks Originating Start End Unit Response Response Response Date & Time Party Block Block Type Description May-05 12:37:52 PM AT AAU May-05 11:37:41 PM AT AAU May-05 11:34:02 PM BE AAU May-05 11:37:41 PM BE AAU Units for conversion must have been issued by Initiating Registry. Units for conversion must have been issued by Initiating Registry. Units identified in the transaction must not have inconsistencies identified through reconciliation with the ITL. Cancelled Units must not be subject to further transactions May-05 11:34:02 PM BE AAU Units for conversion must have been issued by Initiating Registry Transaction Log Actions These forms are read-only Transaction Filter The transaction filter allows the user to pull transactions by a wide range of options. This filter offers more functionality than the other filters allowing AND and OR query conditions for the Registry and Acquiring Account Type search. The user can query on Acquiring Registry, Transferring Registry, Acquiring Account Type, Transferring Account Type, Transaction Type, Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-24

25 Transaction ID, Transaction Status, any combination of these criteria in which the action occurred within a specific date range. See Figure 31. Figure 31: Transaction Filter (example) Acquiring Registry Name: Sweden OR Transferring Registry Name : Sweden Acquiring Account Type : Retirement OR Transferring Account Type : Holding Transaction Type : Most Recent Status: Retirement Proposed AND OR Transaction ID: Project ID: Date Range: to DD-Mon-YY Clear Show Matches Hide Matches 2.15 Unit Block Information The Transaction and Transaction Block screens provide information about past and current transactions. The Unit Block data provides the current ownership and status information on any Kyoto Unit. This information is available from the Unit Block Information menu option. Figure 32 shows the unit block grid showing the current ownership and status of each unit block. The following fields are scrollable in this grid as follows: Icons Originating Party/Registry Unit Type Supplementary Unit Type Block Start Block End Original Commitment Period Applicable Commitment Period LULUCF Activity Code Project ID Track Expiry Date Holding Registry Holding Account Type Unit Status Project Freeze External Transfer of Track 2 ERU Flag The user may either select a block to view or if the user is authorized, may edit the block. Data in this grid are derived from the UNIT_BLOCK and INCONSISTENT_BLOCK tables. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-25

26 Figure 32: Unit Block Information (example) Unit Block Download Filter Originating Party Start Block End Block Holding Registry Original CP Applicable CP Unit Type Unit Status Holding Account Type Project ID Project Freeze Austria Sweden 1 1 AAU Available Holding Austria Austria 1 1 AAU Available Holding Austria France 1 1 AAU Available Holding Austria Austria 1 1 AAU Available Holding Austria Austria 1 1 AAU Available Holding Editing a Unit Block Only an authorized user may select a unit block and change its attributes when taking corrective actions based on a manual reconciliation process. Figure 33 shows the unit block detail form with the fields that are available for editing. Not editable fields are: Originating Party, Start Block and End Block. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-26

27 Figure 33: Unit Block Detail (example) Unit Block Saved Successfully - 09:35:38:47 AM Originating Party : Sweden Start Block: Unit Type: 1 End Block: 250 AAU * Account Type: Holding * Supplemental Unit Type: Expiry Date: Project Freeze: Holding Registry: Unit Status: Jan-09 * Germany Available * * Track: LULUCF Activity: Project ID: Transferred ERU?: Applicable CP: 1 Original CP: 1 Last Action Date: 06-Jul-05 Remove from Inconsistent Block Save Cancel If the user selects the unit block record for editing, the user is warned to track the changes through Reconciliations Manual Intervention interface. In addition, the System Administrator may remove the block from the INCONSISTENT_BLOCK table to clean the block for further processing. While the AUDIT_LOG will capture these changes automatically, comments should be recorded to trace these actions. Figure 34 shows the warning message the user sees before continuing with an edit action. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-27

28 Figure 34: Editing a Unit Block Warning (example) Unit Block - Edit You are about to edit critical data in the UNIT _BLOCK table. This is not recommended unless it is necessary to correct an inconsistency as part of the reconciliation process. You must track this change through manual intervention to record and acknowledge the corrective actions performed. Continue Cancel Unit Block Actions Only authorized users have the privilege to edit the UNIT_BLOCK data Unit Block Filter The Unit Block Filter allows the user to search for unit blocks by Holding Registry, Originating Party, Project ID, Account Type, Unit Type, Unit Block Status, Project Freeze, Expiry Date (as a date range) and block ID (as a range) any combination of these criteria in which the last action occurred within a specific date range. See Figure 35 for screen details. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-28

29 Figure 35: Unit Block Filter (example) Holding Registry: Sweden Project Identifier: SE 145 Applicable CP: Account Type: Unit Type: First Commitment Period Holding AAU Supp. Unit Type: Originating Party : Block ID Range: to Start End Expiry Date: to Unit Status: DD-Mon-YY Available Project Freeze: External Transfer of ERU Flag : Clear Show Matches Hide Matches 2.16 Reconciliation The Reconciliation interface is comprised of three functional areas: Reconciliation log review snapshot review (Section Section ) manual intervention (Section ) The Reconciliation Log tracks the jobs that initiated reconciliation actions. The parent grid in Figure 36 shows each registry and the most recent reconciliation action performed along with the most recent status of that reconciliation. These data are derived from the RECONCILIATION_LOG, REGISTRY, RECONCILIATION_STATUS_HISTORY, and the RECONCILIATION_STATUS_CODE tables. For any registry, the history of every reconciliation action is displayed in the child grid (see Figure 36). These data are derived from the RECONCILIATION_STATUS_HISTORY table. For any reconciliation record that is selected, the subsequent child records show the various phases that the reconciliation has passed through along with any reconciliation comments recorded during a manual intervention (see Figure 36). Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-29

30 Figure 36: Reconciliation Log Screen (example) Registries Most Recent Most Recent Action Registry Name Reconciliation Date Status Austria 01-Jun :30:00 AM ITL Start Request Denied Belgium 01-Jun :30:00 AM Validated France 01-Jun :30:00 AM Initiated Germany 01-Jun :00:00 AM ITL Unit Blocks Inconsistent Sweden 01-Jun :30:00 AM ITL Completed Reconciliation Log - Initiations for Germany Download Action Action Reconciliation Snapshot Start Begin End Select Actions ID Date & Time Phase Date & Time Date & Time Jun-05 03:00:14 AM Totals 01-Jun-05 03:00:40 AM May-05 02:30:00 AM Totals 01-May-05 02:30:12 AM 01-May-05 02:31:01 AM Apr-05 02:30:00 AM Totals 01-Apr-05 02:30:02 AM 01-Apr-05 02:31:15 AM Mar-05 02:30:00 AM Totals 01-Mar-05 02:31:14 AM 01-Mar-05 02:32:46 AM View Snapshot Inconsistent Blocks Manual Intervention View Totals View Audit Trail Reconciliation Status History - Reconciliation 8448 Comment - Reconciliation 8448 Status ITL Unit Blocks Inconsistent ITL Totals Inconsistent Initiated Status Date 01-Jun-05 03:03:01 AM 01-Jun-05 03:01:52 AM 01-Jun-05 03:00:00 AM 2 June, :31:01 AM Started Audit Log received. Manual Intervention started with the request for Audit Log. View Unit Blocks For each reconciliation action the user may view the associated ITL snapshot data upon the reconciliation is based by selecting the record and clicking the "View Snapshot" button. This will display the Snapshot Grid (see Figure 37). The "Inconsistent Blocks" button will display any inconsistent blocks associated with a reconciliation action (see Figure 39). The "Manual Intervention" button will only be available for selection when the current reconciliation has not been validated (see Figure 43). The "View Totals" button will display the totals submitted by the registry for reconciliation. It will also display the totals calculated by the ITL (see Figure 40). The "View Unit Blocks" button will display the unit blocks submitted by a registry for reconciliation. This button will only be available for selection if the totals were not validated (see Figure 41). Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-30

31 The "View Audit Trail" button will display the transaction history submitted by a registry for this reconciliation action. It will only be available for selection if the reconciliation action reached this phase (see Figure 42) Snapshots For each Reconciliation job that requests data to be submitted from a registry, the ITL will create a snapshot and store this data in the RECONCILIATION_LOG, SNAPSHOT_LOG, SNAPSHOT_TOTAL and SNAPSHOT_BLOCK table. Figure 37 shows the snapshot grid that is displayed below the Reconciliation Log grid when a user selects a Reconciliation ID record and clicks "View Snapshot." Figure 37: Snapshot Grid (example) Snapshots for Germany Download Filter Recon Account Unit Originating Start End Action ID Type Type Registry Block Block 8448 Holding AAU DE Holding AAU DE Holding AAU DE Holding RMU DE The user may filter the snapshot grid may be filtered by any of the unit characteristics saved in the data snapshot. Figure 38: Snapshot Filter (example) Account Type: Holding Account Commitment Period: Originating Registry: Unit Type: Serial Range : Germany AAU Start Block End Block to Clear Show Matches Hide Matches Inconsistent Blocks If any inconsistent blocks are associated with a reconciliation action, they will be displayed in this grid. The source of this grid is the RECON_BLOCK_RESPONSE_LOG table. This table stores all the blocks that were ever found to be inconsistent during a reconciliation action. Once an inconsistency is resolved, the record remains in this table and continues to be displayed in this grid Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-31

32 for historical purposes. These blocks may be viewed (and corrected) through the Manual Intervention screens. There is no filter for this grid. Figure 39: Inconsistent Blocks (example) Inconsistent Blocks for Reconciliation 8448 Download Originating Start End Response Response Code Registry Block Block Code Description DE DE DE DE The registry and ITL unit blocks for each specified account type, Commitment Period and unit type must be consistent The registry and ITL unit blocks for each specified account type, Commitment Period and unit type must be consistent The registry and ITL unit blocks for each specified account type, Commitment Period and unit type must be consistent The registry and ITL unit blocks for each specified account type, Commitment Period and unit type must be consistent Reconciliation Totals The Reconciliation Totals grid displays the totals submitted by the registry and the totals calculated by the ITL from the snapshot. The Source column indicates whether the total is from the registry or the ITL. When the total is from a registry, the value will be the country code for that registry. If the total is from the ITL, the value is "ITL." The source of this grid is the Snapshot_Total table. Figure 40: Reconciliation Totals (example) Download Source DE DE ITL ITL Account Type Commitment Period Unit Type Total Reconciliation Unit Blocks The Reconciliation Unit Block grid displays the unit blocks submitted by the registry during the reconciliation action. The source of this data is the Snapshot_Block table, filtered for the appropriate data type. Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-32

33 Figure 41: Reconciliation Unit Blocks (example) View Unit Blocks for Recon Germany Source DE DE DE DE Originating Registry DE DE DE DE Block Start Block End Account Type Commitment Period Download Unit Type Reconciliation Audit Trail The Reconciliation Audit Trail grid displays the transaction history of the inconsistent blocks as submitted by the registry. Selecting a transaction and clicking the "View Block Detail" button will display below the grid all the blocks associated with that transaction. Figure 42: Reconciliation Audit Trail (example) View Audit Trail for Recon Germany Download Filter Select ID Trans Type Supp Trans Type Acquiring Registry Acquiring Account Type Acquiring Account ID Transferring Registry Transferring Account Type Transferring Account ID Transaction Date & Time Most Recent Status DE101 Issuance 54 DE Holding DE 06-Jun-05 09:14:12 Completed DE301 Issuance DE Holding DE 06-Jun-05 09:14:35 Completed DE411 Issuance DE Holding DE 06-Jun-05 09:15:03 Completed DE412 Retirement DE Retirement DE2000 DE Holding 06-Jun-05 09:15:12 Completed View Block Detail Transaction Block Detail - Transaction SE523 Unit Unit Originating Start End Unit Original Applicable Project Action Party Block Block Type CP CP ID DE AAU 1 1 DE AAU 1 1 Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-33

34 Manual Intervention There will be instances in which the ITL administrator will need to suggest corrective actions for a registry to perform or that need to be made directly on the ITL data. When this happens, the System Administrator must select an existing Reconciliation action and then record corrective actions. This screen will display a grid of past and ongoing reconciliations that have reached the Manual Intervention stage. The parent grid will display the reconciliation action. When a reconciliation is selected, three child grids will display the current status, any comments associated with the reconciliation, and any inconsistent blocks that are associated with the reconciliation action. The source of data for these grids is the RECONCILIATION_LOG, RECONCILIATION_STATUS_HISTORY, and the SNAPSHOT_BLOCK tables. To initiate a Manual Intervention the user must first click the "Start Manual Tracking" button. This assures that all changes to unit blocks to correct inconsistencies will be associated with this Reconciliation ID when recorded in the Audit Log. Once the "Start Manual Tracking" button has been clicked the user will be allowed to edit the inconsistent blocks and related data. This button is only available for selection if the reconciliation has not been previously completed. Figure 43: Manual Intervention Screens (example) Manual Interventions Reconciliation Most Recent Most Recent Action Registry Name ID Reconciliation Date Status Germany Jun-05 03:00:00 AM ITL Unit Blocks Inconsistent Status Registry: Germany Reconciliation Start Date: June 1, 2005 Most Recent Status: ITL Unit Block Inconsistent Reconciliation ID: 8448 Comment - Reconciliation June, :31:01 AM Started Audit Log received. Manual Intervention started with the request for Audit Log. Start Manual Tracking Inconsistent Blocks Audit Log Set Status to Complete Save Inconsistent Blocks Download Filter Originating Start End Holding Applicable Expiry Unit Unit Account Project Action Party Block Block Registry CP Date Type Status Type Identifier DE Germany 1 AAU Available Holding DE Germany 2 AAU Available Holding SE Germany 1 AAU Available Holding Annex I ITL Software Specification, Version <1.0>, Draft #8 Page I-34