Single Electricity Market SEM Release 1.9.0 – April 2011 Change Control Forum (CCF) Meeting 21 st October 2010 (Dublin)

Single Electricity Market

SEM Release 1.9.0 – April 2011

Change Control Forum (CCF) Meeting

21st October 2010 (Dublin)

© SEMO, 2010.2

Agenda

Provisional Priority List Proposal – 15 Sep

Introduction & Review

Change Requests for consideration

Next Steps

Questions


Welcome to the second of two Change Control Forum (CCF) meetings for the SEM R1.9.0 release (April 2011).

The first meeting decided on a Provisional Prioritisation List of Change Requests (CRs) based on business criticality.

The SEM Design Service (SDS) has since secured vendor Impact Assessments for the CRs on this list.

This meeting is to finalise the list of non Trading & Settlement Code (T&SC) CRs for the April release on the basis of cost/benefit and remaining release capacity.

Subsequent to this meeting the SEMO IT Manager will issue a final recommendation report to the Regulatory Authorities (RAs) for approval.

On receiving RA approval, SEMO IT will direct our vendors to include the CRs in scope.

SDS to publish complete scope to the industry once finalised.

Please Note: CRs relating to our Finance Application do not come under the release vendor capacity agreement with ABB/Navita and can be considered separately (unless there is an interface dependency on Navita systems).

© SEMO, 2010.3

Capacity Review

The following table details what changes are already in scope. These consist of Modification Proposals, approved to date.

© SEMO, 2010.4

Modification Proposals

CR Ref Mod Ref

Description Vendor Hours

SEM_PC_CR217 46_09 Treatment of UIs for Pumped Storage Units 144

SEM_PC_CR242 12_09 Loss adjustment of SUC and NLC in CONP and MWP 72

SEM_PC_CR199 34_09 Global Settlement 1,206

Total Modification Capacity Usage 1,422

Modification Capacity Surplus 2,008

Non – T&SC Change Requests

Unused Capacity from Modifications stream 2,008

Non-T&SC Capacity Allocation 858

Total Remaining Capacity Available 2,866

© SEMO, 2010.5

Agenda




Next Steps

Questions

Provisional Priority List Proposal – ABB/Navita (15-Sep)

The following tables (over 2 pages) comprises the Provisional Priority List as determined at the CCF of 15-Sep-2010 involving CRs that are ABB/Navita related:

© SEMO, 2010.6

Change Requests raised by SEMO

CR Ref System Description Priority Org. Imp

H/M/L

Risk

H/M/L

Return

Years

Vendor Hours

SEM_PC_CR172 MI/MA MIUN Calculation High SEMO H H n/a EST 500

SEM_PC_CR225 STL Historical Cross Border Resettlement High SEMO H H n/a 1,000

SEM_PC_CR214 STL Removal of 0INTEREST from INTEREST Import Source

High SEMO H M 0.5 42

SEM_PC_CR180 All Central Market Systems to use common exchange rate (entered once)

High SEMO H M 1 178

SEM_PC_CR209 STL PUGDOG TTARIFF data changed to good until updated

High SEMO H M 1 55

SEM_PC_CR210 STL CDEX by Market High SEMO H M 3 128

SEM_PC_CR201 CRM Supplier and GU SRA overview in TRM High SEMO M H 0.5 42

SEM_PC_CR200 MI Max Limit of 6 SRAs per PT in MI High SEMO M H 2 172

SEM_PC_CR187 MI MOI Batch Event High SEMO M H 4 336

SEM_PC_CR228 CRM Calculation of Forecast ENG-CAP price in TRM High SEMO M H 4 458

SEM_PC_CR190 MI/STL/

CRM

SRA Cancellation in MOI High SEMO M H 10 770

SEM_PC_CR231 Mi/STL MI-STL Daily Push High SEMO M H 20 480

Provisional Priority List Proposal – ABB/Navita (15-Sep)

Total Vendor Hours Assessed: 7,654 hours

** Has a Finance system dependency: © SEMO, 2010.7


H/M/L

Risk

H/M/L

Return

Years

Vendor Hours

SEM_PC_CR234 STL/FIN Calc Currency Costs in Axapta to STL via Interface

High SEMO H M 6 234**

SEM_PC_CR178 MI Standing Bids Conversion Event to only cater for units registered for the relevant Trading Day

High SEMO H L 2 228

SEM_PC_CR203 MA Displaying UUC Penalty Costs in MA Medium SEMO H L 140 142

SEM_PC_CR240 STL/FIN Bad Debt Smearing Process - DEFERRED High SEMO n/a n/a n/a TBD

Total SEMO (ABB/Navita) CR Hours based on vendor impact assessments 4,765

Change Requests raised by Market Participants


H/M/L

Risk

H/M/L

Return

Years

Vendor Hours

SEM_PC_CR215 STL MSQ in public settlement reports High Airtricity H H TBC 25

SEM_PC_CR192 STL MSQ in Capacity PIR Report Medium Energia H H TBC 40

SEM_PC_CR198 MI Additional COD Validations High ESBI H M TBC 652

SEM_PC_CR224 STL Type 3 statement version identification Medium Airtricity M H TBC 1,740

SEM_PC_CR193 MI TLAF Publishing in the MPI High Energia M M TBC 432

Total Market Participant (ABB/Navita) CR Hours based on vendor impact assessments 2,889

Provisional Priority List Proposal – Finance (15-Sep)

The following table comprises those CRs that are covered by Bearing Point and are not subject to release capacity constraints – effort estimated in DAYS:

** Has an interface dependency with Navita

Notes: Implementation of CR234 covers implementation of CR170

© SEMO, 2010.8


H/M/L

Risk

H/M/L

Return

Years

Vendor Days

SEM_PC_CR170 FIN Payment Currency Costs High SEMO H H 4 25

SEM_PC_CR235 FIN Market Type included in Open Transactions High SEMO H M TBC 2

SEM_PC_CR233 FIN Invoice Details applied to Axapta Sales Journals High SEMO H M TBC 6

SEM_PC_CR234 STL/FIN Calc Currency Costs in Axapta to STL via Interface

High SEMO H M TBC 40**

SEM_PC_CR241 FIN Purchase Order SBI No In Axapta High SEMO L L TBC 4

Total Finance CR Days assuming CR234 (not CR170) is approved 52 Days

© SEMO, 2010.9

Agenda




Next Steps

Questions


The following slides detail those CRs which were agreed to be included on a Provisional

Prioritisation List from the CCF meeting of September 15th.

SEMO have subsequently secured Impact Assessments from our vendors to enable the

CCF to evaluate the implementation impact and cost of each CR.

The implementation of these CRs will: Reduce impacts on Market Participants Provide greater transparency for the SEM Mitigate the risk of Operator Error Introduce efficiencies to SEMO Market Operations (time and cost) Reduce queries to the Market Helpdesk Reduce support costs from our vendors Introduce increased robustness to the CMS


Three new classifications for each CR have been defined:

Impact on the Market of Not Implementing: High: Cashflow is affected Medium: Timelines / Credit Cover affected Low: Minor disruption

Risk of Occurrence: High : Has caused issues more than 5 times previously Medium: Has caused issues up to 5 times Low: Rarely occurs – metrics not available

Return Period: The amount of time SEMO estimates to recoup the costs of the change. This value only

considers SEMO costs, not Market Participant costs. It has been determined for CRs raised by SEMO only.

SEMO Change Requests for consideration – ABB/Navita

CR Ref.: SEM_PC_CR172

Proposed By: SEMOPriority: High Complexity: High

Hours: 500 Est

Impact On Market: High Risk of Occurrence: High Return (Years): n/a

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_CR225


Hours: 1000


Description: Historical Cross-Border Resettlement

SEM R1.8.0, through SEM_PC_CR150, will introduce a split to of charges into intra and inter jurisdictional amounts. The SEM_PC_CR150 change will only apply to Settlement Invoices relating to periods after the implementation of SEM R1.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

Impact On Participant Interfaces:

All invoices generated after implementation (including historical re-settlement) will show the split of charges into intra and inter jurisdictional amounts.


© SEMO, 2010.14


Proposed By: SEMOPriority: High Complexity: Low

Hours: 42

Impact On Market: High Risk of Occurrence: Medium Return (Years): 0.5

Description: Removal of 0INTEREST 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).

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 0INTEREST also contained in the

INTEREST import source and this has led to issues in the past.

As the variable 0INTEREST 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.

Rationale / Benefit: Reduce Impact on Market of Errors

Reduction in errors that affect workload of Market Participants and delays in the invoicing of the Market


No impact.



Proposed By: SEMOPriority: High Complexity: Medium

Hours: 178

Impact On Market: High Risk of Occurrence: Medium Return (Years): 1

Description: Exchange Rates in Central Market Systems

Central Market Systems to use common exchange rate which is entered once.

Currently controllers need to enter exchange rates separately into each of the Central Market Systems (MA, Settlements, CRM, FT). Due to the number of manual inputs there have been occurrences where exchange rates have been entered incorrectly. It is inherently prone to error due to its manual nature even with additional checks in place..

The worst instances have led to incorrect schedules being published for Ex-Ante and invoices needing to be cancelled, delayed and reissued.

Rationale / Benefit: Reduce Impact on Market of Errors, Operational Efficiency

Reduce impact on the market as a result of delayed/incorrect Pricing and Scheduling runs, and also resettlement/re-invoicing due to incorrect use of exchange rates delaying cashflow

This change will also reduce the time associated with controllers entering the exchange rate into 3 different systems and perform a check on each entry, everyday.

Impact on Participant Interfaces:

No Impact




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 : Reduce Impact on Market of Errors, Operational Efficiency

Remove impact on Market Participants of instances of resettlement due to incorrect uninstructed imbalances due to omission of charges/tariffs.

Improved efficiency of process with daily manual load of files removed.

Note: During assessment – some of the more high cost components (eg. Applying changes directly to the market system, using existing batch output to highlight errors) were descoped. The result is the most efficient implementation that will still meet the key requirements and be of most benefit


No Impact.




Hours: 128


Description: Provide a separate exchange rate for Capacity invoicing calculations Invoicing day exchange rates are 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. The current market system design does not have separate records for Energy and Capacity. The workaround process consists of having to re-import the Exchange rate for the first day of any overlapping Energy/Capacity period and each subsequent billing week.

As a result the application of these exchange rates is open to manual error. Capacity invoicing has been calculated incorrectly on some occasions and required correction.

This change request is to pprovide separate CDEX exchange rates for the Capacity/FMOC markets and the Energy markets. The rates should be imported using the Manual Line Item Import in a similar way to the current situation.

Rationale / Benefit: Reduce Impact on Market of Errors, Operational Efficiency, Auditability

Reduced likelihood of errors in exchange rates affecting Market Participants.

More efficient application of exchange rates for Capacity.

More auditable process with values not being overwritten by subsequent runs.


No Impact.


© SEMO, 2010.18



Hours: 42

Impact On Market: Medium Risk of Occurrence: High Return (Years): 0.5

Description: Supplier and GU SRA overview in TRMCurrently not all the information required for validation and approval of Credit Cover Reports is provided on the summary screen in the CRM application. The missing information relates to SRA values. The means the information must be download, a macro run and the information appended to a spreadsheet version of the report for further analysis. This is both time consuming (extra 15 min per day) and open to error.

Rationale / Benefit: Reduced Likelihood of Errors, Operational Efficiency

Reduce likelihood of errors in the validation and approval of credit cover reports

Improved efficiency of Credit Cover Report approvals


No impact.


© SEMO, 2010.19



Hours: 172

Impact On Market: Medium Risk of Occurrence: High Return (Years): 2

Description: Max limit of 6 SRAs per PT in MIEach participant should be limited to a maximum of 6 SRAs per trading day per market.When a participant attempts tosubmit a 7th SRA for a given trade date and market, it should be rejected with a message appearing indicating the reasonfor the rejection. A log of the rejected submission should also be recorded for auditing purposes.

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 AP10, 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 at the time of submission.

This means that Market Participants are not informed of ineligiblity of SRA’s at the time of submission and have additional work to reconcile the subsequently cancelled SRAs

In addition, the current process puts a daily requirement on the MO to check for these occurrences, cancel ineligible SRA’s and communicate this back to Market Participants. The email communication 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.

Rationale / Benefit: Code Compliance, Reduce Workload on Market Participants, Operational Efficiency

MO Code Compliance with regard to type 2 and 3 messages.

This means that Market Participants informed of ineligiblity of SRA’s at the time of submission reducing the additional work to reconcile the subsequent cancellations.

More efficient credit cover processes


No interface impact. However, when a Participant submits more than 6 SRAs for a trading day the submission will be rejected and an error message will be received by Participants on screen (Type 2) or in the response file (Type 3).


© SEMO, 2010.20



Hours: 336


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. 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. There have been a number of occurrences where publishing events have been delayed or incorrectly published due to the individual nature of each event.

Rationale / Benefit: Reduce Delays Impacting Market, Operational Efficiency

Reduce occurrences of publishing delays or incorrectly published

Improved efficiency of operation of the market


No impact.


© SEMO, 2010.21



Hours: 458


Description: Calculation of Forecast ENG-CAP price in TRM

Functionality to calculate Energy and Capacity Market Forecast Price in TRM 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.

Rationale / Benefit: Reduced Impact on Market of Errors, Operational Efficiency

Reduced likelihood of errors in calculation of Market Participants Exposure

Improved efficiency of credit cover operations


No impact.


© SEMO, 2010.22



Hours: 770


Description: SRA cancellation in CRM

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 there have been errors both in preparing the cancellation reports and also sending them.

The MO needs a means of identifying and cancelling SRAs in an automated fashion.

Rationale / Benefit: Reduce Impact on Market of Errors, Operational Efficiency

Market Participants provided with accurate, standardised and timely information on SRA cancellations as part of CRM activities

More efficient operation of CRM processes


No impact.


© SEMO, 2010.23



Hours: 480


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

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 some time process through the market systems. To push historical data from MI database to Settlements the window needs to be extended to X+1 days (X being historical trade date) and completed while taking into account the operational pushes required. This can lead to occasions where the data cannot be used, even though the TSO have provided it successfully. In these cases the MO has had to request the send again of the information.

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 (8 occurrences).

Rationale / Benefit - Reduce reliance of TSO/MDP for workaround, Operational Efficiency,

Reduced reliance on TSO to resubmit data when issues occur with push.

Reduced overhead on all MO functions to process the data.


No impact.


© SEMO, 2010.24



Hours: 40 Days Bearing Point

120 Est Navita


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.


No Impact.

Note: This CR has a Finance Application Dependency


© SEMO, 2010.25



Hours: 228

Impact On Market: High Risk of Occurrence: Low Return (Years): 2

Description: Standing Bid Conversion Event

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.

Change to the Standing Bids Conversion Event to only convert bids for units that are effective for the relevant Trading Day

Rationale / Benefit: Reduce Likelihood of Errors Being Missed

Reduced likelihood of real errors going unseen and affecting the Market


No impact.


© SEMO, 2010.26


Proposed By: SEMO

Priority: Medium Complexity: Low

Hours: 142

Impact On Market: High Risk of Occurrence: Low Return (Years): 140

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


No impact.

MP Change Requests for consideration – ABB/Navita

© SEMO, 2010.27


Proposed By: AirtricityPriority: High Complexity: Low

Hours: 25


Description: MSQ in Public Settlements ReportsThe 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 UnitsThese 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, byensuring that the correct version of the MSQ data is made available in the “Metered Data and NIJI” public settlementreports. 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. Atpresent neither accurate reproduction of settlement calculations, or accurate analysis, can be performed. Marketparticipants are potentially being misled.


Two new variables ‘MSQ’ (Market Schedule Quantity for Generator Units) and ‘MSQIU’ (Market Schedule Quantity for Interconnector Units) will be added to the MIR reports.


© SEMO, 2010.28


Proposed By: Energia

Priority: Medium Complexity: Low

Hours: 40


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 twotogether due to the EN & CA being out of sync. When the EN and CA revisions are out of sync we cannot shadow SEMOcalculation for Capacity charges \ payments.


Variable (MSQ) added to the Capacity Participant Information Report (PIR).


© SEMO, 2010.29


Proposed By: ESB International

Priority: Medium Complexity: Medium

Hours: 652

Impact On Market: High Risk of Occurrence: Medium Return (Years): n/a

Description:. Additional COD ValidationsPreventing 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 beentered. 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 unitsPrice values > €100/MWh for CCGTs / Coal unitsStart up costs <€100Start up costs >€1,000,000The top Q value being less than MingenAny 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

Impact On Participant Interfaces:Please see next slide…….



Proposed By: ESB International


Hours: 652


Impact on Participant Interfaces:

Four new fields in the Market Participant Registration (MPR) system to store the Max/Min Price levels and Max/Min Start Up Costs (currency will be based on Jurisdiction). These will be optional. Participants to provide these new Registration values if they wish to enforce validation rules, however if not provided then validation rules will not be enforced. This “opt in/opt out” validation approach is the first of its kind in the Central Market Systems.

As with other registration data SEMO must approve it before it is effective in the systems so normal registration data update timelines will apply on the entry/update of this data.

When validation checks fail appropriate warning messages will be issued (Type 2 and Type 3), however the offers will continue to be accepted. Market Participants can chose to revise their offer after encountering these warnings.

No reporting changes proposed.


© SEMO, 2010.31


Proposed By: Airtricity

Priority: Medium Complexity: High

Hours: 1740

Impact On Market: Medium Risk of Occurrence: High Return (Years): n/a

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-3resettlement statements. We are requesting an indicator to be used in the relevant reports / data downloads. Include a flagin 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 3statements. (e.g. D + 4, M + 4 and M +13). A new flag / signal to indicate it is an ad-hoc re-settlement would facilitateusers to easily and efficiently identify the Type-3 resettlement statements. There is a large volume of resettled days in themarket. 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 (F0015495 and F0016085) and severaldiscussions have taken place at MOUGs. This request is very similar to CR206 (Re-Pricing Flag on Reports) andtherefore consideration should be given to the benefits of combining this CR with CR206.


Please see next slide.



Proposed By: Airtricity


Hours: 1740

Impact On Market: Medium Risk of Occurrence: High Return (Years): n/a

Impact On Participant Interfaces:Although 3 options have been laid out by the Participant, the impact on Settlement will not vary much as the naming convention of the

Settlement outputs will change regardless of the option chosen. Currently the system does not indicate the processing type in its outputs

(other than ‘P’ or ‘F’), this change will be impact the same modules in Settlement so the effort between the options will differ only slightly.

The following solution our vendors believe address the requirements and will have the least impact on the system.

Naming convention for settlement statements, reports and invoice will be updated to include the settlement processing type in both the file

name and in the header records of each output.

The suggested naming conventions for settlement outputs are as below.

Settlement Statement: currentName_<processing_type>(version_suffix).csv, e.g. ENGEXG_F_PNAME_YYYY-MM-DD_INITIAL.csv

Reports: currentName_<processing_type>.csv, e.g. CA_PIR_PNAME_P_YYYY-MM-DD_INDICTIVE.csv

Invoices: currentName_<processing_type>.csv, e.g. INV_102329_PT_500040_2010_09_28_INITIAL.csv

Processing types can be one of the following: INDICATIVE, INITIAL, M4, M13, ADHOC.

For any ad-hoc runs between the scheduled processing types will be indicated by ‘ADHOC’ suffix in the file name.

The new processing type will be activated through a configuration parameter in the SettlementSetup application. When this setting is set

settlement statements, market reports and invoices will be generated using the processing type. In addition, the market operator will have

to select the ‘processing type’ in the ‘job processing’ or ‘Invoice job’ screen’ during manual processing when generating statements or

invoices.

However for batching, new task types will be created to include the ‘processing type’ and it will require creating separate batch for each

processing type.

For WebLink, statement, reports and invoice views will include a filter for ‘processing type’ and the participants can filter on the processing

type to narrow the search. The processing type will also be displayed in the list view.

This change will also require updates to the Type 3 download


© SEMO, 2010.33


Proposed By: Energia


Hours: 432

Impact On Market: Medium Risk of Occurrence: Medium Return (Years): n/a

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 WebService, our systems could downloadthis file and store it programmatically. Without this change, many TLAFs need to be manually entered for all units of theyear, which is very time consuming.

Impact on Participant Interfaces: Three options have been proposed by the vendors

Option 1: Monthly TLAF XML reports TLAF report for each calendar month in XML format Available via Type 2 & Type 3

Option 2: Annual CSV report One report in CSV format that covers the full year (does not resolve scalability issues) ABB Report Manager will require upgrade to generate CSV files

Option 3: Monthly CSV reports CSV report for each calendar month in CSV format (addresses scalability) ABB Report Manager will require upgrade to generate CSV files

ABB recommends Option 3 from the future scalability and end-user point of view.

Change Requests for consideration (Finance)

Our Finance Application vendor is Bearing Point.

CRs relating to our Finance Application do not come under the release vendor capacity agreement with ABB/Navita and can be considered separately (unless there is an interface dependency on Navita systems).

Estimates provided by Bearing Point are in Days.

When reviewing the following slides it should be noted that the functionality of SEM_PC_CR170 is also included in SEM_PC_CR234, i.e. if SEM_PC_CR234 is implemented then SEM_PC_CR170 will not be required.


© SEMO, 2010.35



Days: 25


Description: Payment Currency Costs

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 : Reduce Errors Impacting the Market, 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 mitigate future issues raised in the Market Audit and reduce the manual processing which is open to error.


No impact.

Note: The functionality of SEM_PC_CR170 is also included in SEM_PC_CR234, i.e. if SEM_PC_CR234 is implemented then SEM_PC_CR170 will not be required.


© SEMO, 2010.36



Days: 2


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.


No impact.




Days: 6


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 and rework due to corrections identified during authorisation of payments.


No impact.



Days: 40


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.


No impact.


Note: The functionality of SEM_PC_CR170 is also included in SEM_PC_CR234, i.e. if SEM_PC_CR234 is implemented then SEM_PC_CR170 will not be required.




Days: 4

Impact On Market: Low Risk of Occurrence: High Return (Years): n/a

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.


No impact.

© SEMO, 2010.40

Agenda




Next Steps

Questions

Next Steps

CCF (this meeting) to agree a priority list of CRs to be considered for April scope (SEM R1.9.0)

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 (subject to vendor capacity).

SEMO IT to publish complete scope to the industry immediately once finalised.

© SEMO, 2010.41

© SEMO, 2010.42

Questions

Documents

Single Electricity Market SEM Release 1.9.0 – April 2011 Change Control Forum (CCF) Meeting 21 st October 2010 (Dublin)