Single Electricity Market SEM Release 1 9 0

Single Electricity Market SEM Release 1. 9. 0 – April 2011 Change Control Forum (CCF) Meeting 15 th September 2010 (Dublin)

Agenda Introduction SDS/CCF Overview Changes already in SEM R 1. 9. 0 scope Change Requests for consideration Next Steps Questions 2 © SEMO, 2010.

Introduction Ø Welcome to the first of two Change Control Forum (CCF) meetings for the SEM R 1. 9. 0 release (April 2011) Ø On August 26 th the Regulatory Authorities gave SEMO approval to establish the SEM Design Service (SDS) Ø The SDS is a new function of SEMO and will ensure, through the CCF, the prioritisation of non Trading & Settlement Code (T&SC) Change Requests (CRs) for inclusion in Central Market Systems (CMS) releases. Ø In addition the SDS will have oversight of all forthcoming CMS releases and will be responsible for the development and maintenance of associated baselines related to these releases. 3 © SEMO, 2010.

Agenda Introduction SDS/CCF Overview Changes already in SEM R 1. 9. 0 scope Change Requests for consideration Next Steps Questions 4 © SEMO, 2010.

What is the SDS? In summary, the responsibilities of the SDS include: Ø Recording the receipt of proposed changes for consideration by the CCF Ø Providing administrative and secretariat support to the operation of the CCF Ø Where required, provide data to the Modifications Committee on release capacity forthcoming releases Ø Assessment of the impacts of the non-T&SC CRs Ø Communicating – release-related decisions – Baseline changes – Status of CRs received Ø Maintaining and developing SEM Design Baselines on behalf of all SEM stakeholders Ø The SDS will not prioritise changes - this will be the role of the CCF.

What is the CCF? Ø As part of the establishment of the SDS the Change Control Forum (CCF) will also be established. This is a public meeting mechanism, open to all, to discuss and recommend non T&SC changes for inclusion within a release. Ø The following basic principles apply to CCF meetings: Ø Anyone can attend Ø There is no need for a nomination or voting structure Ø Simple to establish, operate and maintain. Ø The purpose of CCF meetings is to: Ø To determine what non-T&SC CRs should be included in a release Ø To give Participants a detailed understanding of changes being made and Ø Provide a forum for discussion / feedback. Ø CCF meetings are chaired by the SEMO IT Manager who will Ø Compile a final recommendation report for the RAs and Ø On receiving approval, include these non-T&SC CRs in scope for the relevant release. 6 © SEMO, 2010.

Deployment Criteria Ø The CCF will evaluate and recommend appropriate change requests for implementation based on the following deployment criteria: Ø The available capacity within the release schedule Ø The interests of final customers Ø The benefit to Market Participants Ø The efficiency of Market Operations Ø The bundling of similar change requests which have common design or functionality. 7 © SEMO, 2010.

Non-T&SC Release Capacity Ø Total release capacity for a scheduled bi-annual release to the CMS is 6, 125 vendor hours, 30% of which is required for the provision of assessments, testing and deployment support, leaving a net development capacity of 4, 288 hours per release. Ø It has been agreed that release capacity will be allocated as follows: Ø 3, 430 hours (80%) to Approved Modification Proposals (approved by the Mods Committee) Ø 858 hours (20%) to Approved non-T&SC CRs (approved by the CCF) Ø Capacity not utilised by one change stream may be utilised by the other as appropriate. 8 © SEMO, 2010.

CCF Meetings Ø Typically, there will be two CCF meetings (held after the Release Cut-Off Date) per scheduled release: Ø Meeting 1 will: Ø Review all non-T&SC CRs submitted before the release cut-off date; Ø Agree a provisional prioritised list of CRs to be included in scope based on business case; and Ø Request assessments from our vendors of those CRs on the provisional prioritised list for which we do not yet have an assessment. Ø Meeting 2 will: Ø Review the provisional prioritised list of CRs from Meeting 1 and Ø Finalise the list of CRs to be included in scope taking into consideration costs provided by our vendors. Ø Subsequent to these meetings a final recommendation report will be issued to the RAs for approval. Ø On receiving final approval from the RAs, the SEMO IT Manager will schedule the appropriate CRs for the release. Ø For more details on the SDS please refer to the SDS Approval paper on the SEMO website 9 © SEMO, 2010.

Agenda Introduction SDS/CCF Overview Changes already in SEM R 1. 9. 0 scope Change Requests for consideration Next Steps Questions 10 © SEMO, 2010.

Changes already in SEM R 1. 9. 0 scope Ø The following table details what changes are already in scope. These consist of Modification Proposals, approved to date. Ø Note: CR 199 has been added to scope. This relates to Mod_34_09 – Global Settlement which we anticipate will be approved by the SEM Committee by the end of September. Modification Proposals CR Ref Mod Ref Description Vendor Hours SEM_PC_CR 217 46_09 Treatment of UIs for Pumped Storage Units SEM_PC_CR 242 12_09 Loss adjustment of SUC and NLC in CONP and MWP SEM_PC_CR 199 34_09 Global Settlement 1, 131 Total Modification Capacity Usage 1, 347 Modification Capacity Surplus 2, 083 144 72 Non – T&SC Change Requests Unused Capacity from Modifications stream Non-T&SC Capacity Allocation Total Remaining Capacity Available 11 2, 083 858 2, 941 © SEMO, 2010.

Agenda Introduction SDS/CCF Overview Changes already in SEM R 1. 9. 0 scope Change Requests for consideration Next Steps Questions 12 © SEMO, 2010.

SEMO Change Requests for consideration After a review of internally raised CRs, SEMO have prioritised a number of changes as being of a High Priority The implementation of these CRs will: Ø Introduce significant efficiencies to SEMO Market Operations (time and cost) Ø Provide greater transparency for the SEM Ø Mitigate the risk of Operator Error Ø Reduce queries to the Market Helpdesk Ø Reduce support costs from our vendors Ø Introduce increased robustness to the CMS

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 172 Proposed By: SEMO Priority: High Complexity: High Hours: TBC Description: MIUN Calculation The requirement is to calculate MIUNs in the Central Market Systems (CMS) as per the rules laid out in Agreed Procedure 2 (page 22: Appendix 2: Calculation of Modified Interconnector Unit Nominations). Rationale / Benefit Currently “sub-contracted” to SONI (via MITS system) Introduction of EWIC/Auction Platform necessitates bring this in to the CMS Therefore this change is required to ensure a consistent determination of the MIUNs and to ensure that it is open and transparent for all interconnection within the SEM. CR Ref. : SEM_PC_CR 170 Proposed By: SEMO Priority: High Complexity: Medium Hours: TBC Description: Payment Currency Costs calculated in Axapta (SEMO’ Finance System) for each settlement type i. e. initial , M+4, M+13 and ad-hoc. Rationale / Benefit : Audit Recommendation There have been issues with calculation of currency costs identified as part of the Market Audit in 2009 and 2010. The calculations are currently performed in spreadsheet as the existing reporting in axapta is not usable. As a workaround, to reduce errors, two Market Controllers are required to calculate the payment currency costs manually via an excel spreadsheet on a weekly basis. This change is proposed to close out the issue raised in the Market Audit and reduce the manual processing which is open to error. 14 © SEMO, 2010.

CR Ref. : SEM_PC_CR 234 Proposed By: SEMO Priority: High Complexity: Medium Hours: TBC Description: Currency Costs calculation in Axapta and transfer to Settlements This change specifies that the currency costs will be pushed to Settlements via an interface in Axapta when these costs are required for Invoicing. Avoiding manual processing and entry. Rationale / Benefit: Audit Recommendation Currency Costs are currently calculated manually using an excel Template and then emailed to the Settlements Controller. This process is open to error and omission. As has been highlighted in some cases as part of the Market Audit. . CR Ref. : SEM_PC_CR 180 Proposed By: SEMO Priority: High Complexity: Medium Hours: TBC Description: Exchange Rates in Central Market Systems to use common exchange rate which is entered once. Rationale / Benefit: Reduce Errors Currently controllers need to enter exchange rates separately into each of the Central Market Systems (MA, Settlements, CRM, FT. In addition, the reciprocal exchange rate must also be entered manually. This has lead to occurrences where exchange rates have been entered incorrectly, even with additional checks being put in place. It is inherently prone to error due to its manual nature. The worst occurrences have led to incorrect schedules being published for Ex-Ante and invoices needing to be cancelled, delayed and reissued.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 225 Proposed By: SEMO Priority: High Complexity: High Hours: TBC Description: Historical Cross-Border Resettlement SEM R 1. 8. 0, through SEM_PC_CR 150, will introduce a split to of charges into intra and inter jurisdictional amounts. The SEM_PC_CR 150 change will only apply to Settlement Invoices relating to periods after the implementation of SEM R 1. 8. 0. Upon implementation of this change request the split of new charges will apply to all Invoices generated irrespective of settlement period. Rationale / Benefit: Revenue Requirement Will allow cross-border trade amounts to be shown in resettlement Invoices as per revenue ruling CR Ref. : SEM_PC_CR 209 Proposed By: SEMO Priority: High Complexity: Low Hours: 55 Description: Improved upload and maintenance of Uninstructed Imbalance and Testing Tariff Values in Settlements The current system design means that DOG/PUG/TTARRIFF files are created manually and uploaded manually in settlement. If a unit is not present in the file the settlement system just ignores this charge. This has led to errors in uninstructed imbalances e. g. one unit was incorrectly charged for 10 months. This change request looks to allow new units or changes to existing units charges to be applied in the settlement system, avoiding the errors and time associated with the manual upload, and additional validation during settlement to ensure each unit has a value. Rationale / Benefit : Reduced Errors, Operational Efficiency Remove instances of incorrect uninstructed imbalances due to omission of charges/tariffs. Improved efficiency of process with daily manual processing removed. 16 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 210 Proposed By: SEMO Priority: High Complexity: Medium Hours: 128 Description: Provide a separate exchange rate for Capacity invoicing calculations Provide two separate CDEX exchange rates for the Capacity/FMOC markets and the Energy markets. This should affect the segments IPCCEN, ENGIPCC, IPCCCP, CAPIPCC and FMOEXG. AS the Capacity/FMOC markets are billing periods are concurrent, a single rate is sufficient for both markets. The rates should be imported using the Manual Line Item Import in a similar way to the current situation. Rationale / Benefit: Reduce Errors CDEX is used in the calculation of Energy/Capacity Currency Costs and to convert the Fixed Market Operator Charge to the currency of the participant to be invoiced. This works fine for Initial Invoicing but problems occur for resettlement as there are overlapping imported CDEX values for Capacity/FMOC and Energy Markets. The workaround consists of having to re-import the Exchange rate for the first day of any overlapping Energy/Capacity period. As a result, Capacity invoicing has been calculated incorrectly on some occasions. The workaround above has been deployed to correct the issue but this workaround is prone to error. CR Ref. : SEM_PC_CR 200 Proposed By: SEMO Complexity: Low Hours: TBC Priority: High Description: Max limit of 6 SRAs per PT in MI Each participant should be limited to a maximum of 6 SRAs per trading day per market. When a participant attempts to submit a 7 th SRA for a given trade date and market, it should be rejected with a message appearing indicating the reason for the rejection. A log of the rejected submission should also be recorded for auditing purposes. Rationale / Benefit: Code Compliance Currently there is no validation process in MOI to limit the number of SRAs a participant submits for a given market and trade date. As per AP 10, a participant should only submit a max of 6 SRAs per trading date per market, but in addition the MO has an obligation under the Code to reject the over submission using both type 2 and type 3 responses. Currently the MO has no way to issue this response type 2 or 3 and communicate this via email. This places an additional burden on the CRM function in the MO. In addition the current process of sending reports via email is not as secure as publishing privately on the MPI and is open to error both in preparing the cancellation reports and also sending them. 17 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 240 Proposed By: SEMO Complexity: Medium Hours: TBC Priority: High Description: Bad Debt Smearing Process Bad Debt Smearing – report to perform smearing calculations Rationale / Benefit – Reduction in Error, Operational Efficiency The Bad Debt Smearing process is currently a manual process. The first step in this is to calculation the smearing amounts. Settlements currently has all the information required to complete the smearing calculation, but a report is needed to output the result. Currently this would have to be done manually which is open to error and also may effect the MO’s ability to meet the tight timelines on issuing debit notes. CR Ref. : SEM_PC_CR 187 Proposed By: SEMO Complexity: Medium Hours: 336 Priority: High Description: MOI Batch Functionality Create events in the MOI that will start a customisable list of events. e. g. have an event that would publish all EA reports at once. Rationale / Benefit: Reduce Errors, Operational Efficiency Processing events individually is time consuming. The more events which have to be individually started, the higher the chance a user will start the wrong event. 18 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 231 Proposed By: SEMO Priority: High Complexity: Medium Hours: TBC Description: MISTL DLY PUSH Event Window If the associate parameters of this specific MOI event have not been extended correctly to push across historical data feeds they cannot be retrieved without resubmission of data Rationale / Benefit - Operational Efficiency For M+4, M+13 and Ad-hoc Resettlement, the Market Operator often has to request historical data from Transmission System Operators (TSOs) before resettlement can take place. The historical data can take the TSO some time to collate and send. To push historical data from MI database to Settlements the window needs to be extended to X+1 days (X being historical trade date). To avoid this cumbersome workaround (involving TSO, SEMO Operations and SEMO IT), SEMO proposes a change that would enable this ‘new/updated’ data to still be sent from the MI database to Pomax. Operationally, this would save upwards of 3 working hours per occurrence and has happened regularly throughout the year. CR Ref. : SEM_PC_CR 214 Proposed By: SEMO Priority: High Complexity: Low Hours: 42 Description: Removal of 0 INTEREST from INTEREST Import Source Remove ability of user to add values for variable type Zero Interest in Manual Line Item Import facility (Import Source - Interest). Rationale / Benefit: Reduce Errors Currently, settlements users update the INTEREST variable in Pomax using the Manual Line Item Import tool. This variable is contained in the INTEREST import source. There is another variable called 0 INTEREST also contained in the INTEREST import source and this has led to issues in the past. As the variable 0 INTEREST has such a similar name to the INTEREST variable, it has previously been populated in error which has resulted in re-invoicing having to be performed. This has caused issues with invoices on more than one occasion 19 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 178 Proposed By: SEMO Priority: High Complexity: Medium Hours: 228 Description: Standing Bid Conversion Event Change to the Standing Bids Conversion Event to only convert bids for units that are effective for the relevant Trading Day Rationale / Benefit: Reduce Errors The Standing Bid Conversion process involves querying the standing bids and re-submitting them as Normal bids for a Trading Day. The current Standing Bid Conversion process which is run at Market OPEN converts Standing Data for ALL units and not just units that are effective for the specific Trading Day in question. This leads to a number of error messages being generated on a daily basis. Even though the error in question does not impact on actual calculation, it is viewed by the Market Operators and Market Participants on a daily basis and could be masking other potential issues due the background “noise” generated by these messages. It is also having an impact on daily checks performed by Market Participants. CR Ref. : SEM_PC_CR 190 Proposed By: SEMO Priority: High Complexity: Medium Hours: 140 Description: SRA cancellation in TRM controllers need a means of identifying and cancelling SRAs submitted by a participant for a given market and for a range of delivery dates. Rationale / Benefit: Operational Efficiency, Reduces Errors The number of SRA cancellations that occur as part of daily credit cover calculations was never envisaged to be so high, but has now become common place. E. g. in the first half of 2009 SRA’s have needed to be cancelled as part of credit cover activities on 71 of the 120 days. (60% of the time). On average this process takes an extra 45 minutes per day (7 working days per year) to the Credit Cover process. In addition the current process of sending reports via email is not as secure as publishing privately on the MPI, and the process is open to error both in preparing the cancellation reports and also sending them 20 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 235 Proposed By: SEMO Priority: High Complexity: Low Hours: TBC Description: Market Type required for each Open Transaction on Axapta Funds Transfer use Billing Job outputs from Settlements to reconcile payments due to the Market. There is insufficient information in Axapta’s Open Transaction report to accurately identify outstanding payments as the market type to which each invoice belongs is not shown. A separate field is required in the open transaction report to show the market type for all published invoices. Rationale / Benefit: Operational Efficiency The Axapta Open Transaction report gives no details of what market type each Invoice belongs to. Increasing the time taken to reconcile payments. The additional field would help reduce the overhead time associated with reconciling outstanding payments due to the market as well as identifying any Default Payments for each market type. CR Ref. : SEM_PC_CR 233 Proposed By: SEMO Priority: High Complexity: Medium Hours: TBC Description: Invoice Details applied to Axapta Sales Journals When Creating the Payment Journal the Invoice Numbers which are being paid are not referenced anywhere in the actual Journal which is being posted. Invoice numbers can be viewed on Purchase Journals. However when creating the payment journal on the Sales side of Axapta the Transaction Text and the Payment reference fields remain blank. Ideally the transaction text and/or payment reference field in Axapta would Include the Invoice Number which has been selected in open transactions and pulled into the journal Rationale / Benefit: Operational Efficiency, Reduce Errors Operations processing would become more efficient if Invoice numbers could be viewed in the Journals which controllers have created. If not implemented, overhead time spent processing payments due into the market will remain high. There also remains a risk of operational errors. 21 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 232 Proposed By: SEMO Priority: High Complexity: Low Hours: TBC Description: Viewing Invoices on the MPI If there are more than three invoices published for one Market Type for any participant, all the latest invoices cannot be viewed on the MPI in the first instance if the Most Recent Invoice Box is checked. A change is required so that if the Most Recent Invoice Check box is ticked, all recent published Invoices may be viewed. Rationale / Benefit: Participant Efficiency, Reduce Participant Errors Overhead time would be reduced for Funds Transfer regarding processing payment defaults for participants who have not successfully viewed Invoices on the MPI. CR Ref. : SEM_PC_CR 241 Proposed By: SEMO Priority: High Complexity: Medium Hours: TBC Description: Invoice Numbers in Axapta When creating Purchase Orders in the Axapta purchase side, the system does not automatically allocate an Invoice number for each Purchase Order. This number has to be entered manually by the user and recorded in an Excel Spreadsheet to avoid duplication. This change will create Invoice Numbers automatically. Rationale / Benefit: Reduced Errors, Operational Efficiency If the Invoice number could be created automatically by the system this would improve efficiency for Funds Transfer and reduce the risk of operator error. 22 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 201 Proposed By: SEMO Priority: High Complexity: Low Hours: TBC Description: Supplier and GU SRA overview in TRM Two new columns to be added to the Code Participant summary screen in the TRM GUI of the Credit Risk Report. • Column 1 - SRAs – Gen. This column lists the sum of SRA amounts for participants of type “Generator” for the given Code Participant • Column 2 - SRAs – Suppl. This column lists the sum of SRA amounts for participants of type “Supplier” for the given Code Participant Rationale / Benefit: Operational Efficiency On average, this would reduce the workload by 15 minutes per day to the Credit Cover process. CR Ref. : SEM_PC_CR 228 Proposed By: SEMO Priority: High Complexity: Medium Hours: TBC Description: Calculation of Forecast ENG-CAP price in TRM Functionality to calculate Energy and Capacity Market Forecast Price in TRM Rationale / Benefit: Reduced Errors, Operational Efficiency Currently a controller has to manually create the Energy and Capacity Forecast price via an excel spreadsheet and import this into TRM. This is not only time consuming on a daily basis as it requires one controller to calculate and enter and a second controller to verify (taking up to 108 hrs over a year) and is subject to error. Any errors can have serious implications in the calculation of Participants Undefined Exposure Period. 23 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 203 Proposed By: SEMO Priority: Medium Complexity: Low Hours: 142 Description: Displaying UUC Penalty Costs in MA Output the penalty costs (i. e. costs associated with the slack variables) in MA, so that these are displayed on screen. Rationale / Benefit: Decision Making Reporting this would make it possible for the Market Operator to calculate the actual production cost of the schedule. This is the cost of running of all generators that are on, plus the cost of any constraint violation. Needed to be able to confirm cost of solutions where both MIP and LR provide infeasible solutions CR Ref. : SEM_PC_CR 239 Proposed By: SEMO Priority: Medium Complexity: Low Hours: TBC Description: Duplicate Vouchers in Axapta When processing payments on the Axapta sales side, the system occasionally creates duplicate voucher numbers. This prevents the journal from being posted without a manual workaround of creating a ‘dummy’ voucher to skip the duplicate. This change will eliminate duplicate voucher numbers being created on the Axapa System. Rationale / Benefit: Operational Efficiency This change will reduce the time it takes to process payments due to the Market. 24 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 174 Proposed By: SEMO Priority: Medium Complexity: Low Hours: 48 Description: MPI dropdown values for TS This change proposes to change the labelling of the trading site field and dropdown list names in the MPI to make them more intuitive and in so doing reduce the likelihood of operator error when registering units. Rationale / Benefit: Reduce Errors Currently the labels and dropdown used to define if a site is a normal supply unit, trading site supply unit, or associated supply unit is not intuitive at all. This has led in part to a number of registration issues which have required extensive vendor support and remedial action. CR Ref. : SEM_PC_CR 229 Proposed By: SEMO Priority: Medium Complexity: Medium Hours: TBC Description: Future VAT rates in TRM Global updating of Future VAT in TRM Rationale / Benefit: Reduce Errors, Operational Efficiency Currently controllers have to update each PT listing in Trade Partners with Energy and Capacity Future VAT individually. As this figure has a baring on the calculations of Undefined Exposure it is vital that this information is input correctly. It is proposed that through making better use of the Credit Parameters section, a controller can make single update to NI/ROI Generator and Supplier VAT rates globally. This would greatly decrease the possibility of errors occurring. There are currently 85 registered participants in TRM and this number is constantly increasing. 25 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 211 Proposed By: SEMO Priority: Medium Complexity: Medium Hours: TBC Description: Simultaneous running of multiple Value Imports This change will allow SEMO to enable Value Imports to be processed for multiple dates. They could be carried out simultaneously or alternatively queued up behind one another, depending upon the system capabilities. Rationale / Benefit: Operational Efficiencies Currently Market Operators carryout M+4, M+13 and often Ad-hoc Re-settlement. This requires the MO to perform multiple types of Value Import, often for a full calendar month at a time. Upwards of 5 import types often have to be processed. The system currently only allows the user to perform a Value Import one day at a time. This method introduces the potential for error (missed dates). CR Ref. : SEM_PC_CR 237 Proposed By: SEMO Priority: Medium Complexity: Medium Hours: TBC Description: Automatic Email Notification of Published Invoices. This change will result in the sending of an email to participants automatically advising that invoices published are due for payment and available for download. The email will be tailored for each participant advising of the number of payments due, the Market Type of each Invoice and the date payment is due. Rationale / Benefit: Market Efficiency Email automatically sent from the SEMO website or MPI to advise participants that invoices have been published to ensure volume of payment defaults incurred by SEMO are reduced. 26 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 212 Proposed By: SEMO Priority: Medium Complexity: Medium Hours: TBC Description: DDF Selection based on Import type Import Files Function - Data Definition File (DDF) import type should be dependant upon Import Type field (i. e. P or I etc). Rationale / Benefit: Reduce Errors Current system flexibility allows for DDF files of type I or P to be selected regardless of which Import Type is selected. This flexibility has resulted in Indicative (P) data being used for an Initial (I) settlement run. This change request proposes to reduce this flexibility by providing a mechanism whereby only DDF files Type ‘I’ may be selected if filtered on Import Type ‘I’, etc. DDF files could additionally be dependant upon System Type to remove any potential error pairings. Alternatively, a ‘Warning/Fail’ message could appear on screen if the above dependency has been breached CR Ref. : SEM_PC_CR 236 Proposed By: SEMO Priority: Medium Complexity: Medium Hours: TBC Description: Axapta Account Details updated Automatically on Sales Ledger When using the payment proposal by due date function the method of payment update with the bank account ‘i. e. MOP_EUR’ according to the Market to which the Invoice belongs. The Dimension in each journal line should also default to match the bank account to which the payment belongs. This is not the case with Journals which are created via the Functions – Settlement process. Offset Account should default to the market to which the settled invoice belongs. Only payments which are made to incorrect market accounts should need to be updated manually by users with A/C Details. Rationale / Benefit: Operational Efficiency Creating payment journals in Axapta is a very manual process. Some of the manually inputted data to the payment journals in the sales side is standard for all Payments and could be updated automatically with less end user processing. I. e. Transaction Text and Bank Account. 27 © SEMO, 2010.

SEMO Change Requests for consideration CR Ref. : SEM_PC_CR 168 Proposed By: SEMO Priority: Medium Complexity: Low Hours: 52 Description: Unnecessary File Import Type selection Removal of unnecessary File Import Type radio button selection in POMAX Import Files screen Rationale / Benefit: Reduced Errors The flexibility of the Import Files screen in Settlements introduces potential for operator error when running file imports. For operational purposes the Import type radio button (Full import / File import Only / XML import only) selection is unnecessary and is never used. ‘File Import Only’ mode does not save the data in the POMAX database rather it saves the data in the xml file. Incorrect selection of the import type due to operator error has caused occurrences where invoices have been delayed and payment dates have had to be pushed out. Vendor consulting time to generate a script to fix the issue was required and there were knock-on issues for CRM and Funds Transfer. Given the import is always the same there is no need to have the multiple selection options. CR Ref. : SEM_PC_CR 213 Proposed By: SEMO Priority: Medium Complexity: Medium Hours: TBC Description: Improved Querying of Settlement Data Change Request for better data querying functionality through Pomax’s Import Control Report. Rationale / Benefit: Operational Efficiency Finance require queries to be run by the Settlement Team in Pomax before approval of invoicing is granted – this often spans Energy, VMOC, FMOC and Capacity market types. This is a time consuming process as results can only be pulled for one day at a time and summated in a spreadsheet. This process can take up to 3 hrs per week/1. 5 days per month. This Change Request proposes a more effective querying tool to pull specific data sets from the Import Control Report. 28 © SEMO, 2010.

SEMO Change Requests for consideration The following Change Requests are of Low Priority and would only be considered if all High and Medium Priority CRs were addressed: Cr Ref. Description SEM_PC_CR 238 IRCU included in Energy Invoices SEM_PC_CR 160 Reconciliation and Loading of Payments SEM_PC_CR 226 Pop-up Reminder of Digital Cert Renewal

Participant Change Requests for consideration The following Change Requests were submitted to SEMO by Market Participants for consideration in a scheduled release. In each case the Participant was contacted to determine their view of the Priority of each change. Note SEM_PC_CR 206 was withdrawn by the Participant subsequent to the list of CRs issued on Monday 13 th September.

Participant Change Requests for consideration CR Ref. : SEM_PC_CR 215 Proposed By: Airtricity Priority: High Complexity: Low Hours: 25 Description: MSQ in Public Settlements Reports The change request seeks to add a new variable to the reports, Market Schedule Quantity (MSQ), for each Generator Unit. The additional variables would be as follows: • MSQ - Market Schedule Quantity for Generator Units • MSQIU- Market Schedule Quantity for Interconnector Units These variables already appear in the PIR settlement report, but only for generator units relating to the recipient party. Rationale / Benefit The Change Request addresses inadequacies in the "Daily Initial Ex-Post Market Schedule Detail" reports (both participant and general public versions), which contain erroneous MSQ data for certain classes of generator unit, by ensuring that the correct version of the MSQ data is made available in the “Metered Data and NIJI” public settlement reports. The two flawed reports are the only source of MSQ data for third parties at the moment. Unless the Change Request is implemented only erroneous MSQ data will be available for some generator units. At present neither accurate reproduction of settlement calculations, or accurate analysis, can be performed. Market participants are potentially being misled. 31 © SEMO, 2010.

Participant Change Requests for consideration CR Ref. : SEM_PC_CR 224 Proposed By: Airtricity Priority: Medium Complexity: Medium Hours: TBC Description: Ad-hoc flag in Type 3 statements A new flag / signal to indicate it is an ad-hoc re-settlement would facilitate users to easily and efficiently identify the Type-3 resettlement statements. We are requesting an indicator to be used in the relevant reports / data downloads. Include a flag in the statements to indicate if it is an ad-hoc statement. Rationale / Benefit Currently when the market completes an ad-hoc resettlement, it is difficult to identify the actual settlement run for Type 3 statements. (e. g. D + 4, M + 4 and M +13). A new flag / signal to indicate it is an ad-hoc re-settlement would facilitate users to easily and efficiently identify the Type-3 resettlement statements. There is a large volume of resettled days in the market. It is not easy to identify the settlement run for the ad-hoc run. Easy identification of each statement would reduce the possibility of errors, increase the accuracy of interpretation of market messages and reduce manual workarounds. Two calls have been previously raised with the helpdesk regarding this issue (F 0015495 and F 0016085) and several discussions have taken place at MOUGs. This request is very similar to CR 206 (Re-Pricing Flag on Reports) and therefore consideration should be given to the benefits of combining this CR with CR 206. 32 © SEMO, 2010.

Participant Change Requests for consideration CR Ref. : SEM_PC_CR 188 Proposed By: ESB International Priority: Medium Complexity: Low Hours: TBC Description: . Include a "Download" in PDF" option for SEMO published Invoices Rationale / Benefit Facilitate more efficient processing and distribution of SEMO invoices to Participants. CR Ref. : SEM_PC_C 189 (ref CR 232) Proposed By: ESB International Priority: Medium Complexity: Low Hours: TBC Description: Invoices filter checkbox change The Invoices filter “Check Box” (Most Recent Invoices) if ticked will not include the Month + 4 and Month + 13 SEMO Invoices published. While the date range may be used to filter the most recent invoices it would be beneficial to include the Month + 4 and Month + 13 Invoices in the “Most Recent Invoice” “Check Box” or have an additional “Check Box” which would include Most Recent Month + 4 and Month + 13 Invoices in the selection returned. Rationale / Benefit Facilitate quicker selection of Most Recent Published Invoices including Initial, Month + 4, Month + 13, Market Operator and Capacity Invoices. 33 © SEMO, 2010.

Participant Change Requests for consideration CR Ref. : SEM_PC_CR 198 Proposed By: ESB International Priority: Medium Complexity: Medium Hours: TBC Description: . Additional COD Validations Preventing the accidental submission of erroneous bid data. A simple sense check on input data ought to be embedded into the MPI website, such that warning messages should be flashed up when apparently erroneous bid data is to be entered. This should not prohibit such data being entered, but should warn the participant that the values are unusual. Including specifically, but not limited to: ØPrice values < € 5/MWh for thermal units ØPrice values > € 100/MWh for CCGTs / Coal units ØStart up costs <€ 100 ØStart up costs >€ 1, 000 ØThe top Q value being less than Mingen ØAny Q value exceeding the Firm Access Quantity Rationale / Benefit This could prevent erroneous data being submitted which would then lead to the prevention of an erroneous schedule being produced. Such an event can cause prices to be more than 20% higher (estimate from NIAUR) than if the correct data was submitted and prevent the day needing to be rescheduled 34 © SEMO, 2010.

Participant Change Requests for consideration CR Ref. : SEM_PC_CR 192 Proposed By: Energia Priority: Medium Complexity: Medium Hours: TBC Description: . MSQ in Capacity PIR report Publish the Market Schedule Quantity (MSQ) variable in the Capacity Participant Information Reports (PIR) Rationale / Benefit The MSQ variable is needed for the Settlement of Capacity in the market, but is published in the Energy PIR. As the EN and CA are published on different timescales and can have different revision numbers, our system cannot tie the two together due to the EN & CA being out of sync. When the EN and CA revisions are out of sync we cannot shadow SEMO calculation for Capacity charges payments. CR Ref. : SEM_PC_CR 193 Proposed By: Energia Priority: Medium Complexity: Medium Hours: TBC Description: . TLAF publishing in the MPI Publish an agreed format and standardised list of TLAFs, i. e. in Excel, XML or CSV format that will be published ad-hoc and will be downloaded via Type 3 and Type 2 communications. Rationale / Benefit Currently SEMO publishes an Excel format of TLAFs on their website. This is not an official version and so it is liable to change format. As we have multiple units in the market we would like to programmatically load the TLAFs into our system. If the format of the TLAF file was standardised and published on the SEMO Web. Service, our systems could download this file and store it programmatically. Without this change, many TLAFs need to be manually entered for all units of the year, which is very time consuming. 35 © SEMO, 2010.

Participant Change Requests for consideration CR Ref. : SEM_PC_CR 204 Proposed By: ESB Powergen Priority: Medium Complexity: Medium Hours: TBC Description: MGR report inclusion of resource type This change request looks to have resource type field included in the Ex-post initial MG&NIJI public file. – GPUD ref EN 13 Rationale / Benefit Resource type is a relevant piece of data on the MG file for our data analysis group. The MG file does not currently have this as a field. To enable full and complete analysis of the market the resource type of a unit at points in time is essential. CR Ref. : SEM_PC_CR 205 Proposed By: ESB Powergen Priority: Medium Complexity: Low Hours: TBC Description: MPI Weblink User Access We are proposing this change to give Settlements users the ability to update SRA data via the Settlements system. We need the capability for people in settlement to ensure data is kept up to date in a timely manner. Rationale / Benefit The MPI currently only allows trading users to edit data. To update SRA data we currently have to request our traders to do this. If this change is not implemented then traders will have to continue to edit SRA data based on settlements requests. As this is not a standard operation for traders there is a risk of error in the process. 36 © SEMO, 2010.

Participant Change Requests for consideration CR Ref. : SEM_PC_CR 230 Proposed By: SONI Priority: Medium Complexity: High Hours: TBC Description: Meter Data Submission by Generator Unit (GU) This Change Request would allow meter data submission by GU, meaning that Meter Data submissions can be split into a number of jobs. In addition validation should be applied to the Meter Data being submitted as per the other SEM Market Feeds checking for erroneous meter data outside tolerances. Rationale / Benefit This change will speed up the processes involved around failed meter data submissions. At present SONI do not receive feedback as to which GUs failed the whole market submission. Getting a detailed response from the Market Systems will allow us to go directly to the failed units and investigate the issue. It would also allow SONI to submit the GUs separately so Meters with unreliable COMMs that periodically cause issues would not delay or hold up submission of the other meter data. This solution would also allow SONI to schedule 2 Meter Submission Tasks separating the problematic meters from the more reliable and increasing the success rate for overall meter data submission. Adding validation and warning response messages to the Meter Data Web. Service will also standardise the SEM Web. Services. 37 © SEMO, 2010.

Agenda Introduction SDS/CCF Overview Changes already in SEM R 1. 9. 0 scope Change Requests for consideration Next Steps Questions 38 © SEMO, 2010.

Provisional Priority List Proposal Ø Based on an analysis of all Change Requests, and with the agreement of the CCF, SEMO propose a provisional priority list (below) for consideration: CR Ref System Description Priority Org. Vendor Hours SEM_PC_CR 172 MI/MA MIUN Calculation High SEMO TBD SEM_PC_CR 170 FIN Payment Currency Costs High SEMO TBD SEM_PC_CR 234 STL/FIN Calc Currency Costs in Axapta to STL via Interface High SEMO TBD SEM_PC_CR 180 All Central Market Systems to use common exchange rate (entered once) High SEMO 178 SEM_PC_CR 225 STL Historical Cross Border Resettlement High SEMO TBD SEM_PC_CR 209 STL PUGDOG TTARIFF data changed to good until updated High SEMO 55 SEM_PC_CR 210 STL CDEX by Market High SEMO 128 SEM_PC_CR 200 MI Max Limit of 6 SRAs per PT in MI High SEMO TBD SEM_PC_CR 240 STL/FIN Bad Debt Smearing Process High SEMO TBD SEM_PC_CR 215 STL MSQ in public settlement reports High Airtricity 25 SEM_PC_CR 192 STL MSQ in Capacity PIR report Medium Energia TBD SEM_PC_CR 214 STL Removal of 0 INTEREST from INTEREST Import Source High SEMO 42 SEM_PC_CR 178 MI Standing Bids Conversion Event to only cater for units registered for the relevant Trading Day High SEMO 228 39 © SEMO, 2010.

Provisional Priority List Proposal Ø provisional priority list contd. : CR Ref System Description Priority Org. Vendor Hours SEM_PC_CR 190 MI/STL/ CRM SRA Cancellation in MOI High SEMO TBD SEM_PC_CR 187 MI MOI Batch Event High SEMO Opt 1) 98 Opt 2) 336 SEM_PC_CR 231 Mi/STL MI-STL Daily Push High SEMO TBD SEM_PC_CR 235 FIN Market Type included in Open Transactions High SEMO TBD SEM_PC_CR 233 FIN Invoice Details applied to Axapta Sales Journals High SEMO TBD SEM_PC_CR 232 MI Viewing Invoices on MPI High SEMO TBD SEM_PC_CR 189 MI Invoices Filter Checkbox Change Medium ESBI TBD SEM_PC_CR 241 FIN Purchase Order SBI Number in Axapta High SEMO TBD SEM_PC_CR 201 CRM Supplier and GU SRA overview in TRM High SEMO TBD SEM_PC_CR 228 CRM Calculation of Forecast ENG-CAP price in TRM High SEMO TBD SEM_PC_CR 224 STL Type 3 statement version identification Medium Airtricity TBD SEM_PC_CR 203 MA Displaying UUC Penalty Costs in MA Medium SEMO TBD 40 © SEMO, 2010.

Next Steps Ø SDS to submit those CRs (for which we do not already have an assessment) identified at this meeting to our vendors for Impact Assessment. Ø SDS to schedule and facilitate a follow-up CCF meeting to finalise non-T&SC related CRs to be included in SEM R 1. 9. 0 scope. The final list will take into account: Ø Cost Ø Benefit Ø Release capacity and Ø Vendor capacity. Ø SEMO IT Manager to issue final recommendation report to the Regulatory Authorities for approval. Ø On receiving final Regulatory approval, SEMO IT will direct our vendors to include the CRs in scope. Ø SEMO IT to publish complete scope to the industry immediately once finalised. 41 © SEMO, 2010.

Questions 42 © SEMO, 2010.