{"text_format":"3","workbook":"xls","n_sheets":5,"sheets":["Modifications","Change Proposals","Issues","Releases","CP IA Timetable 2016-17"],"not_rendered":{"images":5,"external_links":2,"defined_names":26},"read":"whole","date_system":"1900","formulas":"cached_only"}

{"sheet":"Modifications","index":0,"n_rows":365,"n_cols":42,"rows_kept":365,"merged":[[5,12,5,41],[6,0,6,5],[6,6,6,9],[6,10,6,11],[6,12,6,16],[6,17,6,21],[6,22,6,26],[6,27,6,31],[6,32,6,36],[6,37,6,41],[7,12,8,12],[7,13,8,13],[7,14,8,14],[7,15,8,15],[7,16,8,16],[7,17,8,17],[7,18,8,18],[7,19,8,19],[7,20,8,20],[7,21,8,21],[7,22,8,22],[7,23,8,23],[7,24,8,24],[7,25,8,25],[7,26,8,26],[7,27,8,27],[7,28,8,28],[7,29,8,29],[7,30,8,30],[7,31,8,31],[7,32,8,32],[7,33,8,33],[7,34,8,34],[7,35,8,35],[7,36,8,36],[7,37,8,37],[7,38,8,38],[7,39,8,39],[7,40,8,40],[7,41,8,41],[8,0,8,11],[22,6,22,41]],"flags":["formulas_cached_only"]}
[]
[]
[]
[{"$nulls":5},"BSC Change Register"]
[" ",{"$nulls":4},"Modifications"]
[]
["Details",{"$nulls":5},"  Progression",{"$nulls":3},"Decision",null,"May",{"$nulls":4},"June",{"$nulls":4},"July",{"$nulls":4},"August",{"$nulls":4},"September",{"$nulls":4},"October"]
["Change Ref.","Title","Proposer","Date Raised","Problem/Issue","Solution","Current Status","Urgent","Self Gov","Implementation date","Panel Recommendation","Ofgem Decision","1st - 5th","8th - 12th","15th - 19th","22nd-26th","29th - 31st","1st - 2nd","5th - 9th","12th - 16th","19th-23rd","26th - 30th","3rd - 7th","10th - 14th","17th - 21th","24th-28th","31th","1st - 4th","7th - 11th","14th - 18th","21at-25th","28th-31st","1st ","4th - 8th ","11th - 15th ","18th - 22nd","25th - 29th ","2nd - 6th","9th - 13th ","16th - 20th ","23th - 27nd","25th - 29th "]
["Open Modifications"]
["P297","Receipt and Publication of New and Revised Dynamic Data items","National Grid","2013-07-24","Changes are being made to the Dynamic Data Set in preparation for EBS go-live in the first quarter of 2015. The Dynamic Data Set is published on the Balancing Mechanism Reporting Service to help parties understand why particular Bids and Offers have been accepted. Consequently it is important that the Dynamic Data Set detailed in the BSC and published on the BMRS is the same.","P297 seeks to ensure that the BMRA and SAA systems are updated to enable BSCCo to receive and publish the new and revised Dynamic Data items from the Transmission Company.","Originally approved by the Authority on 28 Apr 14 for implementation on 05 Nov 15. The Authority approved an extension to the Implementation Date on 16 Mar 15, with implementation on 03 Nov 16. The Authority approved a further extension on 08 Aug 16, with implementation now scheduled for 29 Jun 17. The Panel requested an extention to the Implementation Date from June 2017 to November 2018. The revised Implementation Date is with the Authority for approval. ","No","No","2017-06-29","Approve","Approve",{"$nulls":9},"Implement"]
["P321","Publication of Trading Unit Delivery Mode","Smartest Energy","2015-04-01","Currently, there is no explicitly-provided information on whether a Trading Unit is delivering or offtaking in a given Settlement Period. The Proposer contends that this lack of visibility can hinder customers’ ability to independently verify their bills or assess which type of contract is right for them.","P321 proposes to publish information on the direction of delivery of Trading Units, particularly for each Grid Supply Point Group, in each Settlement Period. This information can currently be inferred through BSUoS bills and TLM values, but P321 would explicitly provide this information.","Originally approved by the Panel on 08 Oct 15 under Self-Governance for implementation on 30 Jun 16. The Authority approved an extension to the Implementation Date on 26 Jan 16, with implementation on 03 Nov 16. The Authority approved a further extension on 08 Aug 16, with implementation now scheduled for 29 Jun 17.","No","No","2017-06-29","Approve","Approve",{"$nulls":9},"Implement"]
["P329","Changes to REMIT inside information reporting","National Grid","2015-11-25","ACER has set out its expectation for standardised web feeds within its REMIT Manual of Procedures on data reporting. As the national reporting platform is the BMRS, ACER will expect the BMRS to comply with the web feed and data reported to it. ","P329 proposes to align the BSC and BMRS with the REMIT common schemas for inside information web feeds, required by ACER. ","At its meeting on 10 March 2016, the Panel recommended that the approval of the Alternative and rejection of the Proposed. On 19 April 2016, the Authority approved the P329 Alternative and rejected the P329 Proposed. The P329 Alternative will be implemented on 29 June 2017.","No","No","2017-06-29","Reject Proposed\nApprove Alternative","Reject Proposed\nApprove Alternative",{"$nulls":9},"Implement"]
["P332","Revisions to the Supplier Hub Principle","Smartest Energy","2016-01-28","Revisions to the nature of the Supplier Hub principle are required to take account of the fact that Suppliers do not always have a contractual relationship with the Agents they are supposed to be managing.","P332 seeks to make Agents signatories to the BSC and make all of their activities directly accountable to the Performance Assurance Board (PAB) and ELEXON.","A verbal update was given to the Panel at its May meeting. The Panel requested an interim report on P332, which will be presented to the Panel on 13 July 2017. A fourth Workgroup meeting was held on 31 May 2017 to develop the interim report. A data request has been was issued to industry on 5 June. Responses are due 26 June. Suppliers and Supplier Agents have been requested to provide data relating to Customer Preferred Agent instances.","No","No","TBC","TBC","TBC",{"$nulls":12},"Interim Report"]
["P335","Inclusion of Non-BM STOR costs and volumes in the indicative cashout price","ENGIE","2016-02-19","P335 contends that the cashout price published after the end of a Settlement Period cannot be relied upon, due to the potential change between the indicative price calculation and the II Settlement Run calculation. The potential change raised from the  delay in the inclusion of non-BM-STOR, which can result in both a change in the direction of the Net Imbalance Volume (NIV), from long to short, and a change in the cashout price. This unreliability reduces the incentive to balance and can lead to sub-optimal trading decisions being made.","P335 seeks to facilitate the submission of non-BM STOR costs and volumes such that they can be included in the indicative cashout price. It aims to improve the incentivising signals provided by cashout and facilitate optimal trading decisions by participants.","P335 was approved by the Authority on 19 September 2016. (16/07)  IIA for P335 was issued on 13 June 17, with a response deadline of 16 June. There are 5 IIAs outstanging.","No","No","2017-11-02","Approve","Approve"]
["P336","Fuel types on the BMRS","Drax Power Limited","2016-02-29","The Proposer has noted the rise in biomass generation and that this is not reported as a specific fuel type on the BMRS. They also believe it should be easier to amend the list of fuel types reported on the BMRS without having to raise a Modification each time.","P336 proposes to add ‘biomass’ as a specific fuel type category reported on the Balancing Mechanism Reporting Service (BMRS). It also seeks to allow the Panel to approve further fuel types without needing to raise a Modification.","The Panel approved P336 on 14 Apr 16 under Self-Governance for implementation on 02 Nov 17. The Self-Governance appeal window will close on 06 May 16","No","Yes","2017-11-02","Approve","N/A"]
["P342","Change to Gate Closure for Energy Contract Volume Notifications","EDF","2016-05-25","The explicit coupling of the time at which PNs and other parameters relating to the dispatch of plant are locked in, and the time at which Energy Contract Volume Notifications (ECVNs) are locked in is unnecessary, reduces competition, and requires Parties to trade in a manner which is less efficient than might otherwise be the case. It also creates difficulty for future developments in intra-day trading using coupled EU auctions, for which trading up to 1 hour before a traded period must be allowed, but results may not be known until after the current definition of Gate Closure.","This modification would introduce the concept of a ‘Final ECVN Submission Time’ for each Settlement Period. This time would be decoupled from the current Gate Closure time and would be set to 30 minutes after the end of the relevant Settlement Period. This would permit energy trades to continue to be notified until the indicative imbalance price had been set. This modification would additionally amend references within the Balancing Settlement Code (BSC) from ‘Gate Closure’ to ‘Final ECVN Submission Time’ where those references are relevant to ECVN submissions, or trigger calculations which refer to the Account Bilateral Contract Volume (including, for the avoidance of doubt, Energy Indebtedness calculations within BSC Section M).","The Initial Written Assessment was presented to the Panel on 9 June 2016. The Panel agreed to submit P342 to an Assessment Procedure with the Assessment Report due to be presented by 10 November 2016. At its meeting on 10 November the Panel agreed to submit P342 to the Report Phase. The Panel made its final recommendation that the Alternative Modification should be approved on 8 December 2016. Authority approved P342 Alternative Modification on 1 February 2017.  ","No","No","2017-11-02","Reject Proposed\nApprove Alternative","Reject Proposed\nApprove Alternative"]
["P344","Project TERRE implementation into GB market arrangements","National Grid","2016-06-01","National Grid is expected to utilise TERRE Products for energy balancing in GB from TERRE go-live. This is currently scheduled for summer 2018. As all current GB balancing products feed into the BSC calculations of imbalance prices and volumes, so should relevant TERRE Products too, as soon as they start to be used as part of GB balancing. This will require changes to the GB market arrangements (the BSC, the Balancing Services arrangements or both).","This Modification proposes to align the BSC with the European Balancing Project TERRE\n(Trans European Reserves Exchange) requirements. This is in order to allow the\nimplementation of the project at national level and be compliant with the first tranche of\nobligations in the European Network Codes (ENCs).","The Panel agreed to progress P344 to the second stage of the Assessment Procedure. P344 is currently  Assessment through nine Workgroup meetings to cover the detailed work under the project. The first Industry Consultation has been completed. The Assessment Report is expected to be delivered to the Panel in May 2018.","No","No","TBC","TBC","TBC"]
["P348","Provision of gross BM Unit data for TNUoS charging","EDF","2016-07-01","P348 seeks to enable the Supplier Volume Allocation Agent (SVAA) to provide gross export and gross import data to the Transmission Company (TC) to support proposed revisions to the Transmission Network Use of System (TNUoS) Charging methods under CMP265.","The TC currently receives the Transmission Use of System (TUoS) Report (P0210 – Half Hourly (HH) / Non Half Hourly (NHH) split) from the SVAA. the TC uses the data in this report to calculate indicative and actual TNUoS charges. Currently, the TUoS report provides the “Period HH Allocated Volume” data in the “HHA Record Types” (for Supplier Balancing Mechanism Units (BMUs)) on the basis of demand net generation within Grid Supply Point (GSP) Groups. To facilitate CMP265 we propose that the SVAA report details of gross import and export volumes by inserting two new columns: “Period BMU HH Allocated Gross Import Volume” and “Period BMU HH Allocated Gross Export Volume” into the TUoS report.","The P348 Proposer raised this Modification with a request for Urgency. The Panel met on 4 July to consider this request and unanimously recommended to the Authority that P348 be treated as an Urgent Modification Proposal. The Authority made its determination on 11 July that P348 should not be treated as Urgent. The first Workgroup meeting was held on 12 July 2016. The Assessment Consultation will be issued on 5 August. The Panel approved a two month extension on 8 September. ELEXON since requested a third two month extension which the Panel approved. The second Assessment Consultation was issued on 20 February 2017 with responses due by 13 March 2017. The Assessment Report was presented to the Panel at its meeting on 13 of April. The Report Phase Consultation was issued on 19 April 2017 with responses due by 8 May 2017. This Modification is progressed in line with P349. The Panel recommended conditional approval of Options 1, 2 and 3 depending on Ofgem's decision on the CUSC modifications. The Final Modification Report was sent to the Authority on 22 May 2017. We expect the decision will be made by the end of June 2017. ","No","No","2018-02-22","Conditional approval (depending on Ofgem decisionon CMP264/265)","TBC",null,"Draft Modification Report"]
["P349","Facilitating Embedded Generation Triad Avoidance Standstill","ScottishPower","2016-07-04","P349 seeks to facilitate the implementation of CMP264. CMP264 seeks to make changes to the Transport and Tariff Model and billing arrangements to remove the netting of output from New Embedded Generators until Ofgem has completed its consideration of the current electricity transmission Charging Arrangements (and any review which ensues) and any resulting changes have been fully implemented.","This Modification will introduce a requirement under the BSC for Suppliers that are the registrants of New Embedded Generators to tell their Half Hourly Data Aggregators (HHDAs) which Metering System IDs (MSIDs) relate to New Embedded Generation. They will also be requited to tell their HHDAs to provide Period Metered Data from these MSIDs to the Transmission Company (TC) in the most efficient and cost-effective manner.","The P349 Proposer raised this Modification with a request for Urgency. The Panel met on 4 July to consider this request and unanimously recommended to the Authority that P349 be treated as an Urgent Modification Proposal. The Authority made its determination on 11 July that P349 should not be treated as Urgent. The first Workgroup meeting was held on 12 July 2016. The Assessment Consultation will be issued on 5 August. The Panel approved a two month extension on 8 September. ELEXON since requested a third two month extension which the Panel approved. The second Assessment Consultation was issued on 20 February 2017 with responses due by 13 March 2017. The Assessment Report was presented to the Panel at its meeting on 13 of April. The Report Phase Consultation was issued on 19 April 2017 with responses due by 8 May 2017. This Modification is progressed in line with P348. The Panel recommended conditional approval of Options 1, 2 and 3 depending on Ofgem's decision on the CUSC modifications The Final Modification Report was sent to the Authority on 22 May 2017. We expect the decision will be made by the end of June 2017.","No","No","2018-02-22","Conditional approval (depending on Ofgem decisionon CMP264/265)","TBC",null,"Draft Modification Report"]
["P350","Introduction of a seasonal Zonal Transmission Losses scheme","National Grid","2016-07-05","The Competition and Markets Authority (CMA) has concluded that the absence of locational pricing for transmission losses has an adverse effect on competition.","In line with the CMA’s remedy, P350 proposes to introduce a Transmission Loss Factor for each Grid Supply Point (GSP) Group for each BSC Season in order to allocate transmission losses on a geographical basis. This solution will be the same as the proposed solution under Rejected Modification P229.","Ofgem approved P350 on 24 March 2017 for implementation on 1 April 2018. \n\nThe Panel unanimously agreed to recommend to Ofgem that P350 should be approved at its meeting on 9 February 2017. The Final Modification Report was sent to Ofgem on 10 February 2017.\n\nThe Panel unanimously agreed an initial recommendation that P350 should be approved and agreed to submit P350 to the Report Phase at its meeting on 19 January 2017.The Report Phase Consultation was issued on 20 January 2017, with responses due by 2 February 2017. The Draft Modification Report will be presented to the Panel on 9 February 2017.\n\n11 Industry Impact Assessment responses were received. These were discussed by the Workgroup at its second meeting on 18 October 2016. We received 20 responses to the Assessment Procedure Consultation, which closed on 25 November 2016. The third Workgroup meeting has been brought forward two days, so that any material outcomes from the meeting can be considered by the CMA before they finalise the Order. It's expected the Workgroup will focus on the consultation responses and the CFD issue in particular.\n\nThe Assessment Report was presented at the January Panel meeting, which has been pushed back a week to 19 January 2017. As a result, the Draft Modification Report will be presented to the Panel at its February meeting as a late paper. This will provide a 10WDs consultation period, but will allow Ofgem to receive the Draft Modification Report as scheduled. The CMA is mandating that its remedy is implemented on 01 Apr 18. The Panel approved P350 and the FMR is with the Authority. Expected decision in March. ","No","No","2018-04-01","Approve","Approve"]
["P354","Use of ABSVD for non-BM Balancing Services at the metered (MPAN) level","ENGIE","2017-01-11","The Proposer identified a defect in the current arrangements for notifying ABSVD.","The proposed solution is to allow the SO to provide ABSVD volume at the MPAN level and the SAA to allocate this to the appropriate Supplier BM Unit. ","P354 was raised on 11 January 2017. The IWA was presented to the Panel at its meeting on 9 February 2017. The Panel agreed to progress P354 to six months Assessment Procedure. The third Workgroup meeting will be held on 23 June 2017 to discuss the solution before issuing this for Assessment Procedure Consultation. ","No","No","TBC","TBC","TBC"]
["P355","Introduction of a BM Lite Balancing Mechanism","PeakGen","2017-06-21","Under the current BM, it is difficult for smaller parties to compete directly with larger generators for the provision of energy to the TC, as the GB System Operator for balancing. This is because there is a lack of access to the BM for smaller plants in a way that would allow them to compete on a level playing field with larger power stations. ","P355 proposes to introduce a new BM Lite Balancing Mechanism to allow smaller generators to offer energy to the System Operator for energy balancing, in competition with the larger BM Units already in the market. ","The IWA for P355 will be presented to the BSC Panel at its meeting on 13 July 2017. ","No","No","TBC","TBC","TBC",{"$nulls":11},"IWA"]
[{"$nulls":5},"Closed Modifications"]
["P353","Fast Track Self-Governance Mod following P324","Panel","2016-11-10","P324 redlining missed the following in Section B 3.1.2 (h) :- approving the Business Strategy prepared by BSCCo for each BSC Year, and revisions to that plan;‘ no longer is applicable and needs to be removed.","Align Section B with the intent of P324. Nov Panel agreed the progression of a Fast Track Self Governance Modification to address this ‘manifest error’. 6 January 2017 implementation after allowing 16 Business Days for an appeal post December’s Panel meeting.","Panel: 8 December 2016","No","Yes","2017-01-06","Approve","Fast Track Self-Governance"]
["P352","Housekeeping changes to BSC Section M","BSC Panel","2016-07-29","The approved legal text for P345 does not match the intention of the original Modification proposal. Further, part of the approved legal text for P307 was not implemented. This Modification seeks to rectify these Housekeeping errors.","The typographical error in the P345 legal text will be corrected and the P307 legal text will be incorporated into Section M of the BSC."," Panel: 11 August 2016 ","No","Yes","2016-09-16","Approve","Fast Track Self-Governance"]
["P351","Align the BSC with changes to the SCR requirements","National Grid","2016-07-29","As an output of CGR phase 3 this modification has been raised to present Ofgem with additional powers to Create, assess and implement changes to the BSC aligned with the Licence. ","The proposal is to align Section F of the BSC with the changes to Transmission Licence, Standard Licence Condition C3 ‘Balancing and Settlement Code (BSC)’ being proposed by Ofgem. The Standard Licence Condition changes propose three routes under Significant Code Review (SCR) for a Modification to be progressed, with potential allowance to move between the processes.","Authority: 1 March 2017","No","No","2017-04-01","Reject ","Approve Proposal\nReject Alternative"]
["P347","Reduction in R1 Read Threshold ","Npower","2016-07-01","A barrier to Elective HH highlighted by Ofgem and discussed at the SRAG is the R1 read performance target for HH sites in the BSC. HH meters enrolled into DCC are unlikely to consistently meet this target which will result in penalties for Suppliers who have large volumes of Elective HH meters.","The Modification looks to reduce the performance threshold for Elective HH meters to 90% from 99%. This will reduce the likelihood of Suppliers being penalised for performance of Elective HH sites enrolled into DCC. ","Authority: 30 January 2017","No","No","2017-04-01","Reject","Approve"]
["P346","Changes to Specific Charges for Elective HH Settlement ","British Gas","2016-06-23","A barrier to Elective HH highlighted by Ofgem and discussed at the SRAG is the BSC Specific Charging methods. The current methods of recovering costs would mean that all HH customers regardless of their end use type and potential risk to Settlement will be charged the same base rate on a Monthly basis.","This Modification looks to amend the BSC Specified Charging Methodology to remove a barrier to Elective HH Settlement. 1. Charging HH sites as they are today (MC C) but charging MC’s E, F and G through the NHH method. This will have the effect of having the same charge as if there was no change in the recording method. 2. Creating a New Specified Charge to reflect the different Customer types in the HH Market. A charge for MC C and a separate charge for MC E, F and G. This method will reflect that the demands on the SVA systems are not the same reducing the cost to Suppliers if they wish to promote the HH market to their customers. \n","Panel: 10 November 2016","No","Yes","2017-04-01","Approve","Self-Governance"]
["P345","Reducing the CAP change notice period and improving its flexibility’","SSE plc","2016-06-02","The BSC requires that the effective date of any change to CAP shall not be earlier than the 20th Business Day following the notification date, in practice meaning implementing a new CAP value takes on average six weeks. Recent volatility in market prices means a more flexible process for changing the CAP would enable it to better reflect reference electricity prices.  Reducing the notice period for changing the CAP would enable it to be changed more quickly, which would allow the CAP to reflect more recent data and better react to market conditions. The benefit of a revised CAP value being applied in the calculation of AEI would also be delivered more quickly. In addition, a Modification is required to change the notice period, further limiting flexibility of the CAP review process.\n","Following discussion by the Credit Committee and BSC Panel, seeks to reduce the notice period for changes to the Credit Assessment Price (CAP) to 15 Business Days. P345 would also enable the notice period to be changed in future without a Modification as long as it remains above a minimum value set out in the BSC and such a change is consulted upon. The Panel approved P345 under Self-governance. The Self-Governance appeal window closed with no objections on 5 August 2016.","Panel: 14 July 2016","No","Yes","2016-08-19","Approve","Self-Governance"]
["P343","Increase to the number of Supplier IDs that can be held by a Supplier","RWE npower","2016-05-26","Multiple Supplier IDs were formalised in the BSC by the implementation of Modification Proposal P106, with the restriction that a Supplier may hold no more than three Supplier IDs in relation to which the Supplier is the first holder of such Supplier ID. ","This Modification seeks a review of the limit imposed in Section S1.3.5, with a view to amending the BSC to increase the number of Supplier IDs that a Supplier may hold. "," Panel: 10 November 2016","No","Yes","2017-02-23","Approve","Self-Governance"]
["P341","MEL and other data earlier than Gate Closure","EDF","2015-07-20","EDF wishes for more forward looking MEL and MIL data to be published on BMRS in order to aid transparency in the market.","P341 would extend the time period where the Transmission Company is required to send Maximum Export Limit (MEL) and Maximum Import Limit (MIL) data to the Balancing Mechanism Reporting Agent (BMRA) for each Balancing Mechanism (BM) Unit to be published on the Balancing Mechanism Reporting Service (BMRS). The purpose of the Modification is to increase the transparency in the market by allowing all Market Participants visibility of the availability of each BM Unit for the window where MEL and MIL data is published.","Closed","No","No","N/A","N/A","Withdrawn"]
["P340","Removal of References and Requirements Relating to the LCPD’","BSC panel","2016-05-12","The Large Combustion Plant (National Emission Reduction Plan) Regulations 2007, enacting The Large Combustion Plant Directive “LCPD”, has been revoked and replaced with The Large Combustion Plants (Transitional National Plan) Regulations 2015 enacting the Industrial Emissions Directive, the “IED”. The LCPD had introduced a number of reporting obligation into the BSC. The IED has changed the legislative basis of those reporting obligations and the reporting will now be to the Environment Agency. This means that sections of the BSC relating to Large Combustion Plant reporting are obsolete and should be removed as parties will no longer be meeting these requirements.","Changes in legislation mean that references and reporting requirements in the BSC relating to Large Combustion Plant Directive have been rendered obsolete. This Modification seeks to remove the relevant provisions from the BSC and subsidiary documentatio. The Panel approved P340 on 9 June 16 as a Self-Governance Modification for implementation five Working Days following approval. The Self-Governance appeal window closes on 30 June 16.\n","The Panel: approved on  9 June 16 ","No","Yes","2016-07-07","Approve","TBC"]
["P339","Introduction of new Consumption Component Classes for Measurement Classes E-G","Ovo","2016-05-20","Spill from embedded generation is currently an issue for Suppliers and for the accuracy of Settlement. Export from embedded generation should be metered and settled.","The SRAG recommends that a BSC Party raises a BSC Modification to create new Consumption Component Classes (CCCs) for Aggregated HH Export. This will allow aggregated HH export data to enter Settlement for smaller customers (that are in Measurement Class F ‘Domestic HH Current Transformer (CT) and whole current (WC) Metering Systems’ or Measurement Class G ‘non-domestic HH WC metered Metering Systems’). This change will provide for the interaction of the improved HH settlement processes recommended above and the implementation of new Measurement Classes with Modification P300 in November 2015."," Panel: 8 December 2016","No","Yes","2017-04-01","Approve","Self-Governance"]
["P338","Consequential changes to P272 legal text","BSC Panel","2016-04-14","Since the approval of P272 'Mandatory Half Hourly Settlement for Profile Classes 5-8', two other Modifications, which amended the requirements of P272, have been approved. We have identified some potential conflicts and overwriting to the approved legal text of P272.","P338 proposes to make consequential changes to the approved legal text for P272 ‘Mandatory Half Hourly Settlement for Profile Classes 5-8’, to resolve conflicts that exist between it and certain approved Modification."," Panel: 14 April 2016","No","Yes","2017-04-01","Approve","Self-Governance"]
["P337","Extension to the payment timescales for Quarter Date Advice Notes below the Advice Note Threshold Limit","BSC Panel","2016-03-10","Currently, for Quarter Date Advice Notes below the Advice Note Threshold Limit (ANTL) need to be paid within three Business Days. Otherwise the Party enters into Section H Default. ELEXON recommended to the Panel in September 2015 that a Modification be raised to extend the short timescales. They agreed that this should be done. ","P337 seeks to extend the payment timescales for Quarter Date Advice Notes below the ANTL of £500 from three Business Days to 15 Business Days. This will allow ELEXON to defer action, giving Parties an additional 13 Business Days to pay the Advice Note and avoid unnecessary actions, such as the Party defaulting.","Panel: 14 Apr 16 ","No","Yes","2016-11-03","Approve","Self-Governance"]
["P334","Inclusion of Non-BM STOR costs and volumes into the cashout price in time for publication after the end of the Settlement Period","ENGIE","2016-02-28","National Grid are obligated to send non BM STOR to BMRA as part of their estimated BSAD (at the end of a Settlement Period) and actual BSAD (the day after).The proposer believes there should be an explicit obligation in the BSC to send non-BM STOR rather than just the obligation to send BSAD.","P334 proposes to place a specific requirement on the Transmission Company to provide its best estimate of non Balancing Mechanism (BM) Short Term Operating Reserve (STOR) volumes and costs as part of its Balancing Services Adjustment Data required under paragraph 6.3.1(a) (ii) of BSC Section Q. ","IWA: 11 Feb 16, Withdrawal Notification issued on 12 Feb 16.","No","No","N/A","N/A","N/A"]
["P333","Inclusion of DSBR volumes into the cashout price in time for publication after the end of the Settlement Period","ENGIE","2016-01-28","P333 contends that not including DSBR volumes in cashout until the II Settlement Run, five days after the relevant Settlement Day, could result in misleading signals to market participants. ","P333 seeks to place a specific requirement on the Transmission Company to provide its best estimate of Demand Side Balancing Reserve (DSBR) volumes as part of its Balancing Services Adjustment Data required under paragraph 6.3.1(a) (ii) of BSC Section Q.","Authority: 2 August 201.","No","No","03 Nov 16 ","Approve ","Approve "]
["P331","Extended Dispute Deadline at the Post-Final Settlement Run under exceptional circumstances","BSC Panel","2016-01-14","There is a lack of flexibility for the TDC and the Panel to extend the Dispute Deadline at the Post-Final Settlement Run under exceptional circumstances. This meant that a proportion of the Settlement Error associated with Trading Dispute DA686 could not be corrected.","P331 seeks to extend the Dispute Deadline for Settlement Errors at the Post-Final Settlement Run from one month to two months, under exceptional circumstances. The Panel agreed to raise P331 and progress to the Report Phase, with determination under Self-Governance. At its meeting of the 10 March 2016, the Panel approved P331 under Self-Governance with the Appeals window closing on 5 April 2016.\n","The Panel: approved on 10 March 2016","No","Yes","2016-06-30","Approve ","TBC"]
["P330","Allowing ELEXON to tender for the Uniform Network Code Gas Performance Assurance Framework Administrator (PAFA) role","ScottishPower Energy Retail","2015-12-01","Under the gas Uniform Network Code (UNC) there are two Modifications seeking to introduce performance assurance arrangements into the gas market for the first time. The P330 proposers believes that should these changes be approved ELEXON should have the opportunity to partake in any tender process for the Performance Assurance operator. The BSC currently prohibits this.\n","P330 seeks to enable ELEXON (as BSCCo), to bid for the role of gas PAFA under the UNC (and perform the role if the contract is awarded to ELEXON) should MOD506 be approved by the Authority. Assessment Report presented to the Panel in Apr16. P330 is proposed for implementation 5 Working Days following Authority approval. The Panel made an initial recommendation that the P330 be rejected. Draft Modification Report presented to the Panel on 12 May 2016. Panel's final recommendation by majority is that P330 be rejected. Issued to the Authority for decision. Authority approved on 25 May for implementation on 2 June.","Authority: approved on 25 May","No","No","2016-06-02","Approve","Approve"]
["P328","Clarifying BSC SBR definitions to align with the BSAD and SMAF Methodology Statements","National Grid","2015-11-06","National Grid required to align the definitions with the recent changes to the C16 Licence Statements: Balancing Services Adjustment Data (BSAD) and System Management Action Flagging (SMAF) Methodology Statements, which the Authority has since approved.","P328 proposes to amend the definitions of Supplemental Balancing Reserve (SBR) and SBR Action in the BSC as modified by P323 ‘Enabling inclusion and treatment of SBR in the Imbalance Price’. ",null,"Yes",null,"2015-11-16","Approve","Approve"]
["P327","Clarifications to P305 legal text","BSC Panel","2015-09-10","Since the approval of P305 in April 2015, ELEXON has identified minor errors and areas of\nambiguity in the approved P305 legal text. To ensure that P305 is delivered as intended, these\nshould be clarified","P327 proposes minor changes to the approved legal text for P305 to correct some minor inconsistencies and improve the clarity of some new definitions.",null,"No",null,"2015-11-05","Approve","Fast Track Self-Governance"]
["P326","Introduction of a non-Working Day adjustment to the Credit Cover Percentage calculation","Haven Power","2015-08-25","The Proposer believes that there is a limitation in the calculation of Credited Assessment Energy Indebtedness for Supplier BM Units, as the calculation does not account for differences in consumption between Working Days and non-Working Days. ","P326 proposes to introduce a method to account for reductions in Supplier demand on non-Working Days within the Credit Cover calculations.\n\nThe Proposed Modification seeks to do this by applying a Demand Capacity Factor (DCF) to the calculation of Supplier BM Units’ BMCAIC.\n\nThe Alternative Modification seeks to do this by calculating two CALF values for Supplier BM Units, with one applying to Working Days and the other to non-Working Days.","Panel approved the Alternative Modification on 14 Apr 16","No","Yes","2017-02-23","Reject Proposed\nApprove Alternative","Self-Governance"]
["P325","Improving the accountability of BSCCo to stakeholders and better aligning BSCCo governance with best practice","SSE Energy Supply Ltd","2015-07-30","The Proposer believes that current provisions restrict BSCCo’s ability to comply with good corporate governance, as set out in the UK Corporate Governance Code. In particular, the Proposer believes that lack of accountability and greater alignment with the UK Corporate Governance Code could be resolved if ELEXON were to have shareholders. ","P325 proposes to amend the BSC to make BSCCo (ELEXON) accountable to its shareholders by issuing shares in BSCCo to BSC Parties, in proportion to their annual funding share(s). In addition, allow those parties to release or receive additional shares; and allow Distribution Network Operators (DNOs) and New Entrants to obtain shares.","\nClosed : 25 May 2017.\n","No","No","N/A","Withdrawn","N/A"]
["P324","Review of BSCCo’s governance: introducing improved accountability to BSC Parties\n","National Grid","2015-07-24","The Knight Report 2013 identified a number of weaknesses in the current governance arrangements for the BSCCo, in particular, the relationship between BSCCo, the BSCCo Board and the BSC Panel. Changes are therefore required to the current provisions to align them with the UK Corporate Governance Code and bring them into line with best practice.","P324 proposes to implement changes to BSCCo’s governance arrangements. The Proposed Modification will:\n> allow Parties to vote to remove Directors;\n> allow Parties to vote on non-binding resolutions on other matters;\n> allow for up to two executive Directors to be appointed;\n> allow the Board to remunerate any of its non-executive Directors;\n> allow the Board to set BSCCo’s Business Strategy;\n> allow the Board Chairman and the Panel Chairman to be separate people; and\n> remove the need for the Authority to approve the Panel Chairman's remuneration.\n\nThe Alternative Modification is identical except that remuneration will remain limited to 'non-industry' non-executive Directors only.\n","Authority: 14 October 2016","No","No","2016-11-11","Approve","Approve"]
["P323","Enabling inclusion and treatment of SBR in the Imbalance Price’","National Grid","2015-06-26","Recent developments in the work on reflecting Supplemental Balancing Reserve (SBR) into cash-out have included BSC Issue 56 ‘Treatment of the new SBR and DSBR services in the imbalance price’, two Open Letters1 published by NGET and an NGET-led Industry Workshop in February 2015. The view from the Issue 56 Group (and proposed in the latest Open Letter published on 15th June) is that SBR should be priced at the Value of Lost Load (VoLL) as it reflects that Demand Control would be required in its absence. At present, should SBR be dispatched it would be System Operator (SO)-flagged as per the System Management Action Flagging (“SMAF”) Methodology. In order to reflect SBR into the imbalance calculation we propose that, when Supplemental Balancing Reserve (SBR) is dispatched in the Balancing Mechanism (BM), the resulting action(s) will initially enter the Indicative imbalance price calculation based on the units “Utilisation Price”. However, this should then be changed retrospectively to be priced at VoLL in the imbalance calculation (e.g. following notification by NGET – for instance via the BSCP18 ‘Corrections to Bid-Offer Acceptance Related Data’ process) ahead of the Interim Information (II) Settlement Run in order to better reflect the state of the system. The Modification proposes to enable a Bid-Offer Acceptance’s (BOA’s) price(s) that goes into the imbalance price calculation to be different to the price(s) that goes into the calculation of BM cashflows.","P323 proposes to enable a BOA’s price(s) that go into the imbalance price calculation, to be different to the price(s) that go into the calculation of BM cash-flows. ","Authority: 15 October 2015","No","No","2015-11-05","Approve","Approve"]
["P322","Revised Implementation Arrangements for Mandatory Half Hourly Settlement for Profile Classes 5-8","RWE Npower","2015-04-28","Analyses on P272 carried out by Ofgem, ELEXON and Industry Parties show that the present\nimplementation arrangements create problems that will compromise plans for migration to HH\nSettlement by 1 April 2016. Timing of the implementation of the facilitating industry changes\n(DCP170 and P300) will require Suppliers to migrate affected sites in a short period of time. To\nminimise disruption to customers, Suppliers would prefer to carry out the migration at contract\nrenewal time. Indications are that many Suppliers may not be able to meet the approved\nImplementation Date of 1 April 2016.\nThe defect with the BSC is the implementation approach of BSC Modification P272 (which will\nrequire suppliers to have migrated all affected sites to HH Settlement by 1 April 2016). This\nwould lead to the problems identified by parties, including impacts on customers. A\nModification to the BSC to change the migration arrangements will remove this defect and\nprovide a more efficient and orderly transition whilst maintaining momentum for Industry\nParties.","P322 proposes new arrangements to migrate sites classes as Profile Class (PC) 5-8 with Advanced Meters installed to Half Hourly (HH) Settlement under the P272 obligations.","Authority: 24 June 2016","Yes","No","2016-08-03","Approve","Approve"]
["P320","Reporting on Profile Classes 5 – 8 Metering Systems after the implementation of P272","British Gas","2015-03-13","Approved Modification P272 requires changes to PARMS to capture and report any non-compliance after its implementation. The Proposer contends that the purpose of the non-compliance reporting will be better achieved by a regular Committee report to the PAB, rather than through PARMS. ","P320 seeks to remove the PARMS reporting requirements from P272 legal text. Instead, a Committee report will be created for P272 non-compliance reporting purpose.","Authority:  09 Sep 2015","No","No","2017-04-01","Approve","Approve"]
["P319","Removal of annual RMP review from PAF","BSC Panel","2015-03-12","The RMP was introduced into the PAF by P207. These detail relevant risks that have been\nidentified for each PAP. ELEXON believes that the information provided to PAPs is duplicated\nthrough other PAF mechanisms. For example, PAPs are informed about the deployment or\nchanges to the deployment of PATs via the processes set out in the relevant PAT Code\nSubsidiary Documents (CSDs). Some Parties have indicated that they agree with ELEXON and\nplace little value on RMPs.\n  ","P319 seeks to remove the requirement for ELEXON to provide an initial Risk Management Plan (RMP) at Qualification and annual review these. The information contained in these annual reviews is already communicated to Parties through other means, and so does not provide Parties with new information.",null,"No",null,"2015-11-05","Approve","Self-Governance"]
["P318","Change of Party ID/Company Number Through Enabling Assignment","Green Energy","2015-02-26","There is currently no route for a BSC Party to transfer its rights and obligations under the BSC to a new company (or Party), without going through the full Market Exit and Market Entry procedures. The P318 Proposer believes that this restricts BSC Parties from making administrative changes when there is a genuine business need. ","P318 seeks to enable a BSC Party to change its Party ID and/or its Company Number in order to reassign its rights and obligations under the BSC without going through the full Market Exit and Market Entry procedures. The intention of this Modification is for this to apply when such a change is of an administrative nature only.","Panel: 08 Oct 2015","No","Yes","2016-02-25","Approve","Self-Governance"]
["P317","Changes to the Unmetered Supplies obligations in the BSC","ENWL","2015-01-08","Clear obligations exist in BSCP520 for the BSC Panel to approve Equivalent Meters, for parties to agree Photoelectric Cell Unit (PECU) Array locations and for Licensed Distribution System Operators (LDSOs) to determine the mode of Half Hourly (HH) trading as either passive or dynamic. However, the BSC has not been updated following changes to the obligations of the LDSO and the Party Agent role of Meter Administrator (MA). ","P317 therefore seeks to remove outdated wording from BSC Section S that is no longer fit for purpose.",null,"No",null,"2015-06-25","Approve","Self-Governance"]
["P316","Introduction of a single marginal cash-out price","RWE Supply and Trading GmbH","2014-11-04","This Modification Proposal seeks to implement two key elements of the cash out reform identified by Ofgem in its Electricity Balancing Significant Code Review (EBSCR) with effect from 1 September 2015. These are:  a marginal cash out price; and  a single cash out price.","P316 proposes to introduce a single marginal imbalance (cash-out) price by reducing the PAR and RPAR values to 1MWh and replacing the dual priced arrangements with a single price. ",null,"No",null,"−","Reject Proposed\nApprove Alternative","Reject Proposed\nReject Alternative"]
["P315","Publication of Gross Supplier Market Share Data","Smartest Energy","2014-09-22","The Proposer believes that the Supplier Metered Volume data currently available to market participants does not provide sufficient transparency for interested parties (including prospective new entrants) to understand Suppliers’ market shares in the retail and embedded generation market.","P315 proposes to provide further transparency on Suppliers’ Meter Volume and MPAN counts. The volumes will exclude embedded generation and will be broken down by Market Participant ID (MPID), customer type, Active Export (AE)/Active Import (AI), and Estimated/Actual.","Approved by the Authority on 20 Oct 15 for implementation on 30 Jun 16.","No","No","2016-06-30","Reject Proposed\nApprove Alternative","Reject Proposed\nApprove Alternative"]
["P314","Reduction in PAR from 500MWh to 350MWh","First Utility","2014-09-04","The existing cash-out arrangements, which may have the effect of dampening cash-out price signals, may not provide sufficient signals to the market of the value of flexible capacity when margins are tight. As a result, cash-out price signals may have failed to create appropriate incentives for investment in flexible capacity (such as flexible generation, Demand Side Response (DSR) services and storage).\nA possible factor in this price dampening is the level of PAR. PAR is the maximum volume over which the weighted average of the most expensive energy actions (to the SO) are taken. This is currently set at 500MWh. Deriving a weighted average from a volume of 500MWh creates an imbalance price which does not reflect the marginal cost of balancing energy for a given Settlement Period. This is especially true at times of system stress when differences between the costs of accepted balancing actions are greatest. ","P314 proposes a reduction in the Price Average Reference value from 500MWh to 350MWh. This will improve the strength of imbalance price signals during winter 2014/15.",null,"Yes",null,"−","Reject Proposed\nReject Alternative","Reject Proposed\nReject Alternative"]
["P313","Required Housekeeping Changes to Implement P295 and EMR","BSC Panel","2014-08-14","The P295 solution is due to be implemented on 16 December 2014 and introduces a new\nsection 5 into BSC Section V. The EMR legal text changes were directed and implemented on\n1 August 2014 and also introduced new section 5 into BSC Section V.\nSince P295 was progressed before EMR was directed it was not possible to consider the P295\nsolution when drafting the required BSC changes. This means that when P295 is implemented\non 16 December 2014 the new section 5 introduced by EMR will be overwritten by the\nsection 5 introduced by P295.  ","P313 proposes minor changes to BSC Section V to correct a discrepancy between the P295 Legal text that will be implemented on 16 December 2014 and the EMR legal text changes directed and implemented on 1 August 2014.",null,"No",null,"2014-12-16","Approve","Fast Track Self-Governance"]
["P312","Required Housekeeping Changes to Implement P298 and EMR","BSC Panel","2014-08-14","Conflict between P298 and EMR legal text changes The P298 solution was implemented on 18 July 2014 and introduced a new bullet point (e) into BSC Section F 2.1.1. The EMR legal text changes for BSC Section F were directed and implemented on 1 August 2014 and introduced new bullet points (e) and (f) into the same BSC Section F2.1.1. Since P298 was progressed and implemented before EMR was directed by the Secretary of State, it was not possible to consider the P298 solution when drafting the required BSC changes for EMR. This in effect means that when EMR was implemented on 1 August 2014 the P298 bullet point (e) in BSC Section F 2.1.1 was overwritten by the EMR bullet point (e). EMR housekeeping changes A number of consequential changes were required to the BSC to support the implementation of the EMR arrangements. Whilst insuring that we implemented the required changes in good time, a number of minor inaccuracies were introduced that we are now seeking to rectify. All of the changes proposed under this Modification are immaterial housekeeping changes.","This Modification proposes minor changes to BSC Section F to correct a discrepancy between the P298 Legal text implemented on 18 July 2014 and the EMR legal text changes directed and implemented on 1 August 2014. \nThis Modification also proposes minor housekeeping changes to BSC Sections F, K, V and Annex X-1 to correct typographical errors introduced under the EMR implementation.",null,"No",null,"2014-09-08","Approve","Fast Track Self-Governance"]
["P311","Required Housekeeping Changes to Implement P291 and P295","BSC Panel","2014-08-14","P2911 ‘REMIT Inside Information Reporting Platform for GB Electricity’ has been approved for implementation on 31 December 2014. P291 requires changes to the Balancing Mechanism Reporting Service (BMRS) and BSC Sections Q and V. These changes are required to enable the reporting of necessary information to meet the requirements of The Regulation on Wholesale Energy Markets Integrity and Transparency (REMIT) regulation. Subsequent to the P291 decision, P2952 ‘Submission and publication of Transparency regulation data via the BMRS’ has been approved for implementation on 16 December 2014. P295 requires changes to the BMRS and BSC Sections Q and V to enable the reporting and forwarding of required Transparency regulation data.","P311 proposes minor changes to BSC Sections Q and V to ensure the implementation of the P291 legal text on 31 December 2014 will not impact the approved P295 solution, which will be implemented on 16 December 2014.",null,"No",null,"2014-12-31","Approve","Fast Track Self-Governance"]
["P310","Revised Credit Cover for Exporting Supplier BM Units","NEAS Energy A/S","2014-07-31","When calculating the CEI for embedded generation, BMUs that are registered in SVA and which have only generation sites and no consumption sites, the demand volume of such BMUs is estimated as zero in the first five working days (the production volumes are not considered relevant and are not taken into consideration). The assignment of zero demand volume means the generation sites are not affecting the CEI calculations, which results in the Party having to lodge Credit Cover or claim Material Doubt to prevent Credit Default. ELEXON operates an alternative CALF calculation, which gives the opportunity to reverse the sign of the BMCAIC and thereby reflect the generation within the BM Unit. However this option requires a non-zero DC value in order to produce a useable estimate. This solution is not applicable for Suppliers with embedded generation and no consumption, as they have to comply with Balancing and Settlement Code (BSC) Section K ‘Classification and Registration of Metering Systems and BM Units’ 3.4 and submit a zero DC value when having no consumption.","P310 proposes to use the Balancing Mechanism Credit Assessment Export Capability (BMCAEC) value instead of the Balancing Mechanism Credit Assessment Import Capability (BMACAIC) value with regards to the Credit Assessment Energy Indebtedness (CEI) calculations when a SVA BM Unit contains embedded generation and no consumption. ",null,"No",null,"2015-06-25","Approve","Self-Governance"]
["P309","Facility to enable BSC Parties to select either replacement contract notifications or additional contract notifications","RWE Supply and Trading GmbH","2014-06-26","An inadvertent error in contract submissions after a software upgrade by a BSC party has highlighted that the current code and associated systems enable a BSC party to unintentionally replace overwrite energy contract notifications with additional energy contract notifications (or vice versa). This creates a risk for Parties with the energy contract submission process that could affect competition in the GB electricity market. The proposed modification will address this issue by enabling parties to prevent an unintentional switch between replacement contract notifications (overwrite) and additional contract notifications (additive).","P309 proposes to give BSC Parties the ability to specify that either replacement contract notifications or additional contract notifications are associated with an Energy Contract Volume Notification Agent Authorisation in order to mitigate the risk that replacement notifications might be submitted instead of additional notifications, or vice versa.",null,"No",null,"2015-11-05","Reject Proposed\nApprove Alternative","Reject Proposed\nApprove Alternative"]
["P308","Alternative security product for securing credit under the BSC","Eggborough Power","2014-06-04","The Proposer considers that the level of credit held under the BSC is in some cases exceptionally high, above and beyond the actual risk that Parties are likely to incur. They believe it would be more efficient to provide a single central security product that could cover all Parties, which would remove a lot of the excess credit that results from the current BSC arrangements.","P308 proposes to introduce a centrally provided alternative security product as an alternative method for securing credit under the BSC, which Parties could use in place of the existing requirements to provide Credit Cover individually.","The Proposer withdrew Modification P308 on Thursday 2 February 2017. The adoption window closed on Friday 10 February from which point the Modification was closed.","No","No","N/A","N/A","Withdrawn"]
["P307","Amendments to Credit Default arrangements","E.ON","2014-06-04","The level of credit held across the energy industry is in some cases exceptionally high, above and beyond the actual risk that market participants are likely to incur. In particular, the BSC requires BSC Parties to lodge credit cover in excess of their maximum energy indebtedness, due to Parties needing to keep their Credit Cover Percentage below the 80% threshold to avoid a level 1 default notice. Following such a notice, the Party has at least a 24 hour Query Period before any consequences; however the consequences can be significant. Where the Query Period commences after 17:00 on a Friday and any time through to Sunday morning, there can be a scenario where there are very few or no Working Hours in which the Party can lodge further Credit Cover with BSCCo. The Party would therefore have no option other than to buy energy during the Query Period and notify energy contracts to reduce their Credit Cover Percentage. This action can incur significant costs to the Party.","P307 proposes to amend the timings, triggers and thresholds in relation to Credit Default, including extending the duration of the Query Period and adjusting the thresholds for entering Credit Default and the processes relating to the Cure Periods.",null,"No",null,"2015-06-25","Approve","Approve"]
["P306","Expanding the definition of a ‘Letter of Credit’ to include regulated insurance companies","E.ON","2014-06-04","During 2012 and 2013, Moody’s Investors Services Inc. (also referred to as Moody’s) and Standard & Poor’s downgraded several licensed banks. This resulted in a reduction in the number of financial institutions with an adequate credit rating to provide security on behalf of Trading Parties under the BSC. A smaller pool of prospective security providers, along with the potential for further downgrading, is unlikely to incentivise banks and similar entities to maintain or reduce charges for providing security. We consider that the pool of prospective providers should be expanded to include regulated insurance companies that can provide “like for like” products to that of a bank, which would provide more options to individual Parties, facilitating competition.","P306 proposes to allow individual Parties to obtain a Letter of Credit from a regulated insurance company that is capable of providing security of a similar level and form as that provided by a bank.",null,"No",null,"2014-11-14","Approve","Self-Governance"]
["P305","Electricity Balancing Significant Code Review Developments","National Grid","2014-05-30","A number of inefficiencies in the current cash-out pricing methodology have been identified in the EBSCR. The EBSCR Final Policy Decision sets out a package of reforms to the existing cash-out price arrangements designed to improve the efficiency of imbalance price signals to the market.","P305 has been raised to progress the outcomes of the Electricity Balancing Significant Code Review (EBSCR), and proposes to implement the EBSCR conclusions ahead of Winter 2015/16, which include:\nReductions in the PAR value (50MWh from Winter 2015/16, then 1MWh from Winter 2018/19);\nA single imbalance price, calculated using the main price calculation;\nThe introduction of Reserve Scarcity Pricing (RSP); and\nThe introduction of Value of Lost Load (VoLL) pricing for Demand Control actions.",null,"No",null,"2015-11-05","Reject Proposed\nReject Alternative","Approve Proposed\nReject Alternative"]
["P304","Reduction in PAR from 500MWh to 250MWh","National Grid","2014-05-30","The EBSCR Final Policy Decision sets out a package of reforms to the existing cash-out arrangements designed to improve the efficiency of imbalance price signals to the market.","P304 has been raised to progress the outcomes of the Electricity Balancing Significant Code Review (EBSCR), and proposes to reduce the Price Average Reference (PAR) value from 500MWh to 250MWh ahead of Winter 2014/15.",null,"No",null,"2014-11-28","Reject ","Reject "]
["P303","Amendments to the Provisions for BSCCo Directors ","Utilita","2014-05-21","The defect that this proposal seeks to address is that the current arrangements for directors restrict the pool of suitable candidates.  ","P303 seeks to make amendments to the Code provisions for BSCCo Board Directors, with the aim of increasing the pool of candidates that may  apply to fill a position on the BSCCo Board. To achieve this P303 proposes to remove the restriction that industry directors cannot receive remuneration and benefits and remove the restriction that non-industry Board members cannot have been an employee, director or representative of a BSC Party or Panel Member in the past 5 years.",null,"No",null,"2014-11-28","Reject Proposed              Approve Alternative ","Reject Proposed              Approve Alternative "]
["P302","Improve the Change of Supplier Meter read and Settlement process for smart Meters","EDF Energy","2014-05-16","The existing NHH Change of Supplier  process is complicated, relying on multiple information flows being sent between new and old Suppliers and Supplier Agents. This makes it prone to error and delays occur which can result in inaccurate data entering Settlement. The costs of resolving these delays and process errors are borne by Suppliers, Supplier Agents and ultimately the consumer.","P302 proposes changes to the Code and BSCPs to amend the CoS process to make use of the enhanced functionality that smart Meters will provide and improve the passing of timely and accurate consumption data into Settlement.","Authority:18 Jun 2015","No","No","2016-06-30","Approve","Approve"]
["P301","Replacement of National Consumer Council by Citizens Advice and Citizens Advice Scotland","National Grid","2014-04-24","On 1 April 2014 the National Consumer Council (NCC) was abolished. On 22 April 2014, the Transmission Licence was amended to reflect that the NCC has been abolished and that its functions have been transferred to Citizens Advice and Citizens Advice Scotland. P301 was raised by National Grid to amend the BSC to reflect the changes to the Transmission Licence. P301 was progressed as a Fast Rack Self-Governance Modification. The Panel considered the P301 IWA on 8 May 2014, when they agreed that the Mod should progress under the Fast Track Self-Governance provisions. P301 was then implemented on 3 June 2014 (1 Working Day) following the end of the Fast Track Self-Governance objection window.","P301 proposes changes to ensure the BSC reflects conditions within Standard Licence Conditions (SLC) C3 of the Transmission Licence by replacing instances of National Consumer Council with Citizens Advice1 and Citizens Advice Scotland.",null,"No",null,"2014-06-03","Approve","Fast Track Self-Governance Modification"]
["P300","Introduction of new Measurement Classes to support Half Hourly DCUSA Tariff Changes (DCP179)","ENWL","2014-03-05","DCP179 is being developed that, if approved, will impact the Balancing & Settlement Code (BSC). DCP179 proposes to amend the use of system charging methodology and introduce tariffs that will aim to reduce or remove any perceived discrepancy between the charges for Non Half-Hour (NHH) metered connections and HH metered connections. It also introduces HH tariffs for all CT metered customers and aggregated HH tariffs for WC metered customers. The BSC contains a number of provisions for providing Distribution System Operators with the metered data they need for charging purposes. The issue is that they don’t provide any mechanism for distinguishing between HH-settled customers whose network charges should be calculated on a site-specific basis, and those whose network charges should be calculated on an aggregated basis. There are also benefits to Settlement for moving to HH metered, as this is considered more accurate.","P300 seeks to introduce new Measurement Classes for aggregated Half Hourly-settled customers (for current transformer and whole current metered domestic; and whole current non-domestic markets). P300 builds on Rejected Modification P280 and aligns with DCUSA DCP 179, which seeks to implement Half Hourly DCUSA tariff changes. P300 would enable Licenced Distribution Systems Operators to charge Suppliers on an aggregated basis as well as on a site specific basis.",null,"No",null,"2015-11-05","Approve","Approve"]
["P299","Allow National Grid access to Metering System Metered Consumption data to support the DSBR service","National Grid","2014-01-31","National Grid is seeking to receive disaggregated MPAN-level data from Suppliers, HHDAs and HHDCs for use in Demand Side Balancing Reserve (DSBR).","P299 proposes changes to extend BSC Section L5.2.4 to allow National Grid to gain access to Suppliers’ Metering System Metered Consumption (SMMCZaKj) data provided by Half Hourly Data Collectors (HHDCs) to Half Hourly Data Aggregators (HHDAs). This data is required to support the validation of submitted tender1 data and to process the settlement of payments for the delivery of the new Demand Side Balancing Reserve (DSBR) service.",null,"No",null,"2014-06-13","Approve","Approve"]
["P298","Consequential amendments to the BSC Modification process following the implementation of Third package and other miscellaneous changes","National Grid","2013-11-25","The Third Package was introduced in Great Britain on 10 November 2011 by making amendments to relevant domestic legislation. The changes were given effect by the Electricity and Gas (Internal Markets) Regulations 2011. As a result, the Authority made a number of changes to the gas and electricity licences. In November 2012, Ofgem issued a consultation on further proposed licence changes following the implementation of the Third Package and other miscellaneous changes. One part of this consultation was to clarify the circumstances under which the Authority could raise Modifications. The Authority issued a second consultation on 29 July 2013 on modifications to the licences that it considered may be required. On 22 October 2013 it notified industry of its decision to modify electricity licence conditions following the implementation of the Third Package and other housekeeping changes, which will take effect from 17 December 2013.","P298 will introduce to the BSC the authority ability (as set out in the Standard Licence Conditions) to raise Modifications (or direct the licensee to) in relation to European Legislation. - CGR2 - Third Package Licence Changes - Authority raised Modifications relating to European legislation",null,"No",null,"2014-07-18","Approve","Approve"]
["P296","Introduction of a ‘Fast Track’ Modification Process following the outcomes of the Code Governance Review (Phase 2)","BSC Panel","2013-07-11","The outcomes of Ofgem’s Code Governance Review (Phase 2), is seeking to extend the current Self-Governance Modification arrangements, by introducing a ‘fast track’ Modification process. The purpose of the ‘fast track’ Modification process is to enable the quick progression and implementation of minor housekeeping changes to the BSC without the need to go through the full Modification process. This would enable minor housekeeping changes to be made in shorter timescales. The ‘fast track’; process was introduced via changes to Standard Condition C3 of the Electricity Transmission Licence which will take effect on 5 August 2013 following publication of the final changes on 7 June 2013. As required by SLC C3, the new ‘Fast Track’ Self-Governance process needs to be incorporated into the BSC by 31 December 2013.","This Modification will deliver the required BSC arising from the Code Governance Review (Phase 2). This includes the addition of the 'Fast Track' Self Governance Review process, which will be used for progressing 'housekeeping changes' that do not have a material impact.",null,"No",null,"2013-11-06","Approve","Approve"]
["P295","Submission and publication of Transparency regulation data via the BMRS","National Grid","2013-07-01","The EU Transparency regulation requires primary data owners to submit information to their Transmission System Operator, or a third party acting as a data provider, for publication on a central European reporting platform. Arrangements to deliver the Transparency regulation must be implemented no later than 4 January 2015. ","P295 proposes that ELEXON is made the GB data provider for all data that the Transmission Company is required to submit to the central platform, with some or all of this data also being published on the BMRS.",null,"No",null,"2014-12-16","Approve","Approve"]
["P294","Addition of Offshore Transmission System and OTSUA to the definition of the Total System","E.ON","2013-06-03","It is not explicit within the Balancing and Settlement Code (BSC) whether an Offshore Transmission System, and in turn OTSUA, forms part of the Transmission System. This is because while the BSC takes its definition for the Offshore Transmission System, including OTSUA, from the Grid Code, its definition of Transmission System, while not expressly including offshore, refers to that in the Transmission Company’s Transmission Licence. As such an Offshore Transmission System forms part of the Transmission System once the OTSDUW has been transferred to an OFTO and is operated by the Transmission Company as the Great Britain System Operator (GBSO).","P294 added Offshore Transmission System User Assets (OTSUA) to the definition of Total System, resolving any potential confusion between the BSC and Grid Code. It would also remove the requirement for a User to install potentially costly CoP1 compliant metering at the Onshore the Boundary Point between the Transmission System and OTSUA, from the point ta site is commissioned until the assets are transfer to the OFTO at which point the metering becomes redundant. It would also ensure consistency regarding the treatment of transmission losses along the OTSUA, as they would be socialised in the same manner as transmission losses when the Transmission Company extends the Transmission System or an OFTO extends an Offshore Transmission System.",null,"No",null,"2013-12-30","Approve","Approve"]
["P293","Changes to  BSC Section H 'Audit' and BSC Service Description for BSC Audit to reflect current Practice","BSC Panel","2013-05-09","The current BSC Audit contract comes to an end on 30 September 2013, with the new contract for the BSC Audit (and Qualification Service Provider) commencing on 01 October 2013. ELEXON is currently undertaking a competitive tender process to appoint a combined BSC Auditor and Qualification Service Provider. As part of this, ELEXON has reviewed the current BSC Audit requirements in BSC Section H5 ‘Audit’ and the ‘BSC Service Description for BSC Audit’.\nFollowing the review, a number of minor changes have been identified that will ensure that the BSC and Service Description reflects current processes and service. The minor changes address any inconsistencies in terminology, add clarity and ensure that the BSC and Service Description relate to the proposed changes to the Audit Contract.","P293 seeks to align BSC Section H 'Audit' and the BSC Service Description for BSC Audit with current practice in time for the commencement of the new BSC Audit and Qualification Service Provider contract o 01 October 2013.",null,"No",null,"2013-10-01","Approve","Self-Governance"]
["P292","Amending Supplier & Meter Operator Agent responsibilities for smart Meter Technical Details","E.ON","2013-03-04","The DECC SMIP has defined requirements in relation to smart metering1 arrangements, which impact existing electricity and gas codes.\nThe SMIP has proposed an operating model for smart MTDs. Under the proposed operating model, Suppliers will take responsibility for configuring the smart Meters and sending the MTD flows to all industry users in place of their appointed MOA. The MOA, however, will remain responsible for installing the smart Meter and then providing physical device details to the Supplier.\nA joint BSC-MRA working group has developed the detailed level changes, partly progressed through CP1388, to capture the low-level requirements.\nCP1388 proposes amendments to BSC Procedures (BSCPs) 504, 514, 515; and the SVA Data Catalogue Volumes 1 and 2. An MRA change to the Data Transfer Catalogue (DTC) is also required to introduce the three new data flows (“Smart Device Details”, “Smart Meter Configuration Details” and “Smart Equipment Work Management Request”) along with any associated new data items.","P292 seeks to enable the changes to Supplier and Non-Half Hourly Meter Operator Agent responsibilities for smart Meter Technical Details proposed by the Department of Energy and Climate Change’s Smart Metering Implementation Programme.",null,"No",null,"2014-06-26","Approve","Approve"]
["P291","REMIT Inside Information Reporting Platform for GB Electricity","SSE","2013-01-30","The Regulation on Wholesale Energy Markets Integrity and Transparency (REMIT) is an EU regulation that came into force in December 2011 and is aimed at preventing market abuse in the wholesale energy markets."," P291 proposes to use the Balancing Mechanism Reporting System (BMRS) as a platform to publish the necessary information to meet the requirements of REMIT inside information reporting for the GB electricity sector.",null,"No",null,"2014-12-31","Approve","Approve"]
["P290","Enabling ELEXON to participate in roles in support of the Smart Energy Code (SEC) Panel ","Smartest Energy","2013-01-03","The current BSC drafting means effectively that ELEXON Ltd may not partake in the tender process for any roles that support the SEC Panel. We believe this prevents ELEXON from offering the service and leveraging its skills and expertise for the wider benefit of the industry. We are not explicitly advocating ELEXON as the SEC Panel support body, rather suggesting that ELEXON’s exclusion from the award process would be detrimental to SEC Parties (which include all domestic suppliers and Distributors) by precluding the evaluation of a credible delivery model and precludes the possible saving for BSC Parties through defrayed costs.","P290 would amend the BSC to enable ELEXON to undertake roles that support the Smart Energy Code (SEC) Panel, in particular for the SEC Administrator and SEC Secretariat roles.","—","—","—","—","—","—"]
["P289","Enabling ELEXON to participate in tendering for the DCC Licensee role via a subsidiary","BSC Panel","2012-12-13","The current BSC drafting means that ELEXON Ltd may not partake in the tender process for the DCC Licensee role. We believe this prevents ELEXON from leveraging its skills and expertise for the wider benefit of the industry, which could be detrimental in the delivery of the most efficient and economic Smart Meter solutions.\nThe key constraints currently imposed on ELEXON Ltd by the BSC include provisions preventing:\n ELEXON or its subsidiaries from providing DCC services outside its core BSC activities; and\n ELEXON or its subsidiaries holding interests in appropriate legal entities to deliver DCC services outside the BSC.","P289 would amend the BSC to allow ELEXON to establish a subsidiary which can participate in the Data Communications Company (DCC) bid process and, if successful, act as DCC. If approved, P289 will change the scope of ELEXON’s permitted activities and have implications for the funding of BSC services (in that costs may be defrayed).  It will therefore be of interest to all BSC Parties.",null,"_",null,"−","Reject ","Reject "]
["P288","Aligning Supplier Charge SP08a calculation with current practice","BSC Panel","2012-11-08","There was an inconsistency between BSC Section S Annex S1  and the Performance Assurance Reporting and Monitoring System (PARMS) regarding how under performance for PARMS Serial SP08a is calculated . The Code required under performance for SP08a to be calculated to 2 d.p. whereas PARMS has always calculated under performance to 1 d.p. The PAB has recommended that the Code be amended to reflect current practice, to avoid the resultant System cost of changing PARMS to calculate SP08a to 2d.p","Modification P288 proposes to amend BSC Section S, Annex S-1 to reflect that underperformance calculated for SP08a uses 1 d.p. instead of 2d.p.",null,"_",null,"2013-01-08","Approve","Self-Governance"]
["P287","Allow the BSC Panel to conduct Modification Business via teleconference","ELEXON","2012-06-14","Under the current arrangements, the BSC Panel cannot conduct Modification Business via teleconference. ","P287 proposes to allow the BSC Panel to make decisions on Modification Business via teleconference, as long as at least one Panel is present at the venue specified for that Panel meeting",null,"_",null,"−","Reject ","Self-Governance"]
["P286","Revised treatment of RCRC for generation BM Units","National Grid","2012-05-28","CUSC Modification Proposal (CMP) 201 proposes to remove Balancing Services Use of System (BSUoS) charges/payments from generation BM Units. The Proposer believes that the BSC’s Residual Cash flow Reallocation Cash flow (RCRC) can be considered as related to the imbalance cost element recovered within BSUoS, and currently all Parties are exposed to both. ","P286 therefore proposes that generation BM Units should no longer be subject to RCRC charges/payments if CMP201 is approved.",null,"No",null,"−","Approve","Reject "]
["P285","Revised treatment of RCRC for Interconnector BM Units","National Grid","2012-05-28","Approved CUSC Modification Proposal (CMP) 202 has removed Balancing Services Use of System (BSUoS) charges/payments from Interconnector BM Units. The Proposer believes that the BSC’s Residual Cashflow Reallocation Cashflow (RCRC) can be considered as related to the imbalance cost element recovered within BSUoS, and currently all Parties are exposed to both. ","P285 therefore proposes that Interconnector BM Units should no longer be subject to RCRC charges/payments.",null,"No",null,"2013-06-27","Approve","Approve"]
["P284","Expansion of ELEXON's role via a 'contract model'","National Grid","2012-04-17","The current BSC provisions do not allow BSCCo (ELEXON) to perform anything other than the activities specified in the BSC. As part of a recent Ofgem consultation on ELEXON diversification, Ofgem concluded that if ELEXON were to undertake a wider role, a ‘contract model’ (whereby ‘New ELEXON’ would be contracted to BSCCo) would best protect BSC Parties’ interests.","P284 seeks to place provisions in the BSC to enable, but not require, the BSCCo Board to establish a BSC services contract with ‘New ELEXON’ subject to specified steps having been undertaken.",null,"_",null,"−","Reject Pro\nReject Alt","Reject Pro\nApprove Alt"]
["P283","Reinforcing the Commissioning of Metering Equipment Processes","BSC Panel","2012-04-13","Current practices surrounding the provision and responsibility for Metering Equipment in respect of measurement transformers (CTs and VTs) makes the BSC obligations difficult to meet. The extent of the issues arising from incomplete commissioning of measurement transformers has been highlighted by the TAA in its annual report to the BSC Panel in 2011 (Attachment A). The TAA report suggests that deficiencies with commissioning and associated records carry significant risk to the integrity of Settlements.","P283 intends to place commissioning obligations on the Transmission Company and Licenced Distribution System Operators because the Registrant and Meter Operator Agent are often not well placed to complete Metering Equipment commissioning",null,"No",null,"2014-11-06","Approve","Approve"]
["P282","Allow MVRNs from Production to Consumption or Vice Versa","Statkraft","2012-03-26","The MVRN mechanism provides some flexibility to the trading arrangements. For example, generators could choose to avoid day-to-day participation in the central trading arrangements by issuing an MVRN with another Trading Party with an active Production account, who then takes on the responsibility for the associated energy volumes. The same facility is available to a Supplier, allowing them to transfer energy they supplied to the Consumption account of another Trading Party. These methods are regularly used by Parties with multiple Party IDs to consolidate all their generation or consumption volumes into a single Account, which makes it easier to balance their overall position. The current restriction prevents a Production BM Unit from transferring energy to the Consumption Energy Account of its Lead Party or of a Subsidiary Party, and vice versa. This limitation, in the Proposer’s view, places an undue and inappropriate restriction on non-Big Six Parties and only increases the costs of the trading arrangements and complexity of compliance with the rules. It also creates significant inefficiencies in the trading arrangements as it prevents them netting their own position against that of a counter-party active on the other side of the market.","P282 proposes to allow energy reallocated via a Metered Volume Reallocation Notification (MVRN) to be reallocated to either a Production or Consumption Energy Account regardless of the BM Unit’s P/C Status. This would remove the current restriction that energy can only be reallocated from a Production BM Unit to a Production Energy Account, or a Consumption BM Unit to a Consumption Energy Account.",null,"_",null,"−","Reject","Reject "]
["P281","BSCCo Board Structure","E.ON","2011-12-03","The current BSCCo Board arrangements can allow the non industry Non- Executive Directors and the Chairman and to carry Board decisions against the will of industry Non-Executive Directors members. This means ELEXON resources can be used, budgets set and expenditure incurred even though such decisions may not be widely supported by BSC Parties and other affected stakeholders. Should ELEXON be permitted to diversify its activities, it will become even more important to establish a BSCCo Board that is able to safeguard the interests of BSC Parties that fund the BSC arrangements. The reform of the BSCCo Board is thus an essential component of the changes required to enable ELEXON to diversify its activities. It will help ensure the appropriate separation of the BSCCo Board from the management of ELEXON who currently perform the administration of the Balancing & Settlement Code.","P281 seeks to amend the make up of the Board by adding 2 non exec industry experts and amend the constituency basis.",null,"_",null,"2012-10-01","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P280","New Measurement Classes","ENWL","2011-11-25","The BSC contains a number of provisions for providing Distributors with the metered data they need for charging purposes: • general provisions in L5.2.4; • SVAA requirements in S2.7.7; and • HHDC requirements in Annex S-2.3.3.2(g). The defect in these arrangements is that they don’t provide any mechanism for distinguishing between HH-settled customers whose network charges should be calculated on a site-specific basis, and those whose network charges should be calculated on an aggregated basis.","P280 seeks to introduce new measurement classes for HH customers and an obligation on SVAA to provide Distributors data on these HH sites. This will allow distributors to work out which HH customers should be calculated on a site specific basis and which should be aggregated.",null,"_",null,"−","Approve","Reject"]
["P279","Export form GSP group","ELEXON","2011-10-13","Correcting a self evident error in the Code relating to the CDCA to SVAA interface.  ","P279 would correct the Code so that their application facilitates the delivery of accurate Settlement where there is Export by a GSP Group.",null,"_",null,"2012-01-10","Approve","Self-Governance"]
["P278","Treatment of Transmission Losses for Interconnector Users","National Grid","2011-09-30","The European Inter-TSO Compensation (ITC) scheme provides compensation  to TSO’s for cross-border flows on Interconnectors. Included are transmission losses for BMUs associated with Interconnectors. The BSC needs to be updated to ensure that BMUs associated with Interconnectors get zero losses applied.","P278 proposes to always apply a fixed Transmission Loss Multiplier of 1 to Interconnector BM Units, so that the BSC does not adjust their Metered Volumes for GB transmission losses.",null,"_",null,"2012-11-29","Approve","Approve"]
["P277","Allow Interconnector BM Units to choose their P/C Status","Vattenfall","2011-09-30","In accordance with BSC Sections K5.5 and K3.5, the Central Registration Agent (CRA) currently assigns Interconnector BM Units in fixed pairs for each Interconnector, as follows: A Production BM Unit for energy entering Britain over the Interconnector; and A Consumption BM Unit for energy leaving Britain. The P/C Status of these BM Unit is fixed as Production or Consumption accordingly, and cannot be changed. Energy from the Production BM Unit is therefore assigned to the Lead Party’s Production Energy Account and energy from the Consumption BM Unit is assigned to their Consumption Energy Account. If a Party were to, for example, buy energy in France and transport it to the Netherlands via Britain, the current set-up could potentially leave them open to being charged the System Buy Price/System Sell Price spread over the whole amount. This is because the energy entering Britain would be allocated to the Party’s Production Account while the energy leaving Britain would be assigned to their Consumption Account (even though these two amounts are equal and opposite, and would net to zero if they were allowed to be in the same Energy Account). Without additional contracts, this would leave both Accounts in imbalance. This can be resolved by setting up an Energy Contract Volume Notification (ECVN) between the two Accounts, but this is an additional administrative burden and potentially prone to human error by the Party.","P277 proposes that Interconnector should be allocated a single Interconnector BMU for each Interconnector rather than the existing pair of Production and Consumption BMUs. The Lead Party for this single Interconnector BM Unit would be able to elect whether the BM Unit’s P/C Status is Production or Consumption.",null,"_",null,"−","Reject","Reject"]
["P276","Introduce an additional trigger/threshold for suspending the market in the event of a Partial Shutdown","National Grid","2011-09-30","BSC market operations are suspended if National Grid notifies that a Partial Shutdown has occurred.  ","P276 proposes to introduce an additional trigger so that  BSC  market operations are not suspended  following any small, localised shutdowns for which market suspension would be disproportionate.",null,"No",null,"2014-03-31","Approve","Approve"]
["P275","GVC - Extending Performance Assurance","ENWL","2011-09-30","Extending the Performance Assurance Framework (PAF) to provide assurance to DNOs in their use of Settlement data","P275 seeks to amend the BSC to clarify that the scope of  Performance Assurance under the BSC is not limited to Trading Parties and that any risk of error or inaccuracy in Settlement data may be considered, not just issues that directly impact the determination and settlement of Trading Charges.",null,"_",null,"2012-05-08","Approve","Self-Governance"]
["P274","Cessation of Compensatory Adjustments","ENWL","2011-09-30","Energy volumes that have undergone a Final Reconciliation run may not be changed. However, the BSC permits Suppliers to use Gross Volume Correction (GVC) to compensate for errors relating to periods that have been subject to RF by adjusting energy volumes in periods not yet subject to RF. This ensures that the total gross volume of energy is correct, albeit allocated to the wrong Settlement Period.","P274 seeks to specify that Settlement errors that have been subject to final reconciliation cannot be compensated for in subsequent Settlement calculations.",null,"No",null,"−","Reject Pro\nRejectAlt","Reject Pro\nRejectAlt"]
["P273","Make the SVA Funding Share Calculation robust to changes in Scaling Weights","BSC Panel","2011-08-11","A defect in the BSC has been identified whereby a change in the GSP Group Correction Scaling Factors may have an unintended effect on the calculation of the SVA (Consumption) Funding Share.","P273 proposes to change Annex D-1, Annex S-2, and Tables X-5, X-6 and X-7 in Annex X-2 of the BSC, to ensure that the SVA Funding Shares calculation is robust to changes in GSP Group Correction Scaling Weights (WTN).",null,"_",null,"2012-02-23","Approve ","Self-Governance"]
["P272","Mandatory Half Hourly Settlement for Profile Classes 5-8 ","Smartest Energy","2011-05-20","Since 6 April 2014, all Meters within Profile Classes (PCs) 5-8 must be an ‘advanced’ Meter capable of being read remotely and recording Half Hourly (HH) consumption. However, there is no mandate to settle these HH capable Meters on a HH basis.","P272 proposes to make HH Settlement mandatory for all Metering Systems within PCs 5-8 (where capable metering has been installed), as the Proposer believes that the use of Non Half Hourly (NHH) data is not as accurate and masks individual customer behaviour.","Originally approved by the Authority on 29 Oct 14 for implementation on 01 Apr 16. The Authority approved a 12-month implementation extension on 24 Jun 15, and so P272 will now be implemented on 01 Apr 17.","No","No","2017-04-01","Reject Proposed\nReject Alternative","Reject Proposed\nApprove Alternative"]
["P271","NETSO consultations","SSE","2011-02-28","As a result of the European Third Energy Package the European Network of Transmission System Operators – Electricity (ENTSO-e) have been tasked with creating European Network Codes.  National Grid, as GB National Electricity Transmission System Operator (NETSO), participate in ENTSO-e meetings and are actively involved in the European Network Codes drafting process.","P271 proposes that National grid are obligated to report any potential or likely BSC impacts as a result of developments of the European Network Codes  to the BSC Panel. It is suggested that the Panel establish a European Issues Group for this purpose.",null,"_",null,"−","Reject Pro\nApprove Alt","Reject "]
["P270","LLFs for Offshore GSPs","ENWL","2011-02-28","The OFTO arrangements  introduced a new type of Grid Supply Point into the BSC; Offshore Transmission Connection Points. Currently, the BSC does not permit the application of Line Loss Factors to a Grid Supply Point.  ","P270 proposes that  Line Loss Factors should be applied to Grid Supply Points where appropriate.",null,"_",null,"−","Reject ","Reject "]
["P269","BMU Account flipping","Smartest Energy","2011-02-04","If the total Relevant Capacities of BM Units in a Base Trading Unit are positive, all of the BM Units in a Base Trading Unit (BTU) would flip from Consumption to Production status. This would have a major impact on Parties who would need to amend their systems to cope with the change in status or face the risk of imbalance charges as a result. The Issue 38 Group believed that the risk of this issue arising is especially high in areas where there are high levels of embedded generation. Currently, ELEXON publish seasonal GCs and DCs on the “Portal”. However, within season corrections are not publicised. It is possible that a redeclaration of values which causes a “flipping” event could occur without Parties knowing about it. Additionally, forcing supplier-only Parties to trade out of two accounts will lead to an inefficiency as imbalances would occur in both accounts. These imbalances are minimised if traded in one account.","P269 seeks to prevent the P/C Status of Base Trading Units ‘flipping’ from Consumption to Production if the level of embedded generation increases.  This will affect those BM Units in Base Trading Units whose P/C Status is linked to that of the Trading Unit. ",null,"_",null,"2012-02-23","Approve","Self-Governance"]
["P268","P/C Status export BMU","Statkraft","2011-01-30","It is currently optional for the Lead Party of an Exempt Export BM Unit to elect a fixed Production/Consumption (P/C) Status.  If it does not, its P/C Status is by default determined dynamically and can change at any time.  This could lead to unintended Imbalance Charges if the Lead Party is unaware.\nFrom 23 February 2012, the Lead Parties of all existing and any future Exempt Export BM Units must explicitly elect to have a fixed P/C Status of either Production or Consumption.  This P/C Status will only change if the Lead Party makes a new election (to change it from Production to Consumption, or vice versa) or if the BM Unit’s Exempt Export status is terminated.","P268 proposes to ensure that the Production/Consumption  status of an Exempt Export BM Unit is only changed with the Lead Party’s explicit agreement.  It also seeks to remove an inconsistency between the BSC and the Central Registration Agent (CRA) Service Description.  The Proposer is requesting a retrospective implementation.",null,"_",null,"2012-02-23","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P267","Consideration of wider industry developments and duration of proposed changes when agreeing progression timetables","RWE Npower","2011-01-28","The development of the Smart Energy Code over the next few years will require thought into the interoperability of arrangements and governance to ensure compatibility between the existing arrangements and a ‘Smart world’. To ensure that this period of transition is managed in a stable manner. ","P267 seeks to place a clear requirement on the BSC Panel to consider wider industry developments (e.g. the development of the Smart Metering Arrangements /Smart Energy Code), and to take account of the likely longevity of a proposed change in the BSC when agreeing a timetable for progression of a change. This new requirement should also apply to the terms of reference of the Panel Committees and Modification Groups.",null,"__"]
["P266","Reactive Power","SSE","2010-10-05","The current BSC provisions do not allow Reactive Power flows associated with Active Export to be assigned to the Export Metering System1 . The BSC therefore forces Parties to assign Reactive Power flows caused by generating plant to a different Metering System to the Active Power generated, leading to spurious DUoS charges for the affected customers.","P266 seeks to resolve anomalies in the allocation of Reactive Power flows on sites where Import demand and Export from Exemptable Generating Plant share a common connection to the Distribution System",null,"_",null,"2012-02-23","Approve","Approve"]
["P265","Improving the Accuracy of the Credit Calculation","RWE Npower","2010-08-31","Parties have to lodge credit with ELEXON in order to cover their Trading Charges for the 29 day period between the Settlement Day and the Initial Settlement (SF) Run. To calculate the required credit cover, an Interim Information (II) run is carried out 5 Working Days after the Settlement Day. Currently the II run uses actual Metered Volumes from the Central Volume Allocation (CVA) market, but only estimated data for the Supplier Volume Allocation (SVA) market. This method of estimating Metered Volumes at the II Settlement Run causes the following issues: There can be inaccuracies in the forecasting of SVA data (particularly embedded intermittent generation); The estimation technique does not correctly forecast usage around a Bank Holiday; The estimation technique uses a percentage of Grid Supply Point Group Takes (GSPGTs) in its calculations. An increase in embedded generation in some Grid Supply Points (GSPs) has resulted in GSPGTs approaching zero, making the credit calculations significantly inaccurate.","P265 proposes amending the Initial Information (II) Settlement Run process to more accurately estimate credit. It will do this by:\n•   Amending the way SVA data is estimated to account for Bank Holidays; and\n•    Changing the algebra used by the SAA II Run to estimate Metered Volumes for Suppliers’ BM Units, in order to make it more robust to high levels of embedded generation.\nThe P265 solution was previously discussed as an alternative solution under P253. The P253 Modification Group unanimously agreed that the solution as detailed in P265 was better than the current BSC arrangements.\n",null,"_",null,"−","Reject","Reject"]
["P264","Two-thirds majority requirement for Panel recommendations on licence originated Modifications'","Drax Power","2010-08-02","From time to time, the licensee (National Grid) may be obligated to raise Modifications to amend the BSC. For example, when directed by the Authority due to the conclusion of a Significant Code Review (SCR). \n\n","P264 proposes that when the BSC Panel votes to determine their final recommendation on a Modification the Licensee as been obligated to raise, a two-thirds majority will be required. If a two-thirds majority is not reached, the Modification will be progressed as recommended for rejection.",null,"_",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P263","‘Code Governance Review: Send Back Process and Environmental Assessment’","National Grid","2010-08-02","In July 2010 Ofgem directed that licence modifications be made to implement the Code Governance Review Final Proposals. In order to comply with the modified Transmission Licence the BSC will need to be amended to reflect the new processes and policies coming into effect.\n\n\n","P263 is the second of two of the Code Governance review Modification Proposals. P263 covers the following areas:\n• Send Back Process\n• Environmental Assessment",null,"_",null,"2010-12-31","Approve","Approve"]
["P262","Code Governance Review: Significant Code Reviews, Self Governance and Code Administration Code of Practice'","National Grid","2010-08-02","In July 2010 Ofgem directed that licence modifications be made to implement the Code Governance Review Final Proposals. In order to comply with the modified Transmission Licence the BSC will need to be amended to reflect the new processes and policies coming into effect.\n\n","P262 seeks to make changes to the BSC in the following areas: \n• Significant Code Review\n• Self Governance\n• Code Administration Code of Practice, assisting Parties, ensuring consistency with other codes\n",null,"_",null,"2010-12-31","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P261","Correcting an omission in the BSC arising from the P216 Alternative Modification legal text","BSC Panel","2010-06-10","We have identified that the P216 ‘Audit of LLF Production’ Alternative Modification legal text did not fully reflect the intent of the approved P216 Alternative Modification solution. ","This Modification amends the BSC to fully reflect the intent of the approved P216 solution.",null,"_",null,"2010-08-09","Approve","Approve"]
["P260","Extension to data provided to the Transmission Company in the TUoS Report","National Grid","2010-06-02","\nThe TUoS report is only provided to the Transmission Company by the SVAA and hence this Modification Proposal would only have a direct impact on the Transmission Company and ELEXON. The content of this data flow would need amending to provide the additional detail.\n","P260 proposes changes to the Transmission Use of System (TUoS) Report (file P0210 – Half Hourly (HH) / Non Half Hourly (NHH) split) from Supplier Volume Allocation Agent (SVAA) for use in its EVE (National Grid’s in house charging software) invoicing system used in developing the indicative and actual transmission usage charges. ",null,"_",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P259","Provision of Applicable Balancing Service Volumes for Interconnectors","National Grid","2010-05-04","All new Interconnectors must be capable of providing Frequency Response volumes to the Transmission Company, who in turn submits the volumes into Settlement as Applicable Balancing Services Volume Data (ABSVD). The Transmission Company is required to allocate all ABSVD to BM Units. However, when the Transmission Company sends the ABSVD it may not know which BM Unit the data relates to. Submission of ABSVD to the incorrect BM Unit will expose the Interconnector to Imbalance Changes.  \n\n","P259 seeks to resolve this issue by ensuring that the ABSVD is assigned to the correct BM Unit. It also seeks to report useful associated Interconnector information on the Balancing Mechanism Reporting System.",null,"_",null,"−","Approve","Reject"]
["P258","Including Party Agents in the Trading Disputes process  ","BSC Panel","2010-04-08","The Trading Dispute Committee instigated a review of the Trading Disputes processes in 2009, which resulted in 12 recommendations, 8 of which are being progressed via 3 Modification Proposals (P256, P257 and P258). P258 is proposing changes to resolve one of the Trading Disputes review recommendations, which is to get Party Agents involved in the Trading Dispute process. The Trading Dispute review group findings indicated that Supplier Agents, particularly Data Collectors (DCs) are likely to know if settlement data is wrong and what the correct data should be. Currently the Supplier Agent may inform the appropriate Supplier of this, but it is then up to the Supplier whether to raise a Dispute. As a result there may be reduced assurance that Settlement data is accurate.","P258 intends to include Party Agents into the Trading Disputes process by providing them with a mechanism to escalate error reporting.",null,"_",null,"−","Reject","Reject"]
["P257","Removal of the concept of Trading Queries","BSC Panel","2010-04-08","A Trading Query is a precursor to a Trading Dispute. When a Trading Query is raised, BSCCo complete a validation check. If a Trading Dispute is raised it is presented to the TDC at a subsequent meeting for review and decision. If a Trading Query is declared invalid by BSCCo the Raising Party can accept the decision or they can reject the decision. This process is inefficient, as no matter what path the Trading Query takes it will always be presented to the TDC for determination. This means that there is no real difference between Trading Queries and\nTrading Disputes. Having both queries and disputes also causes confusion for Parties using the\nprocess. Removing the concept of Trading Queries would streamline the Trading Disputes process and remove any potential confusion for Parties. Furthermore, the current process requires all Trading Disputes to be presented to the TDC for decision even if they haven’t satisfied the 3 criteria and BSCCo has not declared them valid. This is inefficient.","P257 seeks to Remove the concept of Trading Query from the BSC; incorporate elements of the Trading Query process into the Trading Disputes process; and\nallow ELEXON to close invalid Trading Disputes\n",null,"_",null,"2010-11-04","Approve","Approve"]
["P256","Improving efficiency and Clarity of the Trading Disputes process","BSC Panel","2010-04-08","The Trading Disputes Committee has recently completed a review of the Trading Disputes process to identify improvements, making the process simpler and more efficient","P256 seeks to introduce changes  to make the Trading Disputes process more efficient by:\n",null,"_",null,"2010-11-04","Approve","Approve"]
["P255","Profile Administrator: creating flexibility in discharging the services","BSC Panel","2010-04-08","Section E of the Code defines the PrA as a BSC Agent. The principal functions of the PrA are set out in 4.2 of Section S. There is a provision in Section C for ELEXON (as BSCCo) to provide the PrA service itself under certain circumstances - i.e. where attempts to appoint a PrA have been unsuccessful and the Panel’s prior consent has been obtained. ELEXON cannot currently undertake any part of the PrA service itself unless these circumstances are met. In addition, the Code does not currently permit ELEXON to provide the PrA service itself for any period exceeding one year without further Panel approval. These Code constraints can be said to restrict ELEXON’s ability to ensure the most efficient discharge of the PrA service.","P253 seeks to include Half Hourly SVA data in the Interim Information (II) Settlement Run so that it can be used in the Credit Calculation. This will increase the accuracy of the Credit Calculation. ",null,"_",null,"2010-07-22","Approve","Approve"]
["P254","Removal of SVA main  and specified Charge amounts from the BSC","BSC Panel","2010-03-11","The BSC allows for some discrepancy between the ‘initial’ amounts/rates given in Section D Annex D- 3 of the Code for the Main and SVA Specified BSC Charges, and the current amounts/rates which the Panel has approved for these charges. The ‘initial’ amounts/rates in the Code were those in force at NETA Go-Live in 2001. Since this time, the Panel has amended the actual amounts/rates for the SVA Specified Charge and one of the Main Specified Charges (the Notified Volume Charge). Because the Code itself still contains the old ‘initial’  2001 rates/amounts for these charges, this can lead to confusion or misunderstanding as Parties may assume that the numbers in the Code are the latest figures","P254 seeks to remove the Main and SVA Specified Charge amounts and rates from Section D Annex D-3 of the BSC, replacing them with a requirement for BSCCo to publish the current charge amounts/rates on the BSC Website.",null,"_",null,"2010-05-25","Approve","Approve"]
["P253","Improving the Accuracy of Credit Calculations","BSC Panel","2010-03-11","Currently if a Party’s indebtedness is underestimated or overestimated, the Party doesn’t have to lodge additional credit cover; they can lodge material doubt instead. This involves providing evidence that the credit calculation has incorrectly estimated their indebtedness (usually in the form of metered data from D0030 and D0275 flows). This process does required additional work from ELEXON as it is a manual analytical process, but the majority of the work is carried out by the Party lodging Material Doubt as they need to gather the supporting evidence and re-submit data every time there is a change in data (usually every working day).","P253 seeks to include Half Hourly SVA data in the Interim Information (II) Settlement Run so that it can be used in the Credit Calculation. This will increase the accuracy of the Credit Calculation.",null,"_",null,"2011-11-03","Approve","Approve"]
["P252","Removal of Trading Parties’ ability to submit two votes at elections of BSC Panel industry members'","Utilita","2010-02-24","Under the current voting process Trading Parties are entitled to submit one vote for each Energy Account that they hold, Production and/or Consumption in elections of industry Panel members.  the existence of the ability to cast two votes gives rise to the following issues and problems: the current process does not reflect the principle of one party, one vote: the existence of Production and Consumption Accounts does not reflect a relevant distinction in the election of BSC Panel Members in respect of either the objectives of the Panel or its duties and powers. There is therefore no need for Trading Parties to have two votes; there is anecdotal evidence that the ability of Trading Parties to cast two votes has in the past lead to tactical voting with a view to maximising the number of seats secured for a particular interest or constituency. Thus aligned trading parties could vote their production accounts one way, and consumption accounts another; and the proposal would improve overall BSC governance by improving the accuracy with which industry Panel membership reflects the views of the electorate, making the process more accessible and transparent, and establishing better democratic accountability through one party, one vote. ","P252 proposes changes to reflect the principle of \"One party, one vote\" in the elections for the BSC industry Panel members, which will remove the ability to cast 2 votes where Trading Parties have two Energy Accounts (a Production and a Consumption account).",null,"_",null,"−","Reject","Reject"]
["P251","Revision of the election process for BSC Panel Industry Members","E.ON","2010-02-01","Modification P206 led to publication on the ELEXON website of vote totals in the BSC Panel elections, without divulging individual Parties’ preference votes. However, while such transparency was a step forward, the voting system currently used for the election of Industry Panel Members could be improved.","P251 seeks to improve the procedure for electing the Industry Members of the BSC Panel, through adopting a standard Single Transferable Voting System.  ",null,"_",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P250","Prevention of \"Timing Out\" of Authority decisions on Modification Proposals","National Grid","2010-01-04","This Modification Proposal seeks to address two issues: a) \"Timing Out\" of Authority decisions on Modification Proposals. A description of the circumstances which can cause \"timing out\" is included in the section above. The result of \"timing out\" is to cause uncertainty among the industry as to the future of a Modification Proposal, as well as the timescales surrounding that proposal. It also has the potential to waste resources in terms of the costs incurred by industry participants in raising and considering a Modification Proposal which may then \"time out\". b) Ongoing validity of industry analysis supporting a Panel recommendation. There is a concern that, where a significant period of time has elapsed between a recommendation being provided to the Authority and the Authority making a decision, the underlying circumstances will have changed. Such a change could effectively render any supporting analysis \"invalid\" and therefore bring into question the validity of the recommendation under consideration.","P250 proposes to remove the potential for an Authority decision on a Modification Proposal to \"time out”. It also seeks to provide a mechanism for the Panel to inform the Authority if they believe the analysis contained in a Final Modification Report may be out of date.  ",null,"_",null,"2010-06-03","Reject Pro\nReject Alt","Reject Pro\nApprove Alt"]
["P249","Revision of banking arrangements under the BSC","BSC Panel","2009-12-10","This Modification seeks to remove the limitation in the BSC that prevents the BSC Clearer from reinvesting monies held in the Reserve Account with financial institutions other than the BSC Banker so as to leverage a better return on these funds for Trading Parties. Similarly the BSC can be said to restrict the ability of the BSC Clearer to place such funds on term deposits with a view to obtaining a greater return on investment.","P249 proposes to revise the BSC banking arrangements in order to enable the BSC Clearer to invest a proportion of the monies lodged in the Reserve Account in financial institutions other than the BSC Banker, and to provide capability for these monies to be invested on term deposit. This arrangement is intended to enhance the rate of return for Trading Parties on the cash balances lodged in the Reserve Account.",null,"_",null,"2010-06-03","Approve","Approve"]
["P248","Aligning BSC interest calculation requirements with the FAA calculation method and P235 principles’","BSC Panel","2009-12-10","Changes to bring the BSC requirements for four FAA interest calculations in line with the principles of accuracy and fairness established by P235.","P248 proposes to bring the BSC requirements for four Funds Administration Agent (FAA) interest calculations in line with the principles of accuracy and fairness established by P235.",null,"_",null,"2001-03-27","Approve","Approve"]
["P247","Proposer ownership of Modification Proposals","E.ON ","2009-12-01","Current BSC Modification procedures can frustrate the development and efficient prosecution of otherwise viable Modification Proposals. ","P247 would allow the Proposer to vary the solution of the Proposed Modification, and/or withdraw their Modification Proposal, at any time before the Modification Group makes its final recommendation to the Panel.",null,"_",null,"2010-05-28","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P246","Reporting to LDSOs of Aggregated Metering Data for Embedded Networks’","The Electricity Network Company Limited","2009-11-30","There is currently no provision in the BSC to allow Settlement data to be provided to Licensed Distribution System Operators (LDSOs) responsible for embedded Distribution Systems (‘embedded LDSOs’)."," P246 will make Settlement data available to other LDSOs to facilitate portfolio billing under the CDCM.",null,"Yes",null,"2010-03-31","Approve","Approve"]
["P245","Changes to Long Term vacant Sites Timescales'","BSC Panel","2009-11-26","There are a number of requirements in Section S of the BSC that must be met before a Supplier can treat a site as a Long Term Vacant site. One of these requirements is that their Non Half Hourly Data Collector (NHHDC) must make two visits to the site to confirm they cannot obtain a reading as the site is not occupied. These two site visits must be ‘not less than three months and not more than seven months apart’.","P245 proposes that this requirement should be replaced with a requirement for NHHDCs to visit the site ‘not less than 75 calendar days and not more than 215 calendar days apart’.",null,"_",null,"2010-03-31","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P244","Provision of BritNed flow data to the BMRS"," National Grid","2009-08-28","The existing interconnector flows from France to England and from Scotland to Ireland are separately reported to the BMRS. There is no such provision in the BSC for reporting of Netherlands-England flows which are likely to become available in late 2010. A change to the BSC is required to accommodate reporting of a new data item for the Netherlands-England flows. If the BSC is not modified to incorporate this change in a timely manner, the BMRS information on interconnector flows would be incomplete and may lead to inefficient decision-making by market participants.","P244 aims to include data relating to the Netherlands-England Interconnector (BritNed) on the BMRS, which is scheduled to become operational in late 2010. P244 also makes allowances in the BSC for future Interconnector data to be incorporated into the BMRS without the need for a Modification Proposal.",null,"_",null,"2010-11-04","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P243","Publication of Generator Forward Availability by Fuel Type","Louis Dreyfus Energy Services L.P","2009-07-28","The future availability of a Plant/Generator availability cannot easily be viewed due to lack of published data. Allowing publication of relevant data will enable information on potential prices of electricity, the availability of different fuel types, the potential to switch from one fuel source to another and any strategic decisions on generation can be made.","P243 proposes changes to the Balancing Mechanism Reporting System (BMRS).\nCurrently the  future availability of a Plant/Generator availability cannot easily be viewed due to lack of published data. Allowing publication of relevant data will enable information on potential prices of electricity, the availability of different fuel types, the potential to switch from one fuel source to another and any strategic decisions on generation can be made.\nAs a minimum, P243 seeks to: \n· Publish the national Output Useable data on the BMRS, \n· Data relating to ‘2-14 days and 2-52 weeks ahead’; and \n· Publish such data in the same 11 ‘Fuel type categories’ used for Out-turn data.",null,"_",null,"2010-11-04","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P242","Treatment of Exemptable Generation Connected to Embedded Offshore L8Transmission Networks","E.ON","2009-07-24","Currently offshore Exemptable Generators, that are connected via 132kV cables to a Distribution network, are treated in the same way as onshore Exemptable Embedded Generators.\nIn June 2010 the offshore transmission trading arrangements (OFTO) are due to Go Live. These arrangements will consider such 132kV offshore cables to be part of the transmission system. The modifications to the BSC for OFTO Go Live will mean offshore Exemptable Generators would be treated in the same way as a Licensable Generator, as they would be considered to be directly connected to the transmission network.\n","P242 proposes that the BSC is changed to continue to treat offshore Exemptable Generators in the same way as onshore Exemptable Embedded Generators.",null,"_",null,"−","Approve","Reject"]
["P241","Relaxation of Requirement to Separately Meter Licensable Generating Units","RWE Npower","2009-07-21","The Code requires licensable Generating Units to be separately metered. This includes those in Combined Cycle Gas Turbine (CCGT) Modules, even though the Code considers CCGT Modules to be single BM Units. This means existing CCGTs may be non compliant without additional metering. ","P241 seeks to remove a requirement to separately meter Licensable Generating Units for Combined Cycle Gas Turbines (CCGTs). P241 proposes changes to Section K ‘Classification and Registration of Metering Systems and BM Units' of the Code.",null,"_",null,"2010-01-28","Approve","Approve"]
["P240","Switching Plant and Apparatus between BM units","RWE Npower","2009-07-21","Currently, the BSC requires a re-registration process if Parties wish to switch plant and apparatus between BM Units. The re-registration process takes at least 30 Working Days. ","P240 proposes to allow plant and apparatus that comprise Offshore Power Park strings to be moved between BM Units in operational timescales, this will mean changes to Section K 'Classification and Registration of Metering Systems and BM Units'. The arrangements would apply in the case where Exports from and/or Imports to Plant and Apparatus may be electrically switched between transmission connections.",null,"_",null,"2010-01-27","Approve","Approve"]
["P239","Correcting manifest errors and modifying an interface in the P217 legal text","BSC Panel","2009-07-09","Following a detailed review of the legal text for P217 Alternative, ELEXON has identified a number of minor errors in the P217 Alternative Legal Text and the P232 Alternative Legal Text.  ","P239 proposes to address these errors. In addition P239 proposes to bring the BSC description of the BSAD interface from the Transmission Company to BSC Agents in line with the technical solution currently being developed for implementation in the November release. This is not a material change, and has no impact on Parties or the calculation of system prices.",null,"_",null,"2009-11-05","Approve","Approve"]
["P238","Removal of the requirement to Meter each Boundary Point for Offshore Power Park Modules","Centrica","2009-06-26","To require metering on each individual Power Park String provides no benefit to settlement, and potentially imposes significant costs on Parties (particularly for existing projects where the cost of retro-fitting additional metering may be extremely high).","P238 proposes a change to Section K of the BSC. It is proposed that all the Exports from (or Imports to) a BM Unit comprising Offshore Power Park Modules (as defined in the Grid Code) can be treated as a single Export (or Import).\nThe effect of this change is to remove the requirement for separate metering of every Boundary Point for offshore wind farms (however a Party may still install separate Metering if they wished to do so). Provided that the installed metering is able to record the energy Exported (or Imported) by each BM Unit that would be sufficient.",null,"_",null,"2009-11-20","Approve","Approve"]
["P237","Standard BM Unit configuration for offshore power park modules","Centrica","2009-06-26","The Code currently requires each Offshore Power Park Module to be treated as a separate BM Unit. This is administratively inefficient for some configurations of offshore wind farms, and it is not necessary for the economic, efficient and co-ordinated operation of the Transmission System.","P237 came out of Issue 37. It proposes that the list of standard BM Unit configurations, set out in Section K of the Code, is expanded to include an aggregation of Offshore Power Park Modules (where requested by the Lead Party and agreed by the Transmission Company).  \nThis will allow 2 or more Offshore Power Park Modules (a collection of Offshore intermittent Generating Units) to be a single Balancing Mechanism (BM) Unit. Currently, the BSC requires each Power Park Module to be a separate BM Unit.",null,"_",null,"2009-11-20","Approve","Approve"]
["P236","Compensation Claims for MVRN Parties arising from an Outage ","First Hydro Company","2009-04-28","Section Q8 of the BSC allows for a Party to claim compensation for losses incurred as a result of an Outage. Current BSC drafting only allows the Lead Party of a BM Unit to make a Q8 claim, and only refers to the effect on the Lead Parties Trading Charges. However, where a BM unit is subject to a Metered Volume Reallocation Notification (MVRN) it will be the Subsidiary Party’s Trading Charges that are affected  but they cannot claim. ","P236 seeks to amend the Q8 claims process so that where the affected BM Unit is subject to MVRNs, Trading Charges and Avoidable Costs of both the Lead Party and the Subsidiary Party or Parties should be considered.",null,"_",null,"2009-09-23","Approve","Approve"]
["P235","Aligning BSC requirements with the calculation of reconciliation interest performed by the Funds Administration Agent","BSC Panel","2009-04-09","BSC Panel had identified that the BSC requirements for calculating the interest on Reconciliation Charges were inconsistent with those used by the Funds Administration Agent (FAA) systems.","This Modification Proposal seeks to amend the BSC so that the method of calculating interest when determining Reconciliation Charges, as specified in Section N 6.4.2 (b), is revised and aligned to the calculation of reconciliation interest performed by the Funds Administration Agent (FAA) – a method which has been employed since before NETA Go-Live.\nIn particular, the BSC requirements should reflect that the interest for each Reconciliation Settlement Run is calculated:\n- over the period from, and including, the Payment Date of the Initial Settlement Run up to, but not including, the Payment Date of the relevant Reconciliation Run; and\n- Using compound interest calculated using the relevant Base Rate applicable as at, and to, each day in the period.",null,"_",null,"2001-03-27","Approve","Approve"]
["P234","Housekeeping Modification - Correction of manifest errors in P217 Legal Text","BSC Panel","2009-03-12","ELEXON has identified a small inconsistency in an algebraic term, some stylistic changes and two incorrect cross references in the P217 Alternative Legal Text.","P234 corrects manifest errors in the approved P217 legal text.",null,"_",null,"2009-11-05","Approve","Approve"]
["P233","Housekeeping Modification - Correction of SSL references, Letters of Credit, Definitions in Section X and manifest errors in P215 Legal Text","BSC Panel","2009-03-12","The new BSC Service Description for the SVAA will replace the seven existing SVAA Service Lines. The references to the SVAA Service Lines in Section S will need to be replaced with the BSC Service Description. In addition the defined term ‘SVAA Service Line’ will require removal from Annex X-1 as it will not be in use in Section S as a result of the above, and is not used anywhere else within the BSC.","P233 will:\n - Correctly reference the BSC Service Description for the SVAA;\n - Include Letters of Credit UCP600 and ISP98 in the code as Annex M-2 and Annex M-3 respectively, and will amend UCP500, in Annex M-1, to make it consistent with UCP600;\n - Include the correct definitions of two Defined Terms in Annex X-2 Table 6;\n - Delete two terms from Annex X-1; and\n - Correct manifest errors in the approved P215 legal text.",null,"_",null,"2009-06-25","Approve","Approve"]
["P232","Black Start and Fuel Security Compensation and Single Imbalance Price Derivation","National Grid","2008-12-23","Section G of the BSC seeks to address various contingencies, and related provisions. In particular, paragraphs 3 and 4 focus on the issues of a Black Start and Fuel Security respectively. This modification seeks to improve the transparency of the BSC processes and procedures that would be associated with a Black Start or Fuel Security event.","Modification Proposal P232 seeks to improve transparency regarding the compensation arrangements pursuant to a Black Start or Fuel Security Code (FSC) period. The Balancing and Settlement Code (BSC) provides high level details of the compensation arrangements associated with a Black Start or FSC period, however, certain areas require further clarification. P232 will address these areas by recommending more detailed processes and procedures.",null,"_",null,"2009-11-05","Approve","Approve"]
["P231","Black Start and Fuel Security Code Procedures under the Balancing and Settlement Code (BSC)","National Grid","2008-12-23","Section G of the BSC seeks to address various contingencies, and related provisions. In particular, paragraphs 3 and 4 focus on the issues of a Black Start and Fuel Security respectively. This modification seeks to improve the transparency of the BSC processes and procedures that would be associated with a Black Start or Fuel Security event.","P231 aims to clarify the arrangements and obligations to be undertaken during a Black Start or Fuel Security Code (FSC) event, as currently there is no such detail in the BSC. The P231 solution outlines what is to be considered the duration of a Black Start / FSC event and the processes required to enable normal market operation.",null,"_",null,"2009-11-05","Approve","Approve"]
["P230","Enabling Interoperability through the use of CoP10 and CoP5 Metering","SSE","2008-12-22","To allow for advanced metering in non-domestic premises, changes to the Standard Conditions of the Electricity Supply Licence are being progressed. ","P230 seeks to mandate the use of CoP5 or CoP10 (at a minimum) in those circumstances where suppliers are installing advanced meters in accordance with the government's new licence condition. This is intended to: enable suppliers to demonstrate compliance with the licence conditions, and ensure consistency of metering requirements and mitigate issues surrounding interoperability of advanced meters in the market.",{"$nulls":3},"2009-11-26","Approve","Approve"]
["P229","Introduction of a seasonal Zonal Transmission Losses scheme","RWE Npower","2008-11-28","Under the current BSC arrangements all transmission system losses are allocated to BSC parties in proportion to metered energy, whether production or consumption on a uniform allocation basis (45% to production accounts, 55% to consumption accounts). Therefore, the cost of heating (variable) transmission losses is allocated amongst BSC Parties regardless of the extent to which they give rise to them. This means that customers in the north of GB and generators in the south of England have to pay some of the costs of transmitting electricity to locations miles away from the source of generation. The proposed seasonal zonal scheme will enable the variable costs of transmission losses to be allocated on a cost-reflective basis and reflected on parties that cause them. The modification would remove the current cross subsidies and associated discrimination that is inherent in the uniform allocation of transmission losses. The current allocation of transmission losses fails to provide potential connecters to the transmission system with appropriate signals regarding the implications of siting in different parts of the country.","P229 seeks to allocate costs of variable losses in a more cost reflective manner, i.e. reflecting the costs imposed on the NETS by individual generators and suppliers.",{"$nulls":3},"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P228","Replace BMRS High Grade Service charge amounts/rates with references to a BSC Website schedule","BSC Panel","2008-11-13","Section 1 of Annex D-3 states that the amounts/rates levied by ELEXON for the Specified BSC Charges shall be: • The initial amounts or rates set out in Annex D-3; or • Such other amounts or rates which may be determined and notified to Parties by the Panel. The Panel can therefore revise the amounts/rates at any time without needing to change the Code itself. The Panel has recently used this ability to revise the amounts/rates levied for the Dataline Monthly Charge, TIBCO Set-up Charge and TIBCO Software Support Charge with effect from 1 April 2009. For a detailed description of these revisions, see Panel papers 144/10 and 146/06. The Code itself continues to contain the old ‘initial’ figures which will not reflect the actual amounts/rates levied from 1 April 2009. Although Section 1 of Annex D-3 highlights the possibility that the amounts/rates it contains may be altered by the Panel at any time, this does not help participants determine whether they have actually been revised. This could be confusing (especially for new entrants)","P228 would remove the current amounts/rates levied for the Dateline Monthly Charge, TIBCO Set-up Charge and TIBCO Software Support Charge from the Code as these will be revised from 01 April 2009. To enable flexibility, and remove confusion of potentially out of date charges, these High Grade Service charges would be replaced with references to a charging schedule which ELEXON will be required to publish on the BSC Website.",null,"_",null,"2009-04-01","Approve","Approve"]
["P227","Extension Of The Definition Of ECVAA Systems to include the centrally provided communications network","APX","2008-09-28","Under the current arrangements, if the ECVAA experiences a System Failure, a recovery procedure exists that allows participants to submit/re-submit contract notifications to the ECVAA, post Gate Closure, for the affected Settlement Periods.","P227 proposes to extend the definition of 'ECVAA systems' to cover centrally provided communications networks. This would mean that where a party cannot submit contract notifications due to a network communications failure, they will be permitted to resubmit contracts (similar to the way Parties may resubmit contracts if there is a current ECVAA system failure). \nThis issue was originally discussed under Modification Proposal P001 and resembles the P001 Alternative solution which was rejected by the Authority at the time.",null,"—",null,"−","Approve","Reject"]
["P226","Improving Large Combustion Plant Directive Information Disclosure","E.ON","2008-09-01","The visibility of key Large Combustion Plant Directive (LCPD) emission limit/allocations and operating hours data, which affects how BSC parties make such plants available to the market, should be enhanced.","P226 proposes a change to the Section V - Reporting, and seeks to enhance the visibility of key Large Combustion Plant Directive (LCPD) emission limit/allocations and operating hours data, which affects how BSC parties make such plants available to the market.  It seeks to do this through the publication of such data on the Balancing Mechanism Reporting System (BMRS) in a form that is readily understandable to the market. In addition the proposal requires relevant BSC Parties to promptly inform the market (again via the BMRS) whenever they request changes to emission limits/allocations or subsequently have such changes granted under the relevant Emission Limit Value (ELV) or National Emission Reduction Plan (NERP).",null,"—",null,"2009-06-25","Approve Pro\nReject Alt","Approve Pro\nReject Alt"]
["P225","Housekeeping Modification: Updating References to the Party Service Lines","BSC Panel","2008-06-12","The Code Subsidiary Document (CSD) Architecture Principles Document was agreed by the Panel in June 2006 (Panel 115/08). One element of these principles required ELEXON to:\n - create a single PSL, containing the non-functional requirements from the existing PSLs; and\n - move the functional requirements currently in the PSLs into the relevant BSCPs.\nELEXON has almost completed the work by raising nine Change Proposals (CPs).","P225 recommended housekeeping proposal aims to update the references to PSLs within the BSC, to reflect the new location of requirements on the Code Subsidiary Documents. In addition to updating the references, Party Service Lines 110, 120, 130, 140, 150, 160, 170 and 180 will be fully removed from the BSC and the Baseline Statement.",null,"—",null,"2008-11-06","Approve","Approve"]
["P224","Reactive Power Flows Associated with Exemptable Generating Plant","E.ON","2008-04-28","Section K of the Balancing and Settlement Code (BSC) currently prevents Parties other than Licensed Suppliers from taking responsibility for Reactive Power flows absorbed (imported) by Licence exempt generating plant (Exemptable Generating Plant). ","P224 seeks to alter the Code such that Parties other than licensed suppliers may take responsibility for reactive power flows absorbed by licence exempt generating plant.",null,"—",null,"−","Approve","Reject"]
["P223","Improvements to the Profile Administrator Service","BSC Panel","2008-04-10","Issues with the current Profile Administration process have lead to data accuracy problems with the load research sample, these have included difficulties with maintaining a sufficient number of participants and collecting a sufficient amount of data for the Profile Administration sample. \n\n","P223 seeks to improve the process of maintaining sufficient numbers of representative customers in Great Britain in each Profile Class in the Profile Administration Sample, to ensure that the necessary amount of data is used in the derivation of Profiles. This modification therefore seeks to improve quality of these profiles to maintain the accuracy and integrity of the Non Half Hourly Settlement processes.",null,"—",null,"2009-12-01","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P222","Provision of EAC and AA data to Distributors","The Electricity Network Company Limited","2008-02-01","Currently AA and EAC data are provided by Data Collectors to Suppliers and Data Aggregators through use of the DTC data flow D0019. Providing this information to DSOs would enable them to more easily and better understand the loading of their networks.","P222 seeks to implement a solution where DSOs receive estimated annual consumption (EAC) or annualised advance (AA) information for non half hourly sites where use of system charges are settled on an aggregated basis (i.e. where consumption data is provided by the D0030 flow). It is proposed that this information be provided by the non half-hourly data collector sending a D0019 flow to the relevant DSO. This modification proposal follows on from work undertaken as part of Issue 31.  A report on Issue 31 is expected to be submitted to the BSC Panel meeting of 14 February 2008.",null,"—",null,"2009-06-25","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P221","Amendments to the Balancing and Settlement Code to reflect changes to the Fuel Security Code","BSC Panel","2007-12-17","The current provisions of the BSC do not align with the revised FSC. Under Section G1.5 of the BSC, the Panel is required to propose any modifications to the BSC which are necessary to ensure such alignment.","P221 seeks to revise the BSC to reflect the changes made to the FSC on 22 October 2007 (Reference 2). As the FSC is a higher legislative document, the BSC should be revised to ensure consistency across the two governance arrangements.",null,"—",null,"2008-02-25","Approve","Approve"]
["P220","Provision of New Data Items for Improving Market Information","National Grid","2007-10-26","Currently AA and EAC data are provided by Data Collectors to Suppliers and Data Aggregators through use of the DTC data flow D0019. Providing this information to DSOs would enable them to more easily and better understand the loading of their networks. Where DSOs do not receive site specific consumption data it is more difficult for them to assess the loading of their networks. This can lead to networks being overloaded, or customers suffering from voltage complaints or interference. Alternatively, it could lead to inefficient or inappropriate reinforcement of the  distribution system.  ","P220 seeks to address that the current market information does not fully meet the needs of the industry, as indicated by the industry feedback to the Transmission Company’s recent consultation. The industry has also suggested that the key market information is scattered at a number of websites and is not available on a single platform. In particular, there is no daily summary page available for key electricity market information (as is the case for gas) to enable market participants to see quickly the key electricity market operational parameters.\nThe proposed change would lead to the provision of additional information requested by the market, which, in conjunction with the existing market information, could be published in a more user friendly way to deliver a summary page. The summary page when delivered will include a mix of current information already available to the market and the new information referred to in this modification.",null,"—",null,"2008-11-06","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P219","Consistency between Forecast and Outturn Demand ","National Grid","2007-10-26","There are two main defects in the current BSC provisions for the demand-related data:  1)\u0083 The complexity of the make up of the current single demand figure submitted by National Grid under the BSC section Q at various points through the day, of which the best example is that the make up of this figure currently changes after the 0900 submission. 2)\u0083 The fact that this single data stream, the make up of which currently changes through the day could be better broken down into two data sets, detailed in the modification description above, and thereby provide clearer, consistent and more detailed demand forecast and outturn information to market participants via BMRS.","P219 seeks submission and publication of additional data on the BMRS in order to improve consistency, clarity and detail of forecast and outturn demand information, and allow fuller comparison of forecast and outturn data than can be achieved at present. This should give participants more and better information in relation to forecast and outturn demand, allowing more efficient operation of the market.\nThe new data items are:\n1. Initial Transmission System Demand Out-Turn which includes Interconnector Metered Volume and the demand taken by station transformers and pumped storage units.\n2. An additional National Demand forecast which does not include Interconnector flows and the demand taken by station transformers and pumped storage units.",null,"—",null,"2008-11-06","Approve","Approve"]
["P218","Facilitating Micro generation within the BSC","Good Energy Ltd","2007-10-23","Currently, microgeneration is proving too costly to enter into the settlement arrangements. The costs to the supplier have been deemed to be greater than the energy benefit because of the relatively small amount of energy concerned. Ofgem in its reasoning for rejection of modification P213 suggests that only a generator exporting in excess of 400kW a year could be viable under current arrangements. This means export of less than 400kW a year are potentially loss making to Suppliers, and Suppliers would need to see export well above that to commercially enter the market.","P218 seeks create a process to allow more micro generation to be accounted for within the settlement process by treating it in a similar way to NHH unmetered supplies. Each supplier will have a single Pseudo Meter (MPAN) in each GSP group. The supplier will keep a schedule of all sites where they have micro generation including the type and kW rating of the generation.  This will be sent to a new agent (Micro generation Export Operator) who will use an agreed calculation to create a single export EAC based on a supplier’s aggregated micro generation within each GSP group and assign it to the relevant pseudo meter (MPAN). This will then be passed into settlements as per normal, and will be netted off the supplier’s take by the relevant NHHDA.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P217","Revised Tagging Process and Calculation of Cash Out Prices","RWE Npower","2007-10-19","Despite the attempts to differentiate system and energy actions in the derivation of cash out prices through the current tagging processes (SO tagging of forward trades, rule based tagging such as CADL and NIV deemed energy tagging) there are circumstances in which it remains possible for cash out prices to be strongly influenced by system-related actions. In particular bids or offers required to resolve “constraints” and taken out of merit order may be included in the NIV and therefore feature in cash out prices. Consequently, cash out prices may not be fully reflective of the cost of resolving the short-term energy imbalance. This gives rise to incorrect incentives to balance as a result of inappropriate market signals. This may result in an outcome in terms of total imbalance that is less economic and efficient than would be the case if cash out was not impacted by system actions. ","P217 proposed that a revised tagging process is introduced to the BSC that would enable bid/offer acceptances (BOA) and forward trades to be tagged as a “system” or an “energy plus system” (i.e. some energy some system) or an “energy only” action based on the primary reason for the action. Each “system” action would be included in the calculation of cash out prices as an un-priced volume whilst each “energy” and “energy plus system” actions would be included in as a priced volume.\nThe development of the “Tagging Methodology Statement”, the “Replacement Price Methodology Statement” together with enhanced reporting under the BSC should ensure open and transparent understanding of SO actions and increase confidence that cash out prices reflect the cost of resolving the energy imbalance in real time.",null,"—",null,"2009-11-05","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P216","Audit of LLF Production","Smartest Energy","2007-07-30","SVG and ISG currently have no means of checking the accuracy of the LLFs being submitted for their approval and yet LLFs have a significant impact on Settlement; it is thought that distribution losses represent about 7% of total energy. The defect is that there are insufficient controls around factors which have a significant impact on the output of Settlement.","P216 proposes that ELEXON audits the DNOs’ production of LLFs so that SVG and ISG can approve them with some confidence as to their accuracy to the methodology. It is also proposed that ELEXON conducts spot checks that the correct LLFCs have been applied to the correct MPAN. As part of this modification it is also proposed that the Code should state that, should a DNO not make their methodologies and production arrangements available, that their LLFs should not be approved, nor should new LLFs associated with new LLFCs be accepted until such time as they have been audited. In this event, only currently approved LLFs and LLFCs may be used in Settlement. It is further proposed that the Code should state that LLFs may not be changed mid-year.",null,"—",null,"2009-04-20","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P215","Revised Credit Cover Methodology for Generating BM Units","Uskmouth Power Company Ltd","2007-07-27","The modification seeks to address the way in which the CEI is calculated for generating BM Units. At present, the CEI is calculated for each Trading party using an estimate of the BM Unit generation or demand, as attributable to the Party’s Energy Accounts and compared with the Party’s contracted volume. For example, for generating BM Units, this estimate of generation is based on a Seasonal estimate; GC (maximum generation for the relevant BSC Season as notified by the Party) times CALF (calculated for the BSC Season using the previous year’s load factor across the equivalent BSC Season), and therefore has little relevance to current or future trading activity.","P215 seeks to modify Section M1.2 of the BSC for generating BM Units (where the definition of which BM Units this applies to should be defined during the modification process), replacing the BMCAEC of the CAQCE in the calculation of Credit Assessment Energy Indebtedness (CEI) with Final Physical Notification (FPN).",null,"—",null,"2009-06-25","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P214","Issues Relating to Funds Administration","Scottish Power","2007-07-03","The BSC Review identified numerous issues with the current funds arrangements. Two prominent areas were Processing of Transactions and Small Value Transactions.","P214 seeks to amend the current provisions for the Funds Administration process on the basis of approaches that were proposed by the BSC Review 2006/7 ‘Funds Administration process’, and discussed further by the Issue 27 (BSC Review) Group. \nThese are:\n• Introducing electronic delivery of Advice/ Confirmation Notes;\n• Combining the amounts from Trading Charges and each Default Charge onto one daily Advice Note;\n• Introducing thresholds below which an Advice Note would not be produced; and\n• Amending the Balancing and Settlement Code (BSC) to bring it in line with modern banking practices.\n",null,"—",null,"2008-11-06","Approve","Approve"]
["P213","Facilitating micro generation (Optional Single MPAN)","E.ON","2007-04-27","BSC should be amended to address the defects that give rise to high transaction costs for suppliers seeking to register and process data from meters (or meter registers) that record export from microgeneration and to address any consequential reduction in profile accuracy that could arise from solutions that could be implemented under other industry documents.","P213 seeks to amend the current provisions for Non Half Hourly settlement of micro-generation by removing the requirement for the Supplier to request a separate Meter Point Administration Number (MPAN) for the Export register of the meter.\nThe purpose of this change is to reduce the complexity of the settlement process for Suppliers and Supplier Agents, and hence facilitate increased settlement of Micro generation export.  ",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P212","Main Imbalance Price based on Market Reference Price","BizzEnergy","2007-04-27","The current rules are not producing a “clean” energy price for the main price. This situation arises because the current tagging rules that seek to remove certain balancing actions from the pricing calculation are defective and are resulting in a high level of pollution of the energy price from costs that relate to maintaining the system balance.","P212 seeks to replace the current energy imbalance price methodology with an alternative method for determining the main imbalance price paid by parties who are in imbalance in the same direction as the system. The solution would use a market-derived reference price.",null,"—",null,"−","Reject","Reject"]
["P211","Main Imbalance Price Based on Ex-post Unconstrained Schedule","EDF Energy","2007-04-16","The defect identified relates to the actions that actually make up the main imbalance price (“price inputs”), as opposed to the volume of actions that the price is calculated from (“price derivation”). Therefore the current calculation for deriving market length (NIV) and the current level of PAR (500 MWh) are not considered defects as part of this modification proposal. Whilst the treatment of reserve contracts may be considered as price inputs, the derivation of these costs are defined outside of the BSC, and are therefore also not to be considered part of the defect.","P211 seeks to amend the calculation of the “main” imbalance price such that when the market is short (NIV>0), System Buy Price (SBP) will be based on the least expensive Offers that the System Operator (SO) could have utilised on an unconstrained system.  Conversely, when the market is long (NIV<0), System Sell Price (SSP) will be based on the least expensive Bids that the SO could have utilized on an unconstrained system.  PAR Tagging would then be applied to the new price stack to ensure than only the most expensive 500 MWh of Bids or Offers are used to set the main price.",null,"—",null,"−","Reject","Reject"]
["P210","Revisions to the Text in Section P related to Single Notifications of Energy Contract Volumes and Metered Volume Reallocations","BSC Panel","2007-02-05","There are six areas relating to Energy Contract Volume and Metered Volume Reallocation processes in Section P that have been identified as requiring revision or clarification, or are currently open to potential misinterpretation, that this Proposal seeks to rectify. These are:\n1. Effect of an overwrite notification on Settlement Days beyond its Effective To Date;\n2. Part day overwrites of notifications;\n3. Business validation of notifications;\n4. Requests from Parties and Agents not to receive notification of validation failures;\n5. Refusal and rejection of notifications for credit reasons; and\n6. An erroneous cross-reference.","P210 proposes to revise or clarify the Code text in relation to the process of single notification for the purposes of removing the potential for misinterpretation and to ensure that established conventions and practices (and the efficiencies associated with those) are maintained. The Proposal would ensure that the text relating to the notifications processes in Section P of the Code is unambiguous and in accordance with existing conventions, general understanding, industry practice and the Energy Contract Volume Allocation Agent (ECVAA) Service Description.\n",null,"Yes",null,"2007-02-05","Approve Pro\nReject Alt","Approve Pro\nReject Alt"]
["P209","Change of Code References from BSCP531 to BSCP537’","BSC Panel","2007-01-11","Given that BSCP531 (as it currently stands) has to remain in existence for the transitional period, it was established during the implementation phase that it would be prudent to draft the new Qualification Process into a new BSCP. It was considered that references to BSCP531 in both the pre and post P197 arrangements would create ambiguity when interpreting the Code as to which arrangements Qualification Applicants should follow. It was felt that a new BSCP would make it clearer what process Qualification Applicants have to follow and this, in turn, would make the initial stages of the Qualification Process more efficient. This is important for new entrants to the market for whom Code clarity surrounding Qualification is particularly beneficial. As a result of this BSCP537 ‘Qualification Process for SVA Parties, SVA Party Agents and CVA MOAs’ was raised and the current Code references need to be updated. This requires a minor consequential change to all references to BSCP531 in the Code to be replaced by BSCP537.","P209 seeks to change all BSCP531 references in the current Code baseline to BSCP537. This will ensure that the transitional and ongoing Qualification arrangements defined in the Code will be appropriately interpreted. ",null,"—",null,"2007-08-23","Approve","Approve"]
["P208","Housekeeping Modification","BSC Panel","2006-11-09","Minor changes to the Code to correct: manifest errors, incorrect references, redundant clauses, use of Code defined terms, typographical errors and minor inconsistencies.","Under Section F2.1.1(d)(iv) of the Balancing and Settlement Code, ELEXON can recommend a Modification Proposal to the Panel to rectify manifest errors, to correct minor inconsistencies and/or make other minor consequential changes to the Code.",null,"—",null,"2007-02-22","Approve","Approve"]
["P207","Introduction of a new governance regime to allow a risk based Performance Assurance Framework (PAF) to be utilised and reinforce the effectiveness of the current PAF","energywatch","2006-09-29","The existing PAF is considered to be inflexible, and does not necessarily focus on the most important issues.","P207 proposes to introduce appropriate new governance arrangements to allow a risk based Performance Assurance Framework (PAF) to be utilised and to reinforce the effectiveness of the current PAF. It builds on the work undertaken in the recent PAF Review.",null,"—",null,"2007-09-10","Approve","Approve"]
["P206","Publication of BSC Panel Election Results","E.ON","2006-08-03","The BSC Panel exercises judgement on proposed amendments to the Code and makes direct recommendations to the legislated Authority. It is therefore highly influential; and its decisions can affect BSC Parties profoundly. As such, the election of candidates to the Panel should be through an objective and transparent process. The secret ballot is the most widespread measure to ensure that views are known only to the individual voter. The concept is common to virtually all electoral systems. However, there is hardly any precedent for election results, in terms of the actual number of votes cast for candidates, to be kept secret. The current electoral system employed in the BSC comprises a multi-winner system, non-transferable preference votes and a variant on standard quotas. It is unusual to either political or corporate bodies and should be open to scrutiny by BSC Parties. However such scrutiny is made very difficult without disclosure of the voting mechanism. The proposer can see no reason why it should not be possible for Parties to evaluate election results, as it may lead to more efficient governance arrangements. The existing option to require that a BSC Auditor scrutinise the conduct of the election merely allows Parties to validate rather than evaluate the process.","Annex B-2 of the Code should be amended to require BSCCo to disclose the number of preference votes received in each voting round by candidates standing for election to the BSC Panel. Subject to approval, this amendment should be implemented from the submission date of this Modification Proposal, in order to disclose the 2006 election results.\nThe details of preference votes cast by Trading Parties would remain secret. The option of Trading Parties to require that a BSC Auditor scrutinise the conduct of the election would remain unaffected.",null,"—",null,"2007-01-31","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P205","Increase in PAR level from 100MWh to 500MWh","Good Energy Ltd","2006-07-04","The introduction of P194 with a PAR level of 100MWh changes this and Supplier will have no choice but to reduce the price available to smaller generators to hedge against this risk.  This will hit renewable generation hardest just at the time that renewable energy is a key component of the government’s Climate Change work. Good Energy analysis is that the 100MWh band is too tight and may have dramatic consequences on the market.","The purpose of this modification is to amend the PAR level introduced with the introduction of P194 of 100MWh to 500MWh, which will lessen the impact of P194 on smaller parties, in particular variable renewable generators, within the market.",null,"Yes",null,"2006-11-02","Approve","Approve"]
["P204","Scaled Zonal Transmission Losses","British Energy","2006-07-03","Apportion an amount of estimated total variable (heating) losses in each period between BM Units in proportion to their flow volumes multiplied by a scaled zonal marginal Transmission Loss Factor determined from a load flow model. The remaining variable losses and fixed losses would be shared between all flows in proportion to volume as currently. The scaling factor would be determined such that on average over every zone and over time, no BM Unit should expect an allocation of losses less than its uniform volume proportion of fixed losses.  ","Proposed Modification P204 seeks to introduce a zonal scheme for the allocation of the variable (heating) element of transmission losses, whereby zonal Transmission Loss Factors (TLFs) would be calculated for each BSC Year on an ex-ante (forecast) basis for each GSP Group (‘TLF Zone’) using a Load Flow Model based on the solution for P198. Under P198, some BM Units in some TLF Zones (e.g. Generators in GSP Groups in the south and Suppliers in GSP Groups in the north) would be credited with energy through the Transmission Loss Multiplier (TLM) as a result of the introduction of zonal TLFs, whilst the Metered Volumes of other BM Units would be scaled down (i.e. they would receive an energy debit to fund that credit). In contrast, P204 seeks to ensure that on average (as far as is practicable) no BM Units are credited with energy (i.e. receive payments), as a result of a zonal allocation of transmission losses, through the TLM. Under P198 a scaling factor of 0.5 is applied to the zonal TLFs. P204 proposes a different scaling factor calculated so that, on average, only energy debits due to losses would be sought, with no debit (or credit) sought for the most favourable locations. Furthermore, P204 proposes that both zonal TLFs and scaling factors are calculated and applied on a seasonal basis, by each BSC Season. No Alternative Modification has been developed for P204",null,"—",null,"−","Reject","Reject"]
["P203","Introduction of a seasonal Zonal Transmission Losses scheme","RWE Npower","2006-06-26","This modification is based on the seasonal alternative solution to P198 developed at the modification group but without any phasing. Seasonal zonal Transmission Loss Factors (TLF) (the “applicable TLFs”) would be derived ex ante for application to generation and demand BMUs within a zone (the “applicable zone”) for each of the four BSC seasons.","The proposed scheme would retain the current process for allocating transmission losses to generation and demand (45% of transmission losses to production accounts and 55% to consumption accounts).",null,"—",null,"−","Reject","Reject"]
["P202","Energy Imbalance Incentive Band ","BizzEnergy","2006-06-07","Trading parties have strong incentives under the current BSC rules to balance their positions (with positions being represented by energy contracts relative to their predicted metered output) and enabled by an ability to enter into energy contracts up until gate closure. There is a strong dependency on the ability of purchasers to trade energy, especially where a trading party does not have its own production or is not part of a wider corporate grouping. However, electricity spot markets have demonstrated very limited and declining liquidity in trades over a sustained and representative period of time, and this illiquidity tends to be greatest when the system is tighter.","All supplier trading parties with consumption accounts under the BSC should be allowed an Energy Imbalance Tolerance Band in certain defined circumstances. The band should be 20MWh per half-hour trading period. ",null,"Yes",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P201","Energy Imbalance Tolerance Band","Utilita","2006-05-26","Trading parties have strong incentives under the current BSC rules to balance their positions (with positions being represented by energy contracts relative to their predicted metered output) and enabled by an ability to enter into energy contracts up until gate closure. There is a strong dependency on the ability of purchasers to trade energy, especially where a trading party does not have its own production or is not part of a wider corporate grouping. However, electricity spot markets have demonstrated very limited and declining liquidity in trades over a sustained and representative period of time, and this illiquidity tends to be greatest when the system is tighter.","All supplier trading parties with consumption accounts under the BSC should be allowed an Energy Imbalance Tolerance Band in certain defined circumstances. The band should be 20MWh per half-hour trading period. ",null,"Yes",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P200","Introduction of a Zonal Transmission Losses scheme with Transitional Scheme","Teesside Power Ltd","2006-04-21","Section T of the BSC contains the term “transmission loss factor” (TLF), currently set to zero. \nWe propose that, subject to feasibility, from 1st October 2007, the value of TLF be amended from zero to a zonal factor to be derived ex-ante and applied separately to generation and demand by zone, as per P198.  ","P200 proposes that, concurrent to the introduction of zonal TLFs, a transitional scheme is applied to existing generating plant meaning CVA-registered BM Units, including interconnector units, with their production/consumption flag set to “production” (“Production BMUs”).  The transitional scheme would allow time-limited retention of existing transmission loss factors for fixed volumes of energy according to a mechanism similar to the EU ETS.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P199","Quantification of Demand Control in the BSC as instructed under OC.6 (c),(d) & (e) of the Grid Code","National Grid","2006-01-30",null,"P199 seeks to make provision for the treatment of Demand Control within the Balancing and Settlement Code. P199 proposes to treat the demand reduction for each Balancing Mechanism Unit (BM Unit) as an Offer Acceptance. The Offer Volume would be included in the Energy Imbalance Price calculations as un-priced. No payment would be made to the affected BM Units for the Offer Acceptance, but the volume would be reflected in the affected Parties’ credited energy. P199 proposes the inclusion of a process whereby Parties affected by Demand Control may query the amount of Demand Control Volume allocated to them in light of additional information. Alternative Modification P199 seeks to make provision that Parties affected by Demand Control would receive a payment for the associated Demand Control Volumes. The payment for the associated Demand Control Volumes would be made at the Market Price.",null,"_",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P198","Introduction of a Zonal Transmission Losses scheme","RWE Npower","2005-12-16","Under the current BSC arrangements all transmission system losses are allocated to BSC parties in proportion to metered energy, whether production or consumption on a uniform allocation basis (45% to production accounts, 55% to consumption accounts). Therefore, the cost of heating (variable) transmission losses is allocated amongst BSC Parties regardless of the extent to which they give rise to them.  This means that customers in the north of GB and generators in the south of England have to pay some of the costs of transmitting electricity to locations miles away from the source of generation. ","The proposed scheme will enable the variable costs of transmission losses to be allocated on a cost-reflective basis and reflected on parties that cause them. The modification would remove the current cross subsidies and associated discrimination that is inherent in the uniform allocation of transmission losses.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P197","SVA Qualification Processes Review","Laing Energy Ltd","2005-12-12","There are a number of issues relating to the current SVA Qualification requirements that would be addressed by the substantial changes to requirements proposed in this Modification: \u0083 The current SVA Qualification requirements date back to 1998 when the risks associated with new entrants were significantly different than they are today. In 1998 when the incumbents’ franchise was removed the Settlement arrangements were substantially revised and all Metering Systems had to be transferred to the new systems. This presented a huge implementation risk as all SVA participants were “new entrants”. In addition, at this time the degree of Customer churn was not quantified. In contrast, new entrants now are likely to be relatively small and are joining a well-established market and so current Qualification requirements do not reflect the risks posed by new entrants; \u0083 There is a significant amount of overlap between the BSC Qualification requirements and the MRA entry process requirements. Applicants have to complete very similar testing for both sets of governance arrangements before they can enter the market. It is desirable to remove this duplication in testing, by the use of a single set of tests that are applicable to both BSC and MRA requirements; and \u0083 Current BSC Entry Process testing requires Applicants to complete numerous detailed scripts. These do not include exception conditions and do not allow Applicants to plan how they are going to complete processes required by the BSC. The completion of a self assessment form related to business scenarios would make Applicants think in more detail how they would complete the processes required by the BSC.","This Modification proposes changes to the SVA Qualification Processes (Entry Processes, Certification and Accreditation) as recommended by the SVA Qualification Review Group and the Supplier Volume Allocation Group following the review of SVA Qualification Processes.  A new SVA Qualification Processes would be designed. This Modification proposes that the Qualification Model included in sections 3.4 and 3.5 of the SVA Qualification Processes Report replaces the current Entry Process and Certification Requirements. This Modification also proposes that the re-qualification requirements for Suppliers and LDSOs set out in section 4 of the SVA Qualification Processes Report be adopted. Finally, this Modification proposes that changes are made to the Removal of Accreditation status process as set out in section 5 of the SVA Qualification Processes Report.\n",null,"—",null,"2007-08-23","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P196","Treatment of Long Term Vacant Sites in Settlements","E.ON","2005-11-25","The Issue 14 Group was tasked to understand this materiality and their report indicated that about 1% of sites can be classified as long term vacant. Some Suppliers indicated that this was a conservative figure. The Issue 14 Group unanimously agreed that this was a significant issue that needed to be addressed. The Group’s findings were further reinforced by studies carried out by the Halifax Bank and the Government which indicated that there were a substantial number of long term vacant sites in Great Britain. Their figures were actually larger than those given by Suppliers. This confirms that the Group’s analysis is based on very conservative figures.","This modification is proposing a solution to allow for the equitable treatment of long term vacant sites within settlements.  This modification has been raised following significant work undertaken as part of Issue 14.  The Issue 14 Group reviewed the current treatment of long term vacant sites within the BSC and their impact on Settlements and associated areas. The Group concluded (see attached Issue 14 report) that this issue is materially significant and the majority believed that a modification to the BSC should be raised to resolve the problems associated with such sites.\n",null,"—",null,"2007-02-22","Reject","Approve"]
["P195","Neutrality for CCGT BMUs Switching Between Gas and Distillate","SSE","2005-10-03","It is clear that a high level of fuel switching: from gas to distillate and back to gas; is likely to be required for this coming winter (and perhaps beyond). CCGT plants are designed primarily to operate on gas and whilst some are equipped to operate distillate this mode of operation presents additional risk. This is because each time such CCGT switches fuels from gas to distillate and back again there is a risk that these operations cause the plant to trip-off or fail to switch as intended. This, in turn, creates an exposure to electricity cash out prices. It is proposed that this defect be rectified by holding CCGT BMUs that have the capability to switch between gas and distillate neutral to any cashout exposure that arises during the period of fuel switching at times of stress on either the electricity or gas systems.","It is proposed that this defect be rectified by holding CCGT BMUs that have the capability to switch between gas and distillate neutral to any cashout exposure that arises during the period of fuel switching at times of stress on either the electricity or gas systems. In this way the number of switches that will occur will increase which should help ensure that supplies of electricity (and gas) are maintained to consumers across Great Britain. Without this ‘neutrality’ such distillate CCGT BMUs will have little choice but to shut down which, in turn, has significant implications for plant margin and thus for the security of electrical supply over the winter period.",null,"Yes",null,"−","Reject","Reject"]
["P194","Revised Derivation of the 'Main' Energy Imbalance Price","National Grid","2005-08-26","The defect is specifically in the part of the ‘Main’ energy imbalance price calculation which derives a volume weighted average price from all the priced balancing actions remaining in the Net Imbalance Volume (NIV) – i.e. after the various ‘tagging’ mechanisms have been applied, but before BSAD variables BPA/SPA are added. Deriving a volume weighted average price from the entire NIV does not always form a good proxy for the marginal cost of balancing energy, especially at times of energy shortage when the differential between the average price and the marginal price of balancing energy is likely to be greatest. Hence the resultant imbalance price is inhibited from appropriately signalling energy scarcity which could lead to perversities in the forward markets where commercial decisions are heavily influenced by the economics of being in imbalance.","The proposal is to amend the calculation of the ‘Main’* Energy Imbalance Price such that only a predefined maximum volume of priced balancing actions, remaining in the Net Imbalance Volume (NIV), will contribute to the derivation of the volume weighted average imbalance price.  The maximum volume of priced balancing actions will be the most expensive 100MWh remaining in the NIV.  ",null,"—",null,"2006-11-02","Reject","Approve"]
["P193","Improved Arrangements for Modification Proposals raised by the BSC Panel","John Greasley","2005-08-26","Paragraph F2.1.8 of the Code currently requires an initial written Assessment (IWA) for a Modification Proposal to be prepared by BSCCo in time for the same meeting at which any newly raised Modification Proposal will be first considered by the Panel. Paragraph F2.1.9 requires the Modification Secretary to place a “new” Modification Proposal on the agenda of the “next Panel meeting” (i.e. the Panel meeting following the raising of the Modification Proposal). However, a Modification Proposal raised by the Panel on the recommendation of BSCCo or the TDC will already have been presented to a previous Panel meeting for the Panel’s agreement for the Modification Proposal to be raised. Since Panel meetings are held monthly, a logical interpretation of Paragraphs F2.1.8 & F2.1.9 means that in practice it can take up to two months for Panel-raised Modification Proposals to be submitted to the Definition or Assessment Procedure or Report Phase. National Grid believes that this timescale is inefficient and hinders the ability of the Panel to discharge its responsibilities to operate the Modification Procedures in an “efficient, economical and expeditious manner ….”, under Paragraph F1.2.2 of the Code.","This proposal seeks to amend the existing Code provisions such that, where a Modification proposal is raised by the Panel on the recommendation of BSCCo or the TDC as described in F2.1.1(d), the Panel may submit the proposal directly to Definition, Assessment or Report at the same meeting at which the Panel agrees to raise the Mod. In practice, this will mean that the IWA is presented at the same time as BSCCo’s/the TDC’s recommendation to raise the proposal – either as part of the recommendation paper itself, or as a separate attachment.",null,"—",null,"2005-12-22","Approve","Approve"]
["P192","Change of Name of the Transmission Company","National Grid","2005-07-27","A motion was submitted to the Annual General Meeting of the Transmission Company held on 25th July proposing to change the Company name from “National Grid Company plc” to “National Grid Electricity Transmission plc”. The motion also amended the group company name to “National Grid plc” (formally “National Grid Transco plc”). The motion was approved by shareholders and the changes took effect legally on 27th July. The definition of the Transmission Company should consequently be amended in the BSC to align with the new legal name of the Company. The registered number of the company is unchanged.","This Modification Proposal proposes that the BSC be modified to reflect the new name of the Transmission Company – National Grid Electricity Transmission plc.",null,"—",null,"2005-09-27","Approve","Approve"]
["P191","Revised definition of Balancing Settlement Unit to include Power Park Module","RWE Npower","2005-07-25","The proposed amendment will enable the current Grid Code definition of “Power Park Module” to be reflected in the balancing and settlement arrangements. In particular, the change will enable wind farms with numerous individual turbines that form a “Power Park Module” to be defined as a standard Balancing Mechanism Unit when registered in CMRS at the electrical point of connection to the GB Transmission System (or User System if Embedded).","It is proposed that the definition of a single BM Unit under Section K paragraph 3.1.4 (a) is amended to include a Power Park Module as follows:\n“K3.1.4 (a) any Generating Unit or CCGT Module or Power Park Module for whose Exports the Metering System(s) is or are registered in CMRS”\nIn addition it is proposed to include a new definition of “Power Park Module” as follows:\n“Power Park Module” has the meaning given that term in the Grid Code”.\nThis amendment and new definition will allow recent changes to the definition in the Grid Code to allow connection of wind farms to be reflected in the BSC.\n",null,"—",null,"2005-12-21","Approve","Approve"]
["P190","Removal of the obligation on the CDCA to provide a witnessing and sealing service in respect of all Metering Equipment associated with CVA Metering systems","RWE Npower","2005-06-02","This Modification Proposal seeks to remove the obligation on the CDCA to provide a witnessing and sealing service in respect of all Metering Equipment associated with CVA Metering Systems as detailed in Section R 6.1.2 of the Code and place this obligation on the relevant CVA Meter Operator Agent. ","This Modification Proposal seeks to remove the obligation on the CDCA to provide witnessing and sealing service in respect of all Metering Equipment associated with CVA Metering Systems as detailed in Section R 6.1.2 of the Code and place this obligation on the relevant CVA Meter Operator Agent.",null,"—",null,"2006-06-28","Approve","Approve"]
["P189","Clarification to fulfil the intent of P174","EDF Energy","2005-05-23","P174, when implemented in November this year, will allow BM Units associated with Interconnector that has a single Boundary Point to form Trading units and it had been fully assumed and expected by all concerned that the Anglo-French Interconnector would qualify (i.e. that the Anglo-French Interconnector has a single Boundary Point and would be captured by P174). However, it has become apparent in preparing for the implementation that the Anglo-French Interconnector has been registered with two Boundary Points, albeit at the same site, thus precluding BM Units associated with this Interconnector from forming Trading Units as envisaged under P174.","A clarification is proposed to the P174 baseline, also in order to include Interconnectors where the circuits are physically proximate but have multiple Boundary points, whilst still excluding those where the circuits are separated by a significant distance. It is considered that a definition whereby the Boundary Points of the Interconnector must all be at the same Site would meet this requirement (where a ‘Site’ is taken as having that meaning defined in Section K ‘Classification and Registration of Metering Systems and BM Units’).",null,"—",null,"2005-11-02","Approve","Approve"]
["P188","Revisions to Credit Default Positions","British Gas","2005-05-03","Section M of the BSC contains the rules for the calculation of a Trading Party’s Energy Indebtedness, which is represented by the Credit Cover Percentages (CCP). The BSC does not obligate a Trading Party to lodge a minimum amount of Credit Cover, however, this is achieved by the use of 2 levels of Credit Default Status. It is suggested that there is a disparity between the treatment of Generators and Suppliers. This was initially raised as Issue 16 to the SSMG. The group discussed the issue and agreed there was a defect.","Once a Trading Party in Level 2 Credit Default (i.e. the existing Query Period and Cure Periods have expired) breaches 100% CCP, the Party has 2 Working Days (i.e. 48 hours) from the point of breach to lodge sufficient Credit Cover to reduce its CCP to below 90% i.e. exit Level 2 Credit Default. If the Trading Party fails to do this, then it will be in Section H Default. As per the current provisions, the Level 2 Default Cure Period would be discontinued once the 100% CCP breach has occurred. Trading Parties will also be entered into Section H Default if they breach 100% CCP six times within a rolling period of six months on separate days and as a result of separate instances (i.e. a series of six instances in six months will result in Section H Default).",null,"—",null,"2006-06-27","Approve","Approve"]
["P187","Introducing the ability for a BSC Party to request urgent status and for it to be considered by the Authority","British Gas","2005-04-04","Section F of the Balancing and Settlement Code (BSC) contains the rules for raising Modification Proposals. The process allows for BSCCo or the Transmission Company to recommend to the Panel Chairman that a Modification Proposal should be treated as an urgent Modification Proposal and for timetable to be expedited. However, there is no explicit formal process for the raising party to request a modification proposal be afforded urgent status and for that request to be considered by the Authority. ","The modification is proposing to introduce a process that supports the aforementioned defect. BGT also believe there may be some value in clarifying the basis upon which a request for urgency can be granted and this could be considered further by the Modification Group.",null,"—",null,"2005-08-09","Approve","Approve"]
["P186","Rationalising the criteria for the submission and declaration of Demand & Generation Capacities","Npower","2005-01-28","Section K3.4 contains provisions for the submission of Generation and Demand Capacities, and for any subsequent resubmissions within a BSC Season. The current criteria are that these submissions should be an estimate of the relevant capacity to within 0.5MW or 1%, whichever is the lower. These criteria are overly onerous, and put undue obligations on Parties when forecasting initial GC and DC values and resubmitting updated values, as well as upon BSCCo who have to undertake the extensive monitoring and enforcement activities. Removal of the absolute volume criteria will eliminate the current undue discrimination against all BM Units with a GC or DC greater than 50MW, whilst not unduly affecting the BSC credit calculations.","This modification proposes that the criteria for the assessment of Demand and Generation Capacity submissions and declarations, as referred to in Section K 3.4.3 and detailed in Section K 3.4.3, be rationalised to remove the absolute volume criterion.",null,"—",null,"2005-09-22","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P185","Redrafting of BSC Sections U and W in relation to clauses pertaining to the processing and rectification of Trading Queries/Disputes","BSC Panel","2005-01-14","Trading Disputes Committee (TDC), in accordance with legal advice provided to that Committee, and recommended that Section U and W should be redrafted.","This Modification seeks to redraft areas of Sections U and W in order to remedy any perceived deficiencies and improve conciseness. Such redrafting is recommended by the Trading Disputes Committee (TDC), in accordance with legal advice provided to that Committee, and with Sections W2.2.1, W 5.3.1 and W 5.3.2 of the Code.",null,"—",null,"2005-11-02","Approve","Approve"]
["P184","Clarification of BSC Section W in relation to the application of the Query Deadline to Trading Queries/Disputes.","BSC Panel","2005-01-14","Clarification in Section W of the Code is recommended by the Trading Disputes Committee (TDC), in accordance with legal advice provided to that Committee, and with Sections W 2.2.1, W 5.3.1 and W 5.3.2 of the Code.","This Modification seeks to clarify perceived areas of ambiguity in Section W of the Code, which relates to the application of the Query Deadline to Trading Queries/Disputes. Such ",null,"—",null,"2005-11-02","Approve","Approve"]
["P183","Additional Mechanisms for Obtaining a valid Change of Supplier Read","Npower","2004-12-21","CTP proposals aim to increase the robustness of the Change of Supplier process by providing additional mechanisms for obtaining a valid Change of Supplier Read. There are circumstances that exist where a Change of Supplier read is not able to be generated by the Data Collector in a timely fashion. This Modification will facilitate the submission of timely agreed Change of Supply readings by allowing the Data Collector to use valid Old Supplier estimated reads for Change of Supplier in limited circumstances where other reads do not exist.","This Modification Proposal proposes to amend the BSC so that:\n• An estimate of a Change of Supply read, generated by the old Supplier, is acceptable for sending to the Data Collector as a Change of Supply read in certain limited circumstances, and\n• A Supplier who has more than one candidate CoS read (e.g. a customer own read taken at the point of sale; a customer own read taken later in the Change of Supplier process; and/or an estimated Change of Supplier read provided by the old Supplier) can select the most appropriate one for onward transmission to the Non Half Hourly Data Collector. Currently the Supplier is required to forward all customer-provided consumption data to the Data Collector. \n",null,"—",null,"2005-11-03","Approve","Approve"]
["P182","Review and redefinition of the Non Half Hourly Settlement performance measures","Centrica","2004-11-02","The current Settlement performance measure of 97% become effective with the introduction of the 1998 trading arrangements to ensure the equitability of Settlements and to date no such review of its validity has been undertaken. 97% performance measure does not satisfy the desire to achieve the fair and equitable correct allocation of energy by Suppliers. ","This Modification has been developed through the VASMG following the raising of Issue 11 by Scottish Power plc, Centrica plc and E.ON UK.\n\nAnnex S-1 of the Balancing and Settlement Code, requires that Suppliers increase the amount of actual energy provided to Settlements so that by 14 months, 97% of the actual energy rather than estimated energy is submitted. This Modification seeks to revise the current Non-Half Hourly (NHH) Settlement performance measure and the associated Annual Consumption Calculation Process.\n",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P181","NGC Emergency Instruction re Damhead Creek 19.5.04:  Deferral of Settlement Process ","Economy Power Ltd","2004-11-16","The NGC EI re Damhead Creek caused exceptionally high Trading Changes to be calculated on a number of supply companies, including Economy Power. The resolution of this issue is the subject of Modification Proposal P171, and with the uncertainty of its outcome, it is proposed that the data to be entered into the Settlement Process should be deferred until it is approved or rejected, and RF reconciliation is run.","This proposal aims to defer data entry into Settlement Process due to take place on 15 December 2004 arising from the NGC EI re Damhead Creek for Settlement Periods 27 and 28 on 19 May 2004 until the RF reconciliation is due to run. ",null,"Yes",null,"2004-12-13","Reject","Approve"]
["P180","Revision to BSC Modification implementation dates, where an Authority decision is referred to Appeal or Judicial Review","National Grid Transco","2004-11-01","A concern has been expressed that the existing BSC and Licence based provisions in relation to\nimplementation dates are not sufficient in circumstances that relate to Authority BSC Modification decisions that are referred to Appeal or Judicial Review. \n","This proposal aims to introduce the ability for BSC Implementation dates be revised, where and Authority BSC Modification is referred to Appeal or Judicial review.",null,"—",null,"2005-04-07","Approve","Approve"]
["P179","Housekeeping Modification","BSC Panel","2004-10-15","Under Section F2.1.1(d)(iv) of the Balancing and Settlement Code, ELEXON can recommend a Modification Proposal to the Panel to rectify manifest errors, to correct minor inconsistencies and/or make other minor consequential changes to the Code.","26 Minor changes to the Code to correct; manifest errors, incorrect references, use of Code defined terms, typographical errors and inconsistencies.",null,"—",null,"2005-02-23","Approve","Approve"]
["P178","Reduction in the BSC withdrawal timescale for parties who have settled the vast majority of their trading debts","Uskmouth Power Company Ltd","2004-10-04","To improve the efficiency of the withdrawal process and to limit the costs and risks for all parties the withdrawal process should be improved to allow those who can withdraw, without leaving significant debt, to do so earlier than the current 14 months after their last settlement day.\n ","The BSC should be modified to allow parties who are non-physical traders or are only responsible for CVA registered meters to withdraw from the BSC anytime after the second day reconciliation run after the last settlement day, on the condition they have met all the other criteria for withdrawal. Accepting that all parties remain liable for further reconciliation, parties withdrawing before the final reconciliation would be required to leave a cash deposit with ELEXON for the purpose of covering any debts arising. This “withdrawal deposit” would be adjusted with each subsequent reconciliation and a final settlement statement and any remaining money would be returned to the party after the final reconciliation from the last settlement day. ",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P177","Removal of Intertrip provisions from the BSC","National Grid","2004-10-04","Paragraph Q.5.1.5 states that “the operational of intertrip in the circumstances described in BC2.5.2.3 of the Grid Code shall be treated as being an Acceptance…” This modification forms one of a range of changes to industry codes and transmission licence documents required to amend the definition, management and remuneration arrangements associated with operational intertrips. Industry discussion and debate in relation to these proposals was initiated via CUSC Amendment Proposal CAP076. This modification to the BSC is a consequential change required to ensure that duplicate compensation arrangements do not exist following the operation of an intertrip.","This Modification seeks to remove Paragraph Q.5.1.5 and all references to it from the BSC.",null,"—",null,"2005-07-15","Approve","Reject"]
["P176","Clarification of the Requirements for Estimation/Deeming of Meter Readings/Advances in Certain Circumstances to Facilitate Correction of Anomalies in Settlement Consumption","Npower","2004-10-04","Section 4.3 of Annex S-2 of the Code requires Meter Advance values to be calculated from meter readings, except in a number of specific circumstances, where Deemed Meter Advances are required to be calculated and used. There are a number of other circumstances where it is necessary or has been the practice, in some cases following guidelines agreed by the TS2 committee under the Pool governance but apparently not supported by the Code (BSC Issue 8 refers), to estimate or deem meter readings and/or meter advances. This is required to correct the effects of previous errors, affecting Settlement Dates for which the Final Reconciliation Volume Allocation Run may already have been carried out, or provide reasonable estimates of consumption where data such as closing meter readings are missing. The provision of a (hopefully) comprehensive list of the circumstances in which deeming is required addresses\nthe concerns raised by the BSC Auditor (and endorsed by the PAB) about the suggestion of basing the new provisions on more loosely defined categories of circumstances (Ref SVG/42/006).","To remove detailed procedures for deeming of meter advances from Annex S-2 and provide new references in this section of the Code to procedures to be defined in Code Subsidiary Documents providing for the estimation/deeming of meter readings and/or meter advances and the setting of Estimated Annual Consumption (EAC) and/or Annual Advance (AA) values in Certain Circumstances to Facilitate Correction of Anomalies in Settlement Consumption.",null,"—",null,"2005-11-03","Approve","Approve"]
["P175","Development of provisions related to certain bid offer acceptances issued pursuant to the Grid Code (e.g. BC2.9 and BC2.10).","RWE Npower","2004-10-01","Under the Grid Code, NGC will issue bid offer acceptances for intertrips and for emergency instructions issued in response to emergency conditions prevailing on part or all of the NGC Transmission System. In each case, NGC creates an acceptance based on the particular circumstances of the event. In settlement the prevailing bid or offer prices are utilised for such acceptances, which is some circumstances could result in extreme bid or offer prices. The may result in inappropriate price signals and cash flows in the balancing mechanism as a consequence of “system” related events.  ","Changes to the BSC are required to introduce specific provisions relating to certain bid offer acceptances issued under the Grid Code BC2. The provision should allow for construction of replacement bid offer prices and parties to claim for costs incurred in providing the service to NGC (such costs recovered from NGC).\nBid offer acceptances under the Grid Code that are subject to the revised provisions could include emergency instructions and intertrips. Subject to changes to the grid Code, the provisions could also apply to unplanned outages of the transmission system and system events such as demand control.\n",null,"—",null,"−","Reject","Reject"]
["P174","Provision for Users of an Interconnector with a Single Boundary Point connection to form a Trading Unit amongst themselves and with other BM Units at the same site’ ","EDF Energy","2004-08-27","The proposal is to modify the current BSC rule as specified in Para 5.7.1 of Section K, Classification and Registration of Metering Systems and BM Units, such that Interconnector BM Units associated with an Interconnector with a single Boundary Point connection can belong to a Trading Unit.","The proposal is to modify the current BSC rule as specified in Para 5.7.1 of Section K, Classification and Registration of Metering Systems and BM Units, such that Interconnector BM Units associated with an Interconnector with a single Boundary Point connection can belong to a Trading Unit.",null,"—",null,"2005-11-02","Approve","Approve"]
["P173","Revised Settlement Arrangements for Emergency Instructions","National Grid","2004-08-25","Acceptances resulting from Emergency Instructions are not distinguished form other Acceptances within Settlement. As a consequence, the Acceptance Volume resulting from Emergency Instruction will have negative effects. ","The Proposed Modification it to introduce Contingency Provisions into the BSC which apply to Acceptances resulting from a communication described in Q5.1.3 (b) only. For ease of description the communication shall be termed ‘relevant emergency instruction’. The new Contingency Provisions will define arrangements for calculating a replacement Bid or Offer price which will apply to an Acceptance pursuant to a ‘relevant emergency instruction’.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P172","Removal of Emergency Instructions taken for System reasons from Imbalance Price","British Gas","2004-08-25","On 19 May 2004 the System Operator (SO) issued an Emergency Instruction to Damhead Creek Power Station to stop them exporting onto Transmission System. In accordance with the Grid Code BC 2.9.2.3 this instruction should have been treated as a Bid Offer Acceptance (BOA). Section Q 5.1.3 then provides the link between the Grid Code and the BSC by outlining a list of communications that will be classified as Acceptances. British Gas Trading (BGT), in raising this modification proposal, is not proposing to change the process for issuing Emergency Instructions, merely how they are included in the calculation of imbalance prices.\nThe SO currently has the ability to tag forward contracts which includes Energy Related Products, PGB Transactions and System to System services as System or Energy related. This is in accordance with the Balancing Services Adjustment data Methodology Statement (BSAD).","P172 seeks to apply the same changes as P171, however it is the intention of the Proposer that P172 would apply on a prospective basis only (i.e. would not be applied to Emergency Instructions issued prior to the Implementation Date)",null,"—",null,"2005-05-09","Approve Pro\nReject Alt","Approve Pro\nReject Alt"]
["P171","Retrospective removal of Emergency Instructions taken for System reasons from Imbalance Price","British Gas","2004-08-25","On 19 May 2004 the System Operator (SO) issued an Emergency Instruction to Damhead Creek Power Station to stop them exporting onto the Transmission System. In accordance with the Grid Code BC 2.9.2.3 this instruction should have been treated as a Bid Offer Acceptance (BOA). Section Q 5.1.3 then provides the link between the Grid Code and the BSC by outlining a list of communications that will be classified as Acceptances. British Gas Trading (BGT), in raising this modification proposal, is not proposing to change the process for issuing an Emergency Instructions merely how they are included in the calculation of imbalance prices.","P171 seeks to remove Emergency Instructions issued for System balancing reasons from Imbalance Prices. It is the intention of the Proposer that P171 would apply on a retrospective basis (i.e. would apply to historic Emergency Instructions).",null,"—",null,"−","Approve Pro\nReject Alt","Reject Pro\nReject Alt"]
["P170","Amendments to the Balancing and Settlement Code (Code), and to the systems and processes that support it, to allow compliance with the changed application of VAT to Trading Charges","BSC Panel","2004-08-12","The Council of the European Union has directed an amendment to the rules on the place of supply of gas and electricity, for the purposes of turnover taxes. This amendment takes effect from 1 January 2005 and directly affects the manner in which VAT is applied to Trading Charges.\nIn order to comply with this taxation legislation BSCCo have obtained agreement from Customs and Exercise for the proposed way forward. This involves BSCCo's VAT return being used for settling VAT relating to Trading Charges and there may be a requirement to carry out daily VAT balancing via ELEXON Ltd accounts.\n","The Proposed Modification will give the BSCCo the tools to do this in an effective manner that mitigates risks and costs to Parties. New obligations that may need to be inserted into the Code are expected to include, but may not be restricted to:\n· obliging Parties to inform BSCCo / the Funds Administration Agent (FAA) of their\nVAT status in relation to Trading Charges, and to update this information if\ncircumstances change;\n· ensuring appropriate indemnification is in place to protect BSCCo from any\nconsequential costs resulting from incorrect VAT information;\n· obliging Parties to provide relevant overseas VAT information to allow FAA billing\nand invoicing; and\n· allowing any consequential interest resulting from the differential VAT rates that\nmay be applicable to Trading Charges to be appropriately recharged to Parties\n",null,"—",null,"2004-12-06","Approve","Approve"]
["P169","Publication of BMU names on ELEXON website","Smartest Energy","2004-07-27","BMU Ids are currently available on the ELEXON website, along with Party Names and Party Ids. BMU Names are currently not available. ","This proposal seeks to publish the BMU Names against the BMU Ids on the ELEXON website.",null,"—",null,"2005-01-05","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P168","Publication of BMU GC and DC values on ELEXON website","Smartest Energy","2004-07-27","GC and DC data has previously been available on the ELEXON website. Following legal advice that it was not explicitly permitted by the Code, the data has been withdrawn. ","This modification seeks to allow the re-publication of live BMU GC and DC values on the ELEXON website.",null,"—",null,"−","Approve","Reject"]
["P167","Erroneous Calculation of Bid Offer Acceptance (BOA) Volume","British Gas","2004-06-28","The Balancing Settlement Code (BSC) calculates BOA volume based on the Final Physical Notification (FPN) submitted by the Party. In the majority of settlement periods it is appropriate to calculate the BOA volume based upon the FPN. However British Gas Trading (BGT) has identified an anomaly in the calculation of the BOA volume in specific circumstances. This anomaly occurs when a Party re-declares its Maximum Export Limit (MEL) below its FPN after Gate Closure and the System Operator (SO) then accepts a Bid from the Balancing Mechanism Unit (BMU). BGT believe the anomaly identified has a direct impact on the calculation of BOA volume and therefore Party’s credited volume.\n","P167 seeks to amend the calculation of Acceptance Volumes to account for changes in BM Unit Maximum Export Level (MEL) and Maximum Import Level (MIL). The perceived defect was initially raised to the Settlement Standing Modification Group (SSMG) as Issue 7, a summary of the group’s discussions was presented to the Panel at its meeting of 10 June 2004 (Reference 5).",null,"—",null,"−","Reject","Reject"]
["P166","Removal of unintentional effects of P123 to allow Supplier BM unit DC values to be revised downwards during a BSC Season","BizzEnergy","2004-03-26","When P123 was implemented the legal text included a loophole that will not let a Supplier decrease the value QMj for a BM unit (and hence DC) in a BSC Season if the QMj value has already been achieved. The reason for this is that tolerances are applied both prospectively and retrospectively across a BSC Season.","This modification seeks to remove this effect by allowing the tolerances in section 3.4.3 (b) to be applied for the remainder of the BSC Season if the changes to QMij for a Supplier BM unit have been made in accordance with paragraph 3.4.2A (i.e. the changes introduced by P123). This will put the intention of P123 into full effect.",null,"—",null,"2004-08-13","Approve","Approve"]
["P165","Housekeeping  Modification - Removal of Approved Modification P125","BSC Panel","2004-02-23","Under Section F2.1.1(d)(iv) of the Balancing and Settlement Code, ELEXON can recommend a Modification Proposal to the Panel to rectify manifest errors, to correct minor inconsistencies and/or make other consequential changes to the Code.\n\n\n","This Modification Proposal seeks to remove the legal text of Approved Modification P125 from the Balancing and Settlement Code, which would come under the category of manifest error.",null,"—",null,"2004-04-28","Approve","Approve"]
["P164","Housekeeping Modification","BSC Panel","2004-02-12","4 minor consequential changes are required to the BSC as a result of 2 minor inconsistencies and 2 reference adjustments ( a result of the removal of BSCP07 and creation of BSCP27.)","P164 proposes to rectify minor inconsistencies, typographical errors and omissions within the Code in order to promote efficiency in the implementation and administration of the balancing and settlement arrangements.",null,"—",null,"2004-06-03","Approve","Approve"]
["P163","Clarification of the circumstances in which paragraph 6.5 of Section P (calculation of Error Correction Payment) should apply","RWE Innogy","2004-02-02","The insertion of a further paragraph, numbered 6.5.7, in Section P of the BSC. This would make clear that the “adjustment to the data” referred to in paragraph 6.5.2 of Section P refers to all adjustments that result from the determination made by the Past Notification Error Committee in respect of a PNEC investigation.","P163 seeks to clarify the method for calculating the ECP to be made by Parties in relation to upheld PNE claims. On the basis of the arguments put forward in the proposal and accompanying legal opinion, the Proposer of P163 is of the view that ELEXON’s operational interpretation of paragraph P6 of the Code is incorrect. As such, the Proposer of P163 is of the view that the ECP should be calculated on the basis of all adjustments to data resulting from a PNE investigation2 .",null,"—",null,"−","Approve","Reject"]
["P162","Changes to the definition of Imports and Exports ","SSE","2004-01-30","The Code, in particular Section K ‘Classification and Registration of Metering Systems and BM Units’, set out obligations as to how responsibilities for Imports and Exports should be allocated.\n\n\n","This Modification Proposal seeks to address a number of perceived issues and anomalies associated with the definition of Imports and Exports in Section K of the Code.",null,"—",null,"2004-10-19","Approve","Approve"]
["P161","Enhancement of BSCCo Board Structure","National Grid","2004-01-20","According to National Grid, the current Board structure is not in line with the “best practice model” for corporate governance in that its membership does not include the BSCCo Chief Executive or a senior commercial/financial post holder from within BSCCo.","It is proposed to add two new executive positions to the BSCCo Board of Directors (“the Board”) – (1) that of the BSCCo Chief Executive and (2) that of a senior executive of the BSCCo who holds a commercially and financially orientated position within the company. The other existing positions on the Board shall remain unchanged.\nIt is proposed that the senior executive shall be a person nominated and provided by BSCCo to the Board. The Board shall, before any senior executive nominated by BSCCo is appointed to the Board, first consult with the Panel.\nIt is proposed that these new positions have the same rights and obligations as the Industry Directors and Other Directors.\n",null,"—",null,"−","Reject","Reject"]
["P160","Removal of the Anomalous Effect of the Error Correction Payment (ECP) for Multiple Claims Affecting the same Settlement Period and Energy Account","EDF Energy","2004-01-29","Paragraph P6 of the Code sets out how Past Notification Errors (PNEs) are to be administered. This paragraph was incorporated into the Code following approval by the Authority of Modification Proposal P37 ‘To provide for the remedy of past errors in Energy Contract Notifications and in Metered Volume Reallocation Notifications’ (P37). Paragraph P6 includes provision for an ECP, which the Modification Group assessing P37 agreed should be 20% of the benefit arising from an upheld claim (reference 5).","P160 proposes to amend paragraph P6.5 such that upheld claims affecting the same Party Energy Account and the same Settlement Periods would be grouped together for the purposes of calculating the ECP (in order to ensure the calculation and effect of the ECP is consistent for all PNE claimants).",null,"—",null,"2004-08-13","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P159","Extending the scope of e-mail communications under the Code","BSC Panel","2004-01-28","The provisions of the Code relating to e-mail communications require clarification. A number of Code Subsidiary Documents include provision for the sending of e-mail communications between individual Parties. The purpose of this modification is to extend the current rules and confirm existing practice.","To confirm that, save where expressly provided in the Code, notices and communications given in relation to matters contemplated by the Code (and any Code Subsidiary Document) may be sent by e-mail.",null,"—",null,"2005-02-23","Approve","Approve"]
["P158","Introducing the ability to lodge a consolidated Letter of Credit (LoC)","British Gas","2004-01-27","The BSC prevents a Party which owns more than 1 BSC Party Id lodging consolidated credit cover against the group of trading parties. The proposer believes this to be a defect within the current drafting of the BSC. ","Credit can be lodged in the form of a LoC or cash or as a combination of the two. This modification is seeking to allow a Party which owns multiple BSC Party Ids to be able to lodge a single consolidated LoC, rather than having to post an individual LoC for each Party Id. The consolidated LoC would need to be sub-divided and an amount of credit allocated against each Party Id. The proposer believes this modification proposal could be introduced on a voluntary basis.\n",null,"—",null,"−","Reject","Reject"]
["P157","Replacement of current Supplier Charges rules","EDF Energy","2004-01-05","The Proposer believes that a firm set of transparent rules will improve the quality of data entering settlement. The latest BSC Audit has been qualified and it is the Proposer’s view that a major contributory factor to this was the level of poor data quality in Supplier Volume Allocation especially within the Non Half Hourly sector. Supplier Charges are intended to be a corrective technique but the recent work of the VASMG on Issue 6 has raised serious concerns over the appropriateness of the current rules and their effectiveness as a corrective technique.","P157 proposes to replace the current Supplier Charges rules in Annex S-1 of the Code with a robust set of rules that adhere to the proposed criteria for a corrective technique suggested by the VASMG on its work on Issue 6 (Supplier Charges).",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P156","Suspending the implementation of the zonal allocation of transmission losses","Scottish Power","2003-12-19","Implementation of the zonal allocation of transmission losses from 1 April 2004 under P82 will cause costs to be incurred which will be passed on to customers and which, due to the forthcoming implementation of BETTA, cannot be economically justified.","Remove the effect of P82 and P125 with immediate effect and withdraw or disable any system or documentation changes already incorporated into the BSC baseline, such that P82, as modified by P125, is not implemented as originally planned from 1 April 2004.",null,"—",null,"−","Reject","Reject"]
["P155","Appeal Mechanism for Panel and Panel Committee Decisions","RWE Innogy","2003-12-01","Because they relate to the detailed functionality of the systems and business processes of Parties and their Party Agents, changes to Code Subsidiary Documents and other documents referred to in the latter can often have a much more significant impact on Parties (and ultimately on customers, in terms of costs) than changes to the Code itself. The lack of an appropriate appeal mechanism and delayed communication of Panel/Committee decisions and/or the reasons for these may unfairly prejudice the interests of (i.e. discriminate against) certain Parties or classes of Parties and means that decisions may sometimes made which cannot be undone without having a retrospective impact. ","Modify the Code to provide for an appeal process on Panel and Panel Committee decisions, where a party reasonably believes that such a decision is inconsistent with Panel objectives or materially prejudices the interests of a particular Party or class of Parties. In the case of decisions taken by Panel Committees under delegated authority, any appeal should be to the Panel. In the case of Panel decisions, any appeal should be to the Authority.","—","—","—","—","—","—"]
["P154","Rectification of Inconsistencies in the Application of BSC Change Management Processes","Npower","2003-12-01","The issue is that BSCCo appears to have been interpreting the Code requirements as meaning that: 1) Code Subsidiary Document changes raised “in the footsteps of” a Modification Proposal do not have to be subject to the normal Change Management procedures (in particular, BSCP 40) or (in those cases where new requirements are identified subsequent to the consideration of the original Modification Proposal) the raising of a new Modification Proposal. 2) Other additional requirements do not have to be subject to any formal and transparent change management process or necessarily have to be approved by the Panel or a Panel Committee. In particular, the following key procedural steps, which are important to the transparency of the process, do not always appear to have taken place at the time envisaged in the Change Management procedure or at all: · Raising Change Proposal · Publication of CP on BSC Website · Updating of Change Register · Presentation of Change Proposal to Panel Committee for decision · Presentation of revised Code Subsidiary Documents (or other documents) to Panel Committee for approval and confirmation of Implementation/Effective Date.","1) Modify section F of the Code to clarify that the BSC Change Management Procedure should be followed for all changes to Code Subsidiary Documents including those which are related to a Modification Proposal; 2) Bring other related documents imposing rights or obligations, e.g. test scripts referred to in BSCPs, within the scope of the Change Management process.",null,"—",null,"2004-08-11","Approve","Approve"]
["P153","Additional Requirements to Support Competition in New and ‘Out-of-Area’ Distribution Networks","Npower","2003-12-01","The Utilities Act 2000 provides for new distributors to enter the market and for existing distributors to operate out of their distribution services area. In so doing, it facilitates the transfer of the obligation to provide Supplier Meter Registration Services (SMRA) from former “Host PESs” to Licensed Distribution System Operators (LDSOs), with the further aim of facilitating competition in the provision of connections and in supply for customers on these networks. There were lengthy industry discussions about the method for implementing this change, involving consideration of various alternatives. The solution eventually adopted and implemented via Modification P62 involved breaking the previously implicit link between the MPAN (Supply Number) and GSP Group.","The proposed Modification is to introduce new requirements (probably including a new BSCP) to define a robust process for migration of SVA Metering Systems between LDS Os. These need to define the processes required for the coordination of the “logical disconnection” of a Metering System in one SMRS and “logical connection” of a new one in another SMRS, the transfer of the Metering System data between Suppliers and their Agents, and the associated responsibilities. It is suggested that a role of “Transfer Coordinator” is required (as for previous ERS-PRS and SVA-CVA migrations) and that this could most appropriately be fulfilled by BSCCo.",null,"—",null,"−","Reject","Reject"]
["P152","Reduction of Credit Cover for a Trading Party in Default which has ceased trading and which has paid all accrued Trading Charges","PricewaterhouseCoopers (acting as administrative receivers of Shotton Combined Heat and Power Limited)","2003-12-01","There is a lacuna in the BSC relating to the provisions for reduction in Credit Cover in Section M. Credit Cover is provided in respect of a Trading Party’s Energy Indebtedness (Section M 1.1). As currently drafted, a Trading Party may apply pursuant to Section M 2.3.1 to reduce its Credit Cover, but that reduction may not reduce the Credit Cover below the minimum eligible amount.","It is submitted that the BSC should be modified so that a Trading Party which: (i) is in Default, but by virtue only of an event or circumstance arising under Section H 3.1.1(g); (ii) has ceased all forms of trading pursuant to the BSC; (iii) has paid all Trading Charges due on the Settlement Payment Date for the last Settlement Day on which it traded as well as all previously accrued Trading Charges; (iv) has transferred or de-registered any relevant BM Units; and (v) has had an Energy Indebtedness of zero or less than zero continuously over the previous 30 days, may make an application pursuant to Section M 2.3.1 of the BSC to reduce its Credit Cover in a manner which is otherwise in accordance with the rules set out in that Section M.",null,"—",null,"2004-07-05","Reject Pro\nReject Alt","Reject Pro\nApprove Alt"]
["P151","Housekeeping Modification","BSC Panel","2003-11-28","BSC Panel has identified minor inconsistencies, typographical errors and omissions within the Code.","P151 proposes to rectify minor inconsistencies, typographical errors and omissions within the Code in order to promote efficiency in the implementation and administration of the balancing and settlement arrangements.",null,"—",null,"2004-04-21","Approve","Approve"]
["P150","Targeting excess costs of PNE appeals process at unsuccessful appellants","Powergen","2003-11-25","The experience of the PNE claims process far exceeded the expectations of most market participants.  As a result, it is anticipated that much of the pre-appeal PNE process costs will be smeared across all users through BSCCo charges. ","This proposal requires any excess ELEXON costs incurred as a result of a particular appeal  to be paid for by the appellant if their appeal is unsuccessful.  ",null,"—",null,"−","Reject","Reject"]
["P149","Delay to the invoicing of the Past Notification Error (PNE) claims fee ","Powergen","2003-11-27","Circumstances have dictated that insufficient time is available for the industry, the BSC Panel and the Authority to properly consider whether the level of the PNE claims fee should be revised. ","This proposal advocates a one month delay in the invoicing of the PNE claims fee.  ","—","—","—","—","—","—"]
["P148","Revision of the claims fee to avoid undue discrimination between classes of Party in their funding of the PNE claims process ","Powergen","2003-11-27","ELEXON have recently published figures outlining the cost of the PNE claims process (£1.610m) and the total fee income (£225,000)1 based on charging a £5,000 claims fee. Without a change to the level of the claims fee set out in Section P of the Code the PNE costs less fee income shortfall of £1.385m will be recovered through BSCCo charges.   ","This proposal would set the claims fee at £17,889 (roughly 50%).  ","—","—","—","—","—","—"]
["P147","Introduction of a Notified Contract Capacity to limit Party liability in event of erroneous contract notifications","Npower","2003-11-19","Circumstances have dictated that insufficient time is available for the industry, the BSC Panel and the Authority to properly consider whether the level of the PNE claims fee should be revised.","This modification will introduce a new term to the BSC, the Notified Energy Contract Capacity (NECC), which would provide a cap to the total volume of contracts notified to an Energy Account for each settlement period. This cap will provide a limit to a party's imbalance liability, thus limiting any exposure that may occur through erroneous or malicious contract notifications.",null,"—",null,"−","Reject","Reject"]
["P146","New Participation Category to the BSC – Clearing House","OM London Exchange Ltd","2003-11-03","The BSC does not recognise the role played by Clearing Houses in the energy market. By requiring entities that act as Clearing Houses to participate in the BSC as “Trading Parties”, the BSC fails to appropriately regulate and facilitate the development and operation of clearing services active in the UK power market. Clearing Houses operate a different business model from other parties acting as Trading Parties and will not, as part of their routine activities, trade or hold positions in power contracts. Clearing Houses will not seek to profit from price changes in the market. Additionally, Clearing Houses will be subject to regulatory requirements regarding their market neutrality, capital adequacy, commercial confidentiality and operational robustness. Accordingly, as Clearing Houses act in a different manner to other bodies that actively trade and hold UK power positions, it is inappropriate that that Clearing Houses be required to act as Trading Parties under the Code. The BSC can be contrasted in this aspect to the equivalent document for the UK gas industry, the Network Code, which specifically provides for the role of clearing operations.","A new Participation Category of a “Clearing House” will be established under Section A of the BSC. A Party operating as a Clearing House shall hold Energy Accounts, and will be able to submit Energy Contract Notifications for these accounts.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P145","Cost reflective mechanism to allocate any deficit arising from the application of the PNE claims fee","Powergen","2003-10-17","ELEXON have recently published indicative figures  outlining the cost of the PNE claims process, as part of a Past Notification Error (PNE) claim fee consultation.  It now appears highly likely that there will be a significant discrepancy between the administration fee revenue and the cost of the PNE claims process.   With a fee remaining at £5,000 the most likely outcome is a £1.4M deficit.  The PNE claims process was established for the benefit of parties seeking to rectify their past notification errors, and thus the cost of that process should be borne by such parties.   Furthermore the PNE claims process costs should be fairly allocated amongst claimants according to the degree to which they contribute to these costs.","This proposal sets out a relatively straight forward and hence cost effective mechanism to ensure any deficit arising from the application of the PNE claims fee is allocated in such a way as to ensure the costs of the PNE process are both fully and fairly allocated amongst PNE claimants: Each claimant shall pay its share of any deficit in accordance with the following formula:          CPNE = D x VC / VTOT",null,"Yes",null,"−","Reject","Reject"]
["P144","Removal of CADL from the BSC","First Hydro Company","2003-10-10","In approving P18A, Ofgem recognised that it is difficult to establish a rule that clearly determines when acceptances relate to system balancing rather than electricity balancing, especially in real time. In its decision letter, Ofgem also recognised that the P18A solution was considered and developed in a short timescale and that there may be alternative methods of determining the duration of acceptances which could be developed over time and which may better facilitate achieving the applicable BSC Objectives than Modification Proposal P18A. However, the P78 NIV “net imbalance volume” (NIV) negates the need for CADL (CADL is in effect obsolete).","P144 proposes that the Continuous Acceptance Duration Limit (CADL) methodology introduced under P18A is removed from the Code, as the P78 Net Imbalance Volume tagging process negates the need for CADL.",null,"Yes",null,"−","Reject","Reject"]
["P143","Revision of P99 to halt the progression of the PARMS Serials, Standards and Supplier Charge elements","Centrica","2003-09-01","It is recognised that the complexity within the current levels of serials is a contributing factor to the increasing costs of P99 and Centrica recommend a review of these serials and encourage a simpler set of measures to be adopted to measure Suppliers Performance together with the recommendations.","P143 proposes to halt the implementation of the PARMS Serials, Standards and Supplier Charge elements of Approved Modification P99 and revert to the previous Code baseline for these aspects.",null,"—",null,"−","Reject","Reject"]
["P142","Minor refinement to allow a Level 2 Default Cure period in defined circumstances","Total Gas and Power Ltd","2003-08-29","Due to restrictions on banking hours, for e.g. at the weekend, the ability to post monies outside of normal business hours to resolve a level 2 c edit default is not currently a feasible option. ","P142 proposes to amend Section M of the Code to allow Parties who have fallen into Level 2 Credit Default outside of normal business hours, and who have not breached 100% of their credit cover percentage, a two-hour window to post additional funds at the beginning of the next business day.",null,"—",null,"2005-02-23","Approve","Approve"]
["P141","Removal of Unintentional Effects of Approved Modification P106 on Supplier Charges","EDF Energy","2003-08-28","Approved Modification P106 was implemented on 24 June 2003 and introduced the term “Supplier ID”. Whilst this term had not previously existed it had been used for a number of years within the industry to represent a partition of a Supplier’s business. P106 sought to clarify, with respect to Settlement, the use of this term and provide an unambiguous statement on how it should be used.","P141 suggests than an effect of Approved Modification P106 was to require reporting on a Supplier basis, rather than at a Supplier ID level.  This was unintentional and is inconsistent with other provisions within Section S of the Code.  In order to remedy this situation,P141 proposes to amend the Code so that data which forms the basis of the Serials (associated with Supplier Charges) is both provided and reported on a Supplier ID basis.",null,"—",null,"2003-06-23","Approve","Approve"]
["P140","Revised Credit Cover Methodology for Interconnector BM Units","EDF Energy","2003-08-21","EDF Energy identified an anomalous treatment for Interconnector Users in the way the CEI is calculated for the I-BMUs, which at present is based on historical data that has little relevance to current or future trading activity.","P140 proposes to modify the Code such that the values of Credit Assessment Credit Energy Volume for each Interconnector Balancing Mechanism Unit are made equal to the Final Physical Notification data, rather than trying to estimate an energy volume based on past trading activity.",null,"—",null,"2005-02-23","Approve","Approve"]
["P139","Removal of Trading Unit Restriction on Interconnector Users","EDF Energy","2003-08-21","Para 5.7.1 of Section K of the BSC states that ‘An Interconnector BM Unit may not belong to a Trading Unit other than a Sole Trading Unit.’ It is contended that this is an unnecessary and unfair restriction on Interconnector BM Units who may wish to operate as a Trading Unit in similar fashion to other BM Units operating at the same site. The effect of the current rule is such that BSUoS charges are charged to each BM Unit active on the interconnectors for each half hour, whether or not the energy contracted transfers are superposed on each other and even though the System Operator will only react to the ‘net’ positions. By way of illustration, if there was 1000MW contracted from France to UK and at the same time as 500MW from UK to France, there would currently be BSUoS charges made on the gross value of 1500MW. If amended as proposed and an Interconnector Trading Unit is then formed, the BSUoS charges would be charged to those Interconnector BM Units (participating in the Trading Unit) in such a way as if the BSUoS charges were based on the ‘net’ value.","The proposal is to modify the current BSC rule as specified in Para 5.7.1 of Section K, Classification and Registration of Metering Systems and BM Units, such that Interconnector BM Units can belong to a Trading Unit. It may also be necessary for there to be a special Class of Trading Unit i.e. an Interconnector Trading Unit, if one of the existing classifications is not thought appropriate.",null,"—",null,"−","Approve","Reject"]
["P138","Contingency arrangements in relation to implementation of Demand Control measures pursuant to Grid Code OC6","Innogy plc","2003-08-08","There are currently no provisions in the BSC that relate to the impact on BSC parties of Demand Control measures as set out in Grid Code OC6. This Modification Proposal seeks to address this defect by introducing contingency provisions into Section G of the BSC. Tighter system margins have apparently increased the risk that Demand Control could be implemented. A Demand Control event would have a number of consequences including: i. Some parties being forced into a long imbalance position as a result of their customers being affected by Demand Control; ii. Parties thus affected could face potentially significant costs; and iii. Residual reallocation cashflows could be high and unpredictable Currently NGC has the perverse incentive of implementing demand control as a free option rather than contracting forward for an appropriate level of reserve, thus creating a higher probability of demand control being exercised.","P138 proposes to provide measures in Section G of the Code to cater for the implementation of a Demand Control instruction pursuant to Grid Code OC6.  P138 would relate to a set of Demand Control Settlement Periods declared by the Transmission Company.",null,"—",null,"−","Reject","Reject"]
["P137","Revised Calculation of System Buy Price and System Sell Price","Barclays Bank Plc","2003-08-01","The current calculation of cash-out prices fails to reflect the underlying costs of market shortage and, in particular: - Weighted average pricing underestimates the marginal cost of balancing the system at times of shortage; - The current tagging methodology leads to inappropriate tagging out of accepted offers at times of system shortage; - the Buy-Price Adjustment fails to reflect the opportunity cost of using pre-contracted reserve (including standing reserve) on those occasions that the reserve is called since the option fees paid to reserve are averaged over those periods in which the reserve is made available rather than those periods in which it is actually used; - The current calculation of SBP does not account for the use of standing reserve from non-BMU sources.","P137 proposes to set the main imbalance cash out price equal to the highest-priced untagged energy offer acceptance when the system is short and the lowest-priced untagged energy bid acceptance when the system is long.",null,"—",null,"−","Reject","Reject"]
["P136","Marginal Definition of the 'main' Energy Imbalance Price","National Grid","2003-08-01","The current definition of the 'main' energy imbalance price, using an average price methodology, significantly understates the cost of the marginal balancing action. This occurs particularly in times of energy shortage (i.e. high demand and/or low generation availability) when the marginal cost of balancing energy is likely to be high, and the differential between the average price and the marginal price is the greatest. For example, on 10 December 2002, Offers were accepted up to £9,999/MWh for periods 35 and 36, however the System Buy Price was £270/MWh and £261/MWh respectively due to averaging effects. The consequence is that imbalance prices have failed to reflect the true underlying marginal cost of balancing the system and thus have not provided the appropriate signals to the forward markets with the result that participants have insufficient incentives to mitigate the risk of not being able to achieve a balanced position at Gate Closure.","Like P135, P136 proposes to calculate the 'main' energy imbalance price using a marginal methodology but is aimed as an enduring solution to enhance existing incentives to balance. ",null,"—",null,"−","Reject","Reject"]
["P135","Marginal System Buy Price During Periods of Demand Reduction ","National Grid","2003-08-01","The Transmission Company believes that as average imbalance prices can understate the cost of the marginal balancing action, weakened price signals are being provided to the forward markets which may threaten security of supply this winter. Particularly in times of energy shortage, the averaging methodology used to calculate imbalance prices means that market participants will not be exposed to the full cost of the marginal balancing action required to balance generation and demand. Thus there is insufficient incentive for them to contract in the forward markets to mitigate the risk of not being able to achieve a balanced position in all scenarios. During periods of energy shortage this could lead to involuntary customer Demand Control.","P135 proposes to calculate the 'main' energy imbalance price using a marginal methodology, in order to provide more appropriate price signals to incentivise market participants to contract forward to mitigate the risk of not being able to balance at Gate Closure.  P135's proposed change to the 'main' energy imbalance price is an interim solution limited to System Buy Price during 'Periods of Demand Reduction' only, so that implementation could potentially be achieved as soon as possible.  ",null,"Yes",null,"—","Reject","Reject"]
["P134","The Halting Of Unnecessary And Inefficient Work And Expenditure Associated With Approved BSC Modification P82. ","British Energy","2003-06-30","The conclusion of the Dti January 2003 Consultation \"Transmission losses in a GB electricity market\" published on 27th June 2003 is that \"the Secretary of State and the Minister for Energy, E-Commerce and Postal Services, Stephen Timms are not minded to designate Average Zonal Transmission Losses as part of the GB BSC\". If Modification P82 is implemented on 1 April 2004 and operates only for 12 months until BETTA is introduced, from which point locational Transmission Loss charging is removed, the balance of cost and claimed benefit of approved Modification P82 are significantly changed, and the basis of the original Authority direction is significantly changed. On the basis that the claimed net benefits of implementation of P82 as an enduring change were not clearly demonstrated, it is extremely unlikely that net benefit will be achieved by implementing P82 for a few months until BETTA is introduced. Provided work and expenditure is halted quickly, and thereby industry costs may be saved, then reversion of the BSC to its state without implementation of P82 will better meet BSC Objectives (b) The efficient, economic and co-ordinated operation by the Transmission Company of the Transmission System; and (d) Promoting efficiency in the implementation and administration of the balancing and settlement arrangements.","P134 proposes to halt all work and expenditure to implement approved Modification P82, and to undo all intended BSC documentation, system and process changes associated already in progress for P82 following the conclusion of the DTI's consultation on Transmission Losses under BETTA.",null,"—",null,"−","Approve","Reject"]
["P133","Facility to permit BSCCo to undertake the role of the Profile Administrator","BSC Panel","2003-06-30","The data provided by the Profile Administrator is an integral part of the Settlement system underpinning the non Half Hourly Supplier Volume Allocation calculation. EASL’s intention to cease providing the service could mean that it would not be possible to procure, at a reasonable cost, and in a timely manner, an alternative independent service provider with the relevant expertise to undertake the role of the Profile Administrator. An issue exists in that if no service is in place to provide the data, the accuracy of the Settlement system would be compromised and BSCCo would be in breach of its obligations under the Code.","P133 proposes to allow BSCCo, or any of its subsidiary companies, to undertake the role of Profile Administrator in the event that a commercial decision to do so is made.",null,"—",null,"2004-01-05","Approve Pro\nReject Alt","Reject Pro\nApprove Alt"]
["P132","Redefinition of Credit Cover Requirements to account for Reconciliation Charges","TXU Direct Sales Ltd","2003-06-19","The current rules for establishing the Minimum Eligible Amount only look at a 29 day period. The consequence of this is that there is a potential for a Party who voluntarily ceases trading (as opposed to entering an insolvency process) to reduce their Credit Cover to zero prior to the completion of the 14 month reconciliation period and the resolution of Post Final Trading Disputes / Past Notification Errors.","P132 seeks to amend the rules for the calculation of Minimum Eligible Amount to take account of the potential charges arising from reconciliation amounts (which would include Trading Disputes and Past Notification Errors).",null,"—",null,"−","Reject","Reject"]
["P131","Introduction of further provisions relating to the determination of Trading Disputes","BSC Panel","2003-06-23","The TDC is of the view that the BSC should place obligations on Parties with regard to the detection and rectification of Trading Disputes. BSC Panel Paper 60/017 presented legal opinion on the criteria for the validity of Trading Disputes in Section 5.15 of BSCP11. The legal opinion stated that most of the criteria in Item 5.15 of BSCP11 are substantively inconsistent with the Code and therefore invalid, and that those remaining are essentially examples of types of potential settlement errors. The preamble in Item 5.15 of BSCP11 which states that all Disputes raised in accordance with BSCP11 must fulfil one of the listed criteria was also judged to be inconsistent with the Code and therefore also invalid.","P131 seeks to modify the Code to incorporate provisions relating to the timely decision and prompt rectification of Trading Disputes, for example the setting of baseline dates for the detection of settlement errors. It is also envisaged that there will be a requirement for additional provisions relating to referral of Trading Disputes to the BSC Panel and/or arbitration as a consequence of the provisions referred to above.",null,"—",null,"2004-11-03","Approve","Approve"]
["P130","Clarification of the treatment of Non Half Hourly Export Consumption within PARMS performance Serial 1","TXU Direct Sales Ltd","2003-06-02","Annex S-1 section 2.2 Provision of Non Half Hourly (NHH) Data – Serial 1 gives the equations for Serial 1 (Post P99: Energy and Metering Systems on Annual Advances and Actual Readings at Each Volume Allocation Run- Serial SP08). As well as being a pre-estimate of loss, Supplier Serial 1 also incentivises Suppliers to enter accurate data into Settlements. If the Export Estimated Annual Consumption (EAC) CCC energy is subtracted from the Import EAC CCC energy, there is less incentive on the Supplier to enter accurate data and it may result in more Export EACs being submitted into Settlements as it would be more advantageous to the Supplier. This would lead to a negative amount of energy being passed thorough to the Supplier Charge calculation, if a Supplier had a large Export portfolio and a small Import portfolio. The Export CCCs have been approved for inclusion in the Code on 28 September 2003 (the implementation date for P81) however the changes to the SVAA software will not be implemented until 20 January 20041 (the day that the Second Reconciliation Settlement Run (R2) for 28 September 2003 will be carried out). ","P130 proposes to amend the equations used in Provision of Non Half Hourly Data - Serial 1 in Annex S-1 of the Code, to ensure that the totals used in the calculation equate to the absolute sum of the Import and Export Consumption Component Class (CCC) values.",null,"—",null,"2004-01-20","Approve","Approve"]
["P129","Changes to Panel Determination Process and Panel Election Procedures","Powergen","2003-05-07","The current modification decision making process is at times unacceptably slow. This can delay implementation of proposals, even when there is clear majority support for reform. The confidence in the quality of Panel determinations and any subsequent Authority decisions is also in doubt if the Panel is not seen to reflect the balance and breadth of industry views. Allowing Panel to make decisions where there is substantial majority agreement will streamline the Modification Procedures and a simpler constituency based election process carried out at annually will ensure the Panel are responsive to prevailing stakeholder opinion. A more transparent and easier to understand election process where outcomes are perhaps less dependent on tactical use of the existing preference voting system will enhance the legitimacy of the Panel.","P129 proposes to enable the BSC Panel, where there is a substantial majority agreement, to make decisions to implement or reject Modification Proposals.  Only where the hurdle majority has not been reached would the proposal, together with a Panel recommendation, be referred to the Authority for a decision.\nP129 also suggests amendments to the Panel Election procedures, through the establishment of voting constituencies.\n",null,"—",null,"−","Reject","Reject"]
["P128","Correction of Erroneous Energy Contract Volume Notification Errors in specifically defined limited circumstances","Gaz de France Energy Marketing Limited","2003-05-06","Modification Proposal P37 ‘To provide for the remedy of past errors in Energy Contract Notifications and in Metered Volume Reallocation Notifications’ (‘P37’) was concerned with a similar perceived defect, (although it was purely retrospective), and was approved by the Authority on 10 May 2002. Modification Proposal P44, ‘Correction of Notification Errors where Parties are able to satisfy a Reasonable and Prudent Operator test’ (‘P44’) was solely prospective, with a fairly wide application, and was rejected by the Authority on 10 May 2002. P128 refers to the Authority’s determination with regards to both these proposals.","P128 proposes to amend the Code to enable specifically-defined past errors in Energy Contract Volume Notifications (ECVNs) to be remedied on an ex-post basis in limited circumstances.  P128 is intended to be retrospective and effective from the close of the P37 claims window, in order to provide new entrants with similar provisions to rectify notification errors as those for existing entrants under P37.",null,"Yes",null,"−","Reject","Reject"]
["P127","Optional de-registration by insolvent Party","Enron Capital & Trade Resources Limited","2003-04-28","Currently voluntary de-registration by insolvent Parties is not possible, and the administrators/receivers/liquidators responsible for the insolvency process are not able to crystallise liabilities, and thus are not able to limit further loss of value to creditors in pursuance of their duty of care. The deregistration needs to be voluntary as there may be grounds for retaining that registration, for example where the business continues to trade or any other circumstances where de-registration will result in loss of value.","P127 proposes to enable Parties who have entered a process of formal insolvency to have the option at any time during their insolvency to de-register.",null,"—",null,"2004-03-15","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P126","Housekeeping Modification","BSCCo","2003-04-15","BSC Panel raised a Modification Proposal to address the many minor inconsistencies, manifest errors or consequential changes in accordance with Section F2.1.1(d)(iv) of the Code.","P126 proposes to rectify minor inconsistencies, typographical errors and omissions within the Code in order to promote efficiency in the implementation and administration of the balancing and settlement arrangements.",null,"—",null,"2003-08-08","Approve","Approve"]
["P125","Apportionment of the Scottish Interconnector flows to the Northern and North Western GSP Groups for the purposes of calculating losses","SSE","2003-03-31","Modification Proposal P82 clearly stated that the TLF zones would be based on the geographical area of GSP Groups and this is reflected in paragraphs 3.1 and 3.2 of the paper 59/017. However, paragraph 3.3 of the paper 59/017 then states that a 13th zone will be deemed to exist for the termination of the Scottish Interconnector. For SSE, this is incorrect, unnecessary and discriminatory.","P125 seeks to amend Annex T-2 of Section T of the Code (as modified by P82) to place the treatment of the Scottish Interconnector on an equitable footing with the other Transmission Loss Factor (TLF) Zones referred to in paragraph 4.1.  It proposes to apportion the metered volume associated with the Scottish Interconnector between the two GSP Groups into which it is connected and apply a composite TLF based on the TLFs for those zones.",null,"—",null,"2005-04-01","Approve","Approve"]
["P124","Revision of mandatory half-hour metering criteria","TXU Direct Sales Ltd","2003-03-27","The majority view of the VASMG was that the cost to industry of moving to mandatory Half Hourly metering criteria based on annual consumption rather than demand outweighed any potential benefits associated with the introduction of criteria which could be more efficiently implemented and monitored. Hence, there would be an overall detrimental effect on Applicable BSC Objective (c), outweighing the positive effect on Applicable Objective (d), such that Proposed Modification P124 should not be made.","P124 seeks to remove the link between 100kW Premises and mandatory Half Hourly Metering criteria, and proposes a new criterion for the identification of Non Half Hourly Metering Systems that qualify for mandatory Half Hourly Metering.",null,"—",null,"2004-12-01","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P123","Assessment of Credit Cover following a change in a Party’s Portfolio","BizzEnergy","2003-03-26","Under M3.4.3(a), BSCCo can only determine that the assessment of Actual Energy Indebtedness is erroneous once the ECVAA has submitted to it a copy of the level 1 default notice that has been submitted to the affected party. This allows the Party to raise a default query notice within a Query Period of 24 hours commencing from the time the default notice was received by the Party. This Query Period is regardless of holidays and weekends requiring both the Party and BSCCo to provide expensive resources in order to establish the materiality of any doubt as to the accuracy of the information used in the calculation of Actual Energy Indebtedness. BSCCo has no right to anticipate the information even where it has good reason to materially doubt the figures coming from the ECVAA.","P123 seeks to remove perceived defects within the Code with regard to credit cover following a change in a Party's portfolio.  The proposal details instances where a trading party may face an excessive calculation of Credit Assessment Energy Indebtedness.\nP123 seeks to remove this perceived distortion of the competitive market and any resulting discrimination against smaller Suppliers, who may potentially be placed in breach of the Code.  \n",null,"—",null,"2004-02-27","Approve","Approve"]
["P122","Assessment of Credit Cover during Holiday Periods","BizzEnergy","2003-03-26","A Supplier who acts responsibly and aims to run with no exposure to the imbalance mechanism will normally only have modest levels of Energy Indebtedness (indeed given current market conditions will normally be a creditor). However, at times of low demand there are two problems: 1. The use of a seasonal average CALF results in an unrealistically high level of Credit Assessment Energy Indebtedness during the Settlement Days for which the II run has not been completed. To address this, this proposal seeks to allow a specific holiday CALF to be applied. 2. The use of “same day of the week” at the II run to calculate Actual Energy Indebtedness distorts the balance between domestic demands and industrial/commercial demands such that predominantly I&C portfolios are likely to be assessed as having too large a share of GSP Group take. To address this, this proposal seeks to allow specific alternative measures to be applied by BSCCo for the recalculation of the Trading Party’s Actual Energy Indebtedness that are more likely to reflect the metered offtake at such a BMU on holiday period days.","P122 argues that, currently, levels of Credit Cover required to be provided by Suppliers at times of low demand during holiday periods are not reflective of the actual level of indebtedness of the Supplier. The proposal details specific problems which ma y result in artificially high levels of Credit Cover being demanded and suppliers being placed into credit default.  P122 seeks to remove this perceived distortion of the competitive market and any resulting discrimination against smaller Suppliers.",null,"—",null,"2003-09-19","Approve","Approve"]
["P121","Credit Cover following a change in a Party’s Portfolio","BizzEnergy","2003-03-12","Under the current terms of the Code, there is no scope for material doubt as to the calculation of Credit Assessment Energy Indebtedness based on the effects of portfolio change. There will be a continuing impact from the calculation This distortion of the competitive market is discriminatory against smaller Suppliers who specialise in the industrial and commercial sector, as the scale of the impact on their business is material, potentially placing them in breach of the Code.","P121 seeks to remove perceived defects within the Code with regard to credit cover following a change in a Party's portfolio.  The proposal details instances where a trading party may face either an excessive, or an under calculation of, Credit Assessment Energy Indebtedness.  P121 seeks to remove this perceived distortion of the competitive market and any resulting discrimination against smaller Suppliers, who may potentially be placed in breach of the Code.   ","—","—","—","—","—","—"]
["P120","Credit Cover during holiday Periods","BizzEnergy","2003-03-12","A Supplier who acts responsibly and aims to run with no exposure to the imbalance mechanism will normally only have modest levels of Energy Indebtedness (indeed given current market conditions will normally be a creditor). However, at times of low demand there are two problems: 1. the use of a seasonal average DC results in an unrealistically high level of Credit Assessment Energy Indebtedness during the Settlement Days for which the II run has not been completed. 2. the use of “same day of the week” at the II run to calculate Actual Energy Indebtedness distorts the balance between domestic demands and industrial/commercial demands","P120 argues that, currently, the levels of Credit Cover required to be provided by Suppliers at times of low demand during holiday periods are not reflective of the actual level of indebtedness of the Supplier.  The proposal details specific problems which may result in artificially high levels of Credit Cover being demanded and suppliers being placed into credit default.  P120 seeks to remove this perceived distortion of the competitive market and any resulting discrimination against smaller Suppliers.  ","—","—","—","—","—","—"]
["P119","Increased flexibility in the reporting of upheld Trading Disputes relating to Credit Default","BSC Panel","2003-02-19","Section M3.5.1 (a) of the Code requires BSCCo to post a notice on the BMRS and the BSC Website in the case of an upheld Trading Dispute relating to Credit Default. BSCCo is currently unable to post such notices on the BMRS. Discussions have been initiated with the central service provider to determine how much this would cost. It is therefore proposed to modify the Code to require that notices of upheld Trading Disputes relating to Credit Default be posted on the BMRS or the BSC Website. This would be consistent with other reporting requirements set out in the Code and would allow BSCCo to use a commercial judgement. In all events the optionality of both sites should be maintained to cover for any system failure.","P119 seeks to remove the requirement for notices of upheld Trading Disputes relating to Credit Default notices to be published on both the BSC Website and the BMRS - proposing to modify the Code to require that such notices may be posted on either the BMR S or the BSC Website.  This will allow ELEXON to adopt the best business solution as to where to post such notices and would therefore better facilitate the objective in Condition C3 (3)(d) of the Transmission Licence, i.e. promoting efficiency in the implementation and administration of the balancing and settlement arrangements.",null,"—",null,"2003-06-24","Approve","Approve"]
["P118","Increased efficiency in the reporting of Credit Default statements","BSC Panel","2003-02-19","Section M3.2.6 (b) of the Code states that Level 1 Credit Default notices shall be posted as soon as reasonably practicable after 0900 hours on the day following the expiry of the default cure period. This clause was included as a point of practicality. Following the CVA June 03 Systems Release, the ECVAA system will be capable of reporting Credit Default notices as they occur. It would be more efficient and would allow for a more robust system if the requirement to wait until 0900 hours on the following day was removed from the Code.","P118 seeks to allow the Energy Contract Volume Allocation Agent (ECVAA) to report Level 1 Credit Default notices immediately on a Party entering Level 1 Credit Default.  This will add extra rigour to the Credit Default process by allowing the ECVAA system to be developed to automatically post Credit Default notices on the Balancing Mechanism Reporting Service (BMRS).",null,"—",null,"2003-06-24","Approve","Approve"]
["P117","Rectification of Past Notification Errors (PNEs)","BSC Panel","2003-01-29","Modification P61 aimed to remove Ad Hoc Settlement Runs as the means to effect agreed adjustments to settlement data. The Modification Report for P61 proposed that Trading Disputes be settled by: a) Applying the correction at the next convenient Timetabled Reconciliation Run; or b) Using a single DF Run post the Timetabled Final Reconciliation Run; or c) Using an Extra Settlement Determination. Modification P61 was approved on 28 August 2002 with an implementation date of 10 December 2002. The legal text included a number of changes where the term ‘Ad Hoc Settlement Run’ was replaced with ‘Dispute Final Run or Extra Settlement Determination’. However this change was not applied in full to Section P6.5.1(c). The outcome of P61 is that Section P6.5.1 (c) of the Code still mandates the use of DF Runs, without the option to use an Extra Settlement Determination, for the correction of PNEs. This is the only remaining reference in the Code to DF Runs without the option to use an Extra Settlement Determination. It is believed that this outcome of P61 was not intended.","P117 seeks to address a minor inconsistency in Section P6.5.1(c) of the Code, which has been identified following implementation of P61.  Section P6.5.1(c) states that where the Panel determines that a Past Notification Error (PNE) occurred, adjustments shall be taken into account in the next Settlement Run or if the Final Reconciliation Settlement Run has already taken place such adjustments shall be taken into account in the Post Final (DF) Run.  All other references to the DF Run in the Code allow an alternative method of rectification using an Extra Settlement Determination.  ",null,"—",null,"2003-05-27","Approve","Approve"]
["P116","Changes to Allow Line Loss Factor Data from BSC Website to be Used in Settlement","East Midland Electricity Distribution Plc","2003-01-06","Following implementation of Modification Proposal P30, Line Loss Factor data is available on demand via the BSC Website. However, the BSC prevents data from this source being used in settlement. This arbitrary restriction of processes used by Half Hourly Data Aggregators to obtain and load Line Loss Factor data into their systems (and may also impose unnecessary costs on Distribution System Operators). The most likely intention of the BSC was to indicate that the source of the LLFs is the DSO, rather than to dictate the method of dissemination, but the current wording of the document frustrates a significant improvement in efficiency","P116 proposes to remove a restriction in Section S of the Code in order to allow Line Loss Factor (LLF) data from the BSC Website to be used by Half Hourly Data Aggregators (HHDAs).  The Proposed Modification also seeks to amend BSCP528 to remove the obligation on Distribution System Operators (DSOs) to publish LLF via a D0265 data flow.",null,"—",null,"2003-11-27","Approve","Approve"]
["P115","Disapplication Of Supplier Charges Under Certain Circumstances","Innogy plc","2002-12-24","There are a number of circumstances under which the application of Supplier Charges (in accordance with Annex S-1 of the Code) may be inconsistent with the status of these charges as \"liquidated damages\", i.e. \"a genuine pre-estimate of the loss likely to be suffered by other Parties as a result of a failure by a Supplier to meet the applicable Performance Level\", as referred to in Annex S-1 paragraph 1.3.1, or it may be otherwise unreasonable to apply them. Under such circumstances the Panel (or PAB) should have the ability to disapply part or all of the Charges for the relevant period(s), where not to do so would otherwise be inconsistent with the Panel objectives as set out in Section B paragraph 1.2.1. This should reduce the risk of legal challenge to the principle of the Charges, which could have far more serious implications for the integrity of the Performance Assurance Framework and the integrity of the Balancing and Settlement Code arrangements more generally.","P115 proposes to modify Section S, Paragraph 3.2.1 and Annex S-1 to say that Supplier Charges should not be applied where it is demonstrated to the Panel's (or PAB's) reasonable satisfaction (subject to clearly defined criteria) that this would not be reasonable in all the circumstances.",null,"—",null,"−","Reject","Reject"]
["P114","Entitlement of Licence Exemptable Generators (“LEGs”) and other Non-trading Parties to BSC Membership Without Evidence of Trading","Slough Energy Supplies Limited","2002-12-02","Licence Exemptable Generators (LEGs) and other Non-trading Parties should be entitled to remain BSC Parties if none of the steps referred to in A2.6.3 are taken.","This Modification seeks to alter the current conditions of paragraph 2.6 of Section A of the BSC related to \"Withdrawal of a Party which does not commence trading\" to allow full access to market data. ",null,"—",null,"2004-02-24","Approve","Approve"]
["P113","E-mail communications under the Code","BSC Panel","2002-11-27","The provisions of the Code relating to the giving of communications require clarification in this area.","This Modification proposes that where general communications are to be given by the Panel, ELEXON, a Panel Committee or a Modification Group to all Parties (or a class of Parties), these may be sent via email.  This Modification therefore confirms current practice.",null,"—",null,"2003-07-19","Approve","Approve"]
["P112","Removing the obligation on new BSC Parties acceding to the BSC Framework Agreement to comply with Section A 2.2.5","BSC Panel","2002-11-27","Section A 2.2.5 of the BSC requires that a person wishing to enter into or accede to the BSC Framework Agreement and become a Party to the BSC must comply with the requirements set out in the IPR Litigation Requirements document (and related undertakings of confidentiality). The dispute to which this document refers has now been resolved and therefore it is recommended that the BSC be amended to reflect the fact that the obligations in Section A 2.2.5 are not relevant to new Parties acceding to the BSC Framework Agreement. ELEXON has taken legal advice from the solicitors instructed to defend the OSL claim on the question of whether current BSC Parties should remain bound by their existing confidentiality undertakings in relation to the IPR Litigation Requirements document. The advice received is that it would be desirable if these undertakings remained in place in part to enable ELEXON to exert continuing control over what information is disseminated about the litigation and associated proceedings.","This Modification proposes to remove the obligation on new BSC Parties acceding to the Framework Agreement to comply with the provisions of A2.2.5, whilst ensuring that the undertakings as to confidentiality remain in place in relation to existing BSC Parties.",null,"—",null,"2003-04-07","Approve","Approve"]
["P111","Procedure to allow the BSC Panel to refuse to accept Contingent Modification Proposals ","Powergen","2002-11-27","A modification proposal (P109) is currently being considered that attempts to anticipate the possible implementation of another pending modification proposal. It is also possible that other BSC Parties may also seek to submit other ‘contingent’ modifications to attempt to insure against the risk of future changes to the code. Such proposals undermine the existing flexible BSC governance arrangements, which were designed to facilitate incremental reform of trading arrangement rules consistent with the Applicable BSC Objectives. Permitting ‘contingent’ modification proposals could potentially limit the beneficial effects of future modification proposals.","This Modification proposes to introduce a procedure to allow the BSC Panel to refuse 'contingent' Modifications - i.e. proposals that are not 'stand-alone' but are dependent on other pending Modifications.",null,"—",null,"−","Reject","Reject"]
["P110","Nullification Of Volume Notifications Where No Notification Authorisations Are In Place","AES Drax Power Ltd","2002-11-04","Where all of the following circumstances prevail: - a valid Volume Notification has been made; - the Volume Notification covers Settlement Periods for which Gate Closure has not yet occurred; - all Energy Contract Volume Notification Agent Authorisations between the two Parties have been terminated; and - the Party and counter-Party cannot agree to establish new Authorisations there is potential for the Parties to be exposed to the consequences of Energy Imbalance Prices with no way of adjusting their position.","This Modification suggests that there are certain circumstances which could leave a Party exposed to the Energy Imbalance Prices without any way of altering their position.  Under such circumstances it is proposed that the effect of such Volume Notifications for Settlement Periods for which Gate Closure has not yet occurred should be nullified on request from one of the two Parties.",null,"—",null,"2003-11-05","Approve","Approve"]
["P109","A Hedging Scheme for changes to TLF in Section T of the code","British Energy","2002-11-01","There is lack of stable signals for long-term investment, and the potential stranding of sunk costs, through a voluntary hedging scheme for any change in TLF value envisaged under Section T of the BSC.","This Modification proposes to implement a hedging scheme to mitigate the risk that the BSC Transmission Loss Factor (TLF) in Section T of the BSC will in future be set to any value except zero.",null,"—",null,"−","Reject","Reject"]
["P108","Modification to enable BSCCo to prepare for the implementation of British Electricity Trading and Transmission Arrangements (BETTA)","British Gas","2002-11-01","BSCCo is not currently able to undertake any work in relation to preparation for the introduction of a GB-wide BSC under BETTA, as the scope of its activities, resources and services is limited only to those necessary to fulfil its role in relation to balancing and settlement in England and Wales. BSCCo must contribute to BETTA implementation to increase the assurance that the target BETTA implementation date of April 2004 will be met.","This Modification proposes to authorise BSCCo to provide or procure assistance to the Gas and Electricity Markets Authority in connection with the development and implementation of the British Electricity Trading and Transmission Arrangements (BETTA).",null,"—",null,"2003-02-06","Approve","Approve"]
["P107","Data Retention Requirements for Post-Final Trading Disputes","SSE","2002-10-30","Currently, the BSC provides an extremely protracted timetable for raising and resolving Trading Disputes. The cut-off for raising Disputes is set out in Section W 1.2.5 thus allowing a whole twenty-two months after Final Reconciliation for Parties to raise a Trading Dispute. The cut-off for resolving Disputes is set out in section U2.2.4 thus allowing an unlimited period of time for resolving disputes.","This Modification proposes to amend the cut-off points for raising and resolving Trading Disputes and bring the BSC (as modified by P61) closer to existing practice.  The precise cut-off points will be open to discussion by the Modification Group.",null,"—",null,"2003-11-04","Approve","Approve"]
["P106","Amendment to the BSC to allow Multiple Supplier Ids","British Gas","2002-10-25","Whilst the Code is silent on the use of multiple Supplier Ids, this Modification is being proposed to provide more rigour to Section S of the Code by recognising their existence. There are currently Parties registered within the Central Registration System with more than one Supplier ID, however, the Code does not explicitly provide for multiple Supplier Ids nor does the registration procedure support the process of a Supplier registering more than one Supplier ID. The adoption of multiple IDs has been the most efficient method for implementing trade sales or mergers and the Supplier default process, rather than the more lengthy Change Of Supplier process. Thus, the use of multiple Supplier Ids provides the most efficient implementation of the Code arrangements in such cases and improves efficiency within the central administration service. The use of multiple Supplier Ids has also been adopted as an efficient way for Suppliers to manage their internal business requirements. For example where a Supplier wishes to separate half-hourly and non half hourly volumes.","This Modification proposes to amend the BSC and relevant subsidiary documents to acknowledge the concept of multiple Supplier IDs.",null,"—",null,"2003-06-24","Approve","Approve"]
["P105","Introduction of Zonal Transmission Losses on a Marginal Basis without Phased Implementation","Powergen","2002-10-24","Currently the cost of transmission losses is not accurately targeted at BSC Parties that are to a greater or lesser extent contributing to those losses. By introducing a zonal differentiation in the allocation of losses the proposal will provide appropriate locational signals to parties which will help reduce overall transmission losses in the short-term and encourage more optimal siting of generation and demand in the longer-term. Adoption of a marginal approach ensures that robust economic signals are provided to relevant users. The current uniform approach to allocation of transmission losses fails to provide appropriate cost signals. It effectively provides hidden cross-subsidies for northern generation and southern demand, whilst unfairly placing additional costs on southern generation and northern demand. The industry has been aware of this longstanding distortion at the heart of electricity trading arrangements, from the inception of the England and Wales Electricity Pool. Indeed OFFER in its 1989 Annual Report stated that their should be locational pricing for the use of NGC’s transmission system and made it clear that it envisaged transmission losses should include locational signals.","This Modification proposes that transmission losses are allocated on a zonal rather than on a uniform system-wide basis.  A Transmission Loss Factor Agent (TFLA) would be appointed to calculate zonal marginal monthly TLFs for each BMU on an ex ante basis.\nThis approach is consistent with a potential P75 Alternative considered by the TLFMG as part of the P75 Assessment Procedure.\n",null,"—",null,"−","Reject","Reject"]
["P104","Amendments to the Solution to P78 ‘Revised Definitions of System Buy Price and System Sell Price’","BSC Panel","2002-10-17","Issue 1: The issue that has arisen here is related to the equation for calculating the Net Imbalance Volume (Section T 4.4.4A).Issue 2: During the detailed implementation and development work on Proposed Modification P78, it was noted that the proposed Energy Imbalance Price mechanism is silent on the circumstances where there are no balancing actions (and therefore volume) eligible for use in the (main) Energy Imbalance Price calculation. ","This Modification proposes to rectify two issues within the legal drafting giving effect to the Proposed Modification P78 'Revised Definitions of System Buy Price and System Sell Price', due to be implemented on 25 February 2003.  The first issue concerns the definition of the Net Imbalance Volume, and the second relates to the Energy Imbalance Price Calculation.",null,"Yes",null,"2003-02-25","Approve","Approve"]
["P103","Respecification of Trading Data","Slough Energy Supplies Limited","2002-10-07","With the advent of NETA, consideration was given as to how market data should be made available, both publicly and to BSC Parties. ","This Modification proposes to alter Table 1 (BMRS) of Annex V-1 of the BSC (Tables of Reports) to make crucial market information available to LEGs with more transparent and usable content.",null,"—",null,"−","Reject","Reject"]
["P102","Entitlement of Licence Exemptable Generators (“LEGs”) to BSC Membership Without Evidence of Trading","Slough Energy Supplies Limited","2002-10-07","With the advent of NETA, some consideration was given to how market data could be made publicly available. The Balancing Market Reporting System (BMRS) provides, free-of-charge, a range of information. This includes final physical notifications, imbalance price data and the anticipated net system imbalance for each half-hour.","This Modification seeks to alter the current conditions of paragraph 2.6 of Section A of the BSC related to \"Withdrawal of a Party which does not commence trading\" to allow full access to market data.  It proposes that Licence Exemptable Generators (LEGs) should be entitled to remain BSC Parties if none of the steps referred to in A2.6.3 are taken.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P101","Housekeeping Modification","BSC Panel","2002-09-16","BSC Panel identified minor inconsistencies, typographical errors and clarifications within the BSC.","This Modification proposes to rectify minor inconsistencies, typographical errors and clarifications within the BSC.",null,"—",null,"2003-01-23","Approve","Approve"]
["P100","Extension of Demand-side Trading Units in order to increase the competitiveness of the market for embedded benefits","Slough Energy Supplies Limited","2002-09-02","Under the current trading arrangements, Licence Exemptable Generation (LEG) faces barriers to achieving a reasonable return on its generation.","This Modification proposes amendments to the BSC in order to free up embedded benefit so that it can be traded efficiently and competitively (but without requiring new contractual relations between NGC and embedded generators).",null,"—",null,"2003-11-05","Approve","Approve"]
["P99","Changes to Accreditation and the PARMS Serials and Standards, resulting from the Performance Assurance Framework (PAF) Review (Phase 1)","British Gas","2002-09-02","Following feedback from Market Participants and Ofgem, the BSC Panel established the PAF Project to review all aspects of the techniques outlined above. The purpose of the review was to ensure that the PAF is delivering an appropriate level of assurance across the full range of the BSC trading arrangements in a cost-effective manner.","This Modification proposes amendments to Accreditation and the PARMs Serials and Standards, resulting from the Performance Assurance Framework (PAF) Review (Phase 1).  The proposal aims to contribute to the production of a complementary and robust PAF.",null,"—",null,"2004-05-01","Approve","Approve"]
["P98","Dual Notification Of Contract Positions.","Dynegy","2002-09-02","Dynegy has always maintained that the single contract notification system under the BSC adds to the trading risks for all parties and adds additional costs to trading under NETA.","This Modification proposes to introduce a voluntary dual notification system for contract positions between BSC parties.  The new process would be based on the specification drawn up under Modification P4.",null,"—",null,"2004-11-08","Reject","Approve"]
["P97","Modification to enable ELEXON to prepare for the implementation of British Electricity Trading and Transmission Arrangements (BETTA)","Powergen","2002-08-30","In fulfilling the current BSSCo role, ELEXON is limited to providing and procuring resources and services to support the BSC in the England and Wales electricity market. This proposal will enable ELEXON to formally carry out initial preparatory work in connection with the BETTA project, whilst ensuring BSC Parties solely generating or supplying electricity in England and Wales are not required to provide the initial funding for such work. Through separate ELEXON accounting and budgeting a framework is created within the BSC to ensure that costs can, at a future date, be appropriately targeted at parties that will ultimately benefit from the introduction of BETTA.","This Modification proposes to authorise ELEXON to provide or procure assistance to the Gas and Electricity Markets Authority ('the Authority') in connection with the development of the British Electricity Trading and Transmission Arrangements (BETTA) project.","—","—","—","—","—","—"]
["P96","Merger Of Assessment & Definition Phases In The Modification Process","Dynegy","2002-08-13","The existing definition process invariably strays into the assessment of the modification, and by dealing with the two processes together the modification process should become quicker, more efficient and easier to understand. The process would also facilitate more effective consultation, in some cases, by allowing participants to only respond to fully worked up proposals during the modification process. The more compact process will also reduce the quantity of paper work for both ELEXON and the participants. Many of the reports undertaken during the modification process are repetitive and very lengthy. A shorter modification process could produce one, more detailed report that would allow participants greater chance to read more detail on all the changes going on in the industry.","This Modification proposes to merge the existing Definition and Assessment procedures for Modifications into one stage where a Modification can be both defined and assessed.",null,"—",null,"−","Approve","Reject"]
["P95","Transitional Amelioration of Barriers to Licenced Exempt Generators’ Market Participation","Slough Energy Supplies Limited","2002-07-12","LEGs are unfairly disadvantaged by NETA as the new arrangements have imposed a number of barriers to LEGs’ ability to trade on a fair basis as compared to large generators.","This Modification seeks to ameliorate barriers to market participation for Licenced Exempt Generators.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P94","Introduction Of A Process To Allow The Panel To Recall Modification Reports From The Authority To Allow The Legal Drafting To Be Corrected If Working Assumptions Prove To Be Incorrect.","BSC Panel","2002-07-08","In many cases the Mod Proposal (“the latter Proposal”) will have interactions with a Mod Proposal which has already been submitted to the Authority for decision (“the earlier Proposal”). The Authority’s decision on the earlier Mod Proposal will therefore impact the draft wording used to give effect to the latter.","This Modification proposes to introduce a process to allow the Panel to recall Modification Reports from the Authority in order to correct the Legal Drafting if working assumptions prove to be incorrect.",null,"—",null,"−","Approve","Reject"]
["P93","Introduction Of Process For Amendment Of Proposed Modification Implementation Dates","BSC Panel","2002-07-08","Implementation Date of each Proposed Modification that it submits to the Authority for determination. Where a specific Implementation Date is identified, this will normally be given in conjunction with a ‘latest’ date for the Authority’s decision. The Implementation Dates reflect the necessary time for systems and processes to be developed, tested and implemented, consistent with the BSC Release Strategy. If the Authority’s decision is not made within the time allowed for, i.e. by the ‘latest’ date, the specified Implementation Date may be infeasible. Alternatively, circumstances may change following the submission of a Modification Report, such that following detailed planning an earlier Implementation Date may be possible. BSC Section F2.11.7 currently contains provision for the Panel to seek extension to the Implementation Date. However, this provision only applies in the case of Approved Modifications (i.e. where the Authority has already made its decision).","This Modification proposes to enable the BSC Panel (after consultation with interested parties) to apply to the Authority to amend the proposed Implementation Date in Modification Reports that have been submitted to the Authority for determination, but where the Authority's decision has not yet been made.  ",null,"—",null,"−","Approve","Reject"]
["P92","Replacement Energy Contract Volume Notifications (ECVNs) And Metered Volume Reallocation Notifications (MVRNs)","BSC Panel","2002-07-08","A minor inconsistency appears in the two Sections of the Code (P 2.3.5 and P 3.3.5) in that on one interpretation it could be argued that a first notification must be \"in force\" before the second notification can replace it. The term \"in force\" is defined in Section P 1.3.2 and basically means effective.","This Modification proposes to amend Section P of the BSC to confirm that a second notification can replace or augment a first notification before the first notification becomes \"in force\".",null,"—",null,"2002-11-12","Approve","Approve"]
["P91","Extension To Data Provided To the Transmission Company In The TUoS Report","National Grid","2002-07-08","Increasingly, Suppliers are choosing to have more than one BM Unit within a GSP Group and want their TNUoS charges calculating down to this level of detail. Furthermore, where embedded generation has been netted off via the SVA system, this information is required to calculate the Use of System charges. The Modification was submitted previously as a Change Proposal but following internal assessment by ELEXON an impact on the Code was identified.","This Modification proposes to modify the TUoS Report provided to the Transmission Company only to include the split between half-hourly and non-half hourly metered data at a BM Unit level rather than being aggregated to a Supplier level.",null,"—",null,"2003-03-17","Approve","Approve"]
["P90","Improving The Representation Of Energy Balancing Actions In Cashout Prices. ","First Hydro Company","2002-07-08","Cashout prices are being polluted by trades taken to alleviate constraints. Additionally, trades that are currently tagged as system trades and yet have a net impact on the energy balance are not necessarily factored into imbalance cashout prices. Cashout prices are not therefore representative of the costs of energy balancing.","This Modification seeks to ensure that genuine system trades do not influence cashout prices and that trades that impact energy balance are better represented in imbalance cashout prices.  In addition, the proposed Modification seeks to simplify the calculation of cashout prices and to ensure consistency of approach for all Bid-Offer Acceptances and forward trades.",null,"—",null,"−","Reject","Reject"]
["P89","Clarification Of The Timescales For Submitting MEL/MIL Data To The BMRA","National Grid","2002-07-02","Currently the BSC extends BMRA data to beyond the BM window and hence beyond the remit of the BSC. Consider an example where a generator has sufficient notice of a need to shutdown in the following day and notifies this intent to the System Operator via a MEL update. Under the BSC this information would be released to the market before the participant could trade out of its position. If this were to occur, we believe that Participants may delay sending information to the System Operator. In addition, there would be the consequential cost for the changes to be made to NETA central systems, which we understand would be significant.","This proposal seeks to align the BSC with existing practices and systems with regard to the Maximum Export Limit/Maximum Import Limit (MEL/MIL) received by the National Grid Company.",null,"—",null,"2003-05-23","Approve","Approve"]
["P88","Introduction of obligations in relation to SVA Metering, Meter Operator Agents and Equipment Owners","SSE","2002-05-31","The aim of REMA has been to establish the distinct roles of Meter Asset Provision (MAP) and Meter Asset Maintenance (MAM), thereby promoting competition in these services. MAMs will be appointed by the Supplier and will be responsible for all fieldwork carried out on Metering Equipment, including installation, removal and repair, and will therefore be identical to Meter Operator Agents (MOAs) as currently defined in the BSC. From a BSC point of view a MAP/MAM split is largely invisible, as the method by which data is submitted into Settlement and the various obligations on Parties and Party Agents would remain the same. However, in order to support the solution described above (and to ensure that no risks are posed to Settlement through misinterpretation of roles), new obligations are proposed affecting the Meter Operator Agents.","This modification proposes to clarify the relevant sections of the BSC to support the changes proposed as a result of the Review of Electricity Metering Arrangements (REMA).",null,"—",null,"2003-05-29","Approve","Approve"]
["P87","Removal of market risk associated with operation of a Generator Inter-Trip Scheme","National Grid","2002-05-31","Description of Issue or Defect that Modification Proposal Seeks to Address (mandatory by proposer): When power stations connect to the transmission system an inter-trip scheme is often used as a way of maximising the utilisation of the transmission system. Whilst this reduces the impact of the transmission system on the electricity market and so contributes to the operation of an efficient, economic and co-ordinated transmission system, it requires a method of compensating participants when a scheme operates. Currently, where applicable under the Grid Code, this is achieved via a deemed bid acceptance. Should a participant wish to signal that they are unwilling to reduce output by entering a large negative bid, this creates the possibility of their receiving a “windfall gain” should the inter-trip operate. Such windfall gains would then be funded out of BSUoS charges levied on the rest of the industry and there is the potential to set an extreme, negative level of System Sell Price.","This modification proposes to remove problems associated with the current method of calculating compensation for a generation inter-trip scheme - namely the possibility of 'windfall gains' and the setting of extreme negative values of System Sell Price.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P86","Clarification of frequency and timing of data submission of Generating Plant Demand Margin and Surplus","National Grid","2002-05-31","National Grid already provides national Surplus information (although this is incorrectly labelled on the BMRA and prior to the implementation of P33 is referred to as national Indicated Margin in the BSC) to the BMRA on a Business Day basis and also on a weekly basis. The additional provision of the Generating Plant Demand Margin by National Grid to BSCCo will be introduced by the implementation of Modification Proposal P33. Under Modification Proposal P33 National Grid sought to rectify inconsistencies in terminology between the BSC and Grid Code OC2. National Grid intended that the frequency and timing of the files of both the Surplus and Generating Plant Demand Margin were consistent with the frequency and timing BSC requirement for national Indicated Margin prior to the implementation of P33.","This Modification proposes to clarify the BSC so that generic references to 'day' or 'daily' relating to the provision of both Generating Plant Demand Margin and the Surplus are replaced with references to Business Days.",null,"—",null,"2002-09-30","Approve","Approve"]
["P85","A Phased Implementation Scheme for changes to TLF in Section T of the code","British Energy","2002-05-31","British Energy has identified lack of stable signals for long-term investment, and the potential stranding of sunk costs, through a phasing adjustment to any change in TLF value envisaged under Section T of the BSC.","This modification proposes seeks to implement a phasing scheme in the event that the Transmission Loss Factor (TLF) value, currently set to 0 in Section T of the BSC, is changed to another value via modification to the Code.","—","—","—","—","—","—"]
["P84","Amendment To Process For Past Notification Errors (2)","Innogy plc","2002-05-22","The proposed Modification amends the period in P6.2.1 of the Code under which notice of claims for Past Notification Errors can be made, which was added to the Balancing and Settlement Code (“the Code”) by Modification Proposal P37 (P37). The Modification Report for P37 was sent to the Authority on 5 November 2001, and the Authority’s determination was published on 10 May 2002.","This modification proposes that, where the error in notification of a single energy volume contract affects a number of Volume Notifications and/or a number of contiguous Settlement Periods, all the relevant Past Notification Errors should be covered by a single claim and/or a single fee.",null,"Yes",null,"2002-05-29","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P83","Amendment To Process For Past Notification Errors (1)","Innogy plc","2002-05-22","The proposed Modification amends the period in P6.2.1 of the Code under which notice of claims for Past Notification Errors can be made, which was added to the Balancing and Settlement Code (“the Code”) by Modification Proposal P37 (P37). The Modification Report for P37 was sent to the Authority on 5 November 2001, and the Authority’s determination was published on 10 May 2002.","This modification proposes to extend the deadline for submission of claims under Modification P37 to ten business days after paragraph P6 of the BSC comes into effect.",null,"Yes",null,"2002-05-24","Approve","Approve"]
["P82","Introduction Of Zonal Transmission Losses On An Average Basis     ","First Hydro Company","2002-05-03","Currently the volume of transmission losses is allocated amongst BSC Parties regardless of the extent to which they give rise to them. To the extent that long term locational signals are to be introduced into the energy market, this Modification seeks to address this perceived defect. The Modification does not seek to introduce strong short term economic signals as it is felt that these would have a detrimental effect on overall efficiency.\n    ","It is proposed that the BSC be modified to give effect to a zonal differentiation in the allocation of the volume of transmission losses, similar to that set out for the Pool in 1997. For each GSP Group a single Transmission Loss Factor (TLF) would be derived ex ante for application to generation and supply throughout the coming year April to March. The manner in which these would be calculated would be under the governance of the BSC. In principle, nodal marginal TLFs would be derived for a representative collection of historic power system conditions during the previous year January to December. Zonal marginal TLFs would be derived from these nodal figures by demand-weighted averaging, and then annual zonal marginal TLFs would be derived by time-weighted averaging.   ",null,"—",null,"−","Reject Pro\nReject Alt","Approve Pro\nReject Alt"]
["P81","Removal Of The Requirement For Half Hourly Metering On Third Party Generators At Domestic Premises","TXU UK Ltd","2002-05-03","The current obligation would require the installation of half hourly metering at such premises which we believe imposes inappropriate costs on micro CHP plant and PV technologies.","The Modification proposal seeks to remove the obligation contained in Section L2.2.1(c) for half hourly metering to be installed at all premises with Third Party Generators if these are located at Domestic premises which have their Imports metered non half hourly.",null,"—",null,"2003-09-28","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P80","Deemed Bid/Offer Acceptance For Transmission System Faults","British Energy","2002-05-01","Where a BM Unit is forced to deviate from Physical Notification due to faults on the transmission system outside its control, the transmission company should be obligated to issue a deemed bid-offer acceptance reflecting the forced deviation, for as long as the situation continues. ","BSC Section Q5.1.5 already contains obligations in relation to the operation of intertrips, and section Q5 should be extended to include all other system faults outside the control of the BM Unit lead party. Corresponding changes to the Grid Code would need to be made. Concerns over lack of competition in bid/offer prices in the circumstances of system failure would be met through regulation or bilateral contracts with the Transmission Company.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P79","Revised Rules For Default Energy Imbalance Pricing","London Electricity Group","2002-04-12","The BSC energy imbalance price default rules should be amended so that they better facilitate the achievement of the Applicable BSC Objectives.  In particular an Offer, or Bid, should not be a candidate for setting the default System Buy or Sell Price respectively, unless there is some applicable volume which would be available to NGC if it had chosen to accept the Offer or Bid.  For example, in the case of an Offer from a producing BM Unit, if there is any separation between MEL and the FPN.  Also, whatever adjustment (addition or subtraction) to the relevant system price from BSAD data would have occurred had there been a valid calculation, should be made to the default price.","The Modification Proposal seeks to amend the rules for calculating default values of System Buy Price (SBP) and System Sell Price (SSP), in order to ensure that: − A Bid or Offer does not set the default price unless it has some available volume; and − Default prices include the Price Adjustment element of Balancing Services Adjustment Data (BSAD), in the same way as non-default prices.",null,"—",null,"−","Reject","Reject"]
["P78","Revised Definitions of System Buy Price and System Sell Price","National Grid","2002-04-05","The current definitions of SBP and SSP give rise to the following issues: · SBP remains unpredictable with a high mean and spread · The price of the shorter stack (the “reverse price”) can, at times, still be significantly affected by costs associated with system balancing actions · The resultant high levels of SBP are driving the market long · The defaulting rules were devised on the basis they would very rarely be called upon and it was therefore considered satisfactory that they should merely avoid setting extreme values. Currently the default rules are being used regularly and the resultant prices are significantly different from those produced by the “standard” rules.","P078 proposed definitions for System Buy Price (SBP) and System Sell Price (SSP).",null,"—",null,"2003-02-25","Reject Pro\nApprove Alt","Approve Pro\nReject Alt"]
["P77","Interconnector Multiple BM Units","SSE","2002-04-05","At present each User of an Interconnector is limited to the use of 2 BM Units (one Consumption and one Production).","It is proposed that this limit is raised to allow a User to apply for up to an additional 2 pairs of BM Units on each Interconnector that it is a User.",null,"—",null,"−","Approve","Reject"]
["P76","Anomalies Associated With Negative Quantities Of Credit Cover","British Gas","2002-04-08","At present Section M2.1.3 of the Code defines the amount of a Trading Party's Credit Cover at any time as: (a) the sum of the maximum undrawn amount for the time being of any Letter of Credit delivered by it, and the principal amount of any cash paid by it and credited to the Reserve Account by the FAA on behalf of the BSC Clearer less (b) the sum of any amounts payable by the Trading Party in respect of Trading Charges which have become due for payment and have not been paid by the Trading Party on the relevant Payments Date in accordance with Section N, and remain unpaid at such time. Therefore if a Trading Party fails to pay any Trading Charges on the relevant Payment Date, the amount of non payment is deducted from the current level of Credit Cover by the Funds Administration Agent (FAA) and details of the new Credit Credit are sent to the Energy Contract Volume Aggregation Agent (ECVAA) for inclusion in the credit checking process. However if the amount of non payment is greater than the current Energy Credit Cover, then the result will be a negative Energy Credit Cover. This will distort the effect of the credit checking calculations.","This proposal seeks to address anomalies that arise in the Credit Cover calculation when unpaid Trading Charges cause a Party's Credit Cover to become negative.",null,"—",null,"2002-10-22","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P75","Introduction Of Zonal Transmission Losses","Powergen","2002-04-05","Currently under Section T2 of the BSC, Transmission Loss Factors (TLFij) for all BMUs in all settlement periods are set to zero.","The modification proposes that transmission losses are allocated on a zonal rather than on a uniform system wide basis. ",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P74","Single Cost-reflective Cash-out Price","Electricity Direct","2002-04-04","Where Total System Energy Imbalance Volume (TQEIj) is positive then all Account Energy Imbalances will be settled at the prevailing System Sell Price. Where Total System Energy Imbalance is negative then all Account Energy Imbalances will be settled at the prevailing System Buy Price. In the unlikely event that Total System Energy Imbalance Volume is zero, then the default Settlement Price will be the arithmetic mean System Buy Price and System Sell Price.","The Proposal seeks to amend the application of Energy Imbalance Prices, such that where the Total System Energy Imbalance Volume for a Settlement Period is: - Negative, then the Imbalance volumes on all Energy Accounts are to be cashed out at the System Buy Price (SBP); - Positive, then the imbalance volumes on all Energy Accounts are to be cashed out at the System Sell Price (SSP); - Zero, then the imbalance volumes on all Energy Accounts are to be cashed out at a default Energy Imbalance Price, which will be the arithmetic mean of the System Buy Price and System Sell Price. At a high level, the Modification Proposal asserts that the intent of such an amendment to the Energy Imbalance Price application is to mitigate distortion of the market caused by the current dual cash-out arrangements, which are not cost reflective, and are unduly penal to Parties with unpredictable output and / or small portfolios.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P73","Addition To Data Required From Transmission Company When Submitting A Claim For Manifest Error","Powergen","2002-04-05","When the Transmission Company submits a claim for Manifest Error to the BSCCo, under Clause Q 7.2.2 it is required to identify the Erroneous Bid Offer Pair(s).  ","It is proposed that in addition, it should also identify the erroneous Bid/Offer Acceptance which led to the erroneous Bid/Offer Pairs.    ",null,"—",null,"2002-11-05","Approve","Approve"]
["P72","Correction Of A Minor Inconsistency In The BSC Arbitrage And Trade Tagging Methodology ","BSC Panel","2002-03-14","Under the current BSC, any trade tagging of Offers would take place sequentially, based on the ranking of Offers. If several accepted Offers had the same price as each other and if the Transmission Loss Multipliers (TLMs) assigned to the Balancing Mechanism Units (BMUs) submitting these Offers were different, then the System Buy Price would, in general, be sensitive to the result of the random ordering of such Offers. In particular, the SBP could change randomly between settlement runs. The materiality of the issue is potentially large but, in practice, has been small.","The Modification Proposal seeks to correct a minor inconsistency in the BSC Arbitrage and Trade Tagging Methodology and to bring the BSC in line with the current software implementation within Central Systems. The proposal is to amend the BSC so that if several Offers (or Bids) have the same price as each other and one of them is in line for arbitrage or trade tagging according to the ranking of accepted Offers (or Bids), then each equally priced Offer (or Bid) will be tagged in proportion to its accepted volume.",null,"—",null,"2002-07-12","Approve","Approve"]
["P71","Transfer of imbalances caused by Balancing Services to the Transmission Company Energy Account","National Grid","2002-03-04","Certain Balancing Services, required by the System Operator for economic operation of the Transmission System (notably Response and Standing Reserve) and the testing of other Balancing Service (such as Black Start), result in the provider’s energy account (or their supplier’s) being exposed to imbalance charges. Imbalance charges are designed to reflect the cost of being out of balance. To the extent that the imbalance is as a result of delivering balancing services, it is inappropriate to charge imbalance prices to parties that have assisted in system balancing. Risk of exposure to high imbalance charges is making service providers (in particular, smaller demand side providers) reluctant to provide services, and some services are being withdrawn. The loss of these services will result in the Transmission Company having to use more expensive service providers; this will increase the overall cost of system balancing, and potentially reduce system security. The Transmission Company’s energy account is not exposed to imbalance charges, and this is appropriate for services that assist in the balancing of the system.","To modify the calculation of Credited Energy Volume (QCEiaj) such that the imbalance caused by the delivery of Balancing (Ancillary) Services is transferred from the provider's energy account to the Transmission Company's energy account.",null,"Yes",null,"2003-02-25","Reject","Approve"]
["P70","CMRS Metering For Inter-DNO Boundaries Within A GSP Group","SEEBOARD","2002-03-01","The metering arrangements at Distribution System Connection Point (DSCP) (i.e. the boundary between two distribution networks) within the same GSP Group should be considered and treated in an exactly similar manner to the metering arrangements at a DSCP coincident with the boundary of two GSP Groups except for the sending of data into settlements SAA.","P70 [RD/3] was raised by SEEBOARD on 1 March 2002, such that if a meter is installed between two Distribution Systems, within the same GSP Group, it should be allowed to be registered in CMRS and for data to be collected using the Central Data Collection Agent (CDCA).",null,"—",null,"−","Approve","Reject"]
["P69","Short-Term Measures To Alleviate The Inefficiencies Within The Present Credit Energy Indebtedness Methodology","TotalFinaElf Gas and Power Ltd","2002-02-19","The current methodology for assessing credit energy indebtedness is widely regarded as over-estimating the indebtedness of certain parties and potentially obliging them to post unwarrantedly high levels of credit cover. Indeed, this was certainly a view endorsed by Ofgem in its decision letter on P2, Revision of the Methodology for Assessing Credit Indebtedness, where they indicate that Parties may have to provide up to £170 million of unwarranted credit cover at an estimated cost per annum of £1.7 million.","This modification proposal seeks to extend the scope of material doubt within Section M3.4 such that ELEXON shall; \n\n(i) on receiving evidence from a BSC trading party that indicates based upon the latest available data, it's actual and calculated energy indebtedness has not placed the party in 'actual' credit default, and  \n\n(ii) based upon this data, be in a position to, conclude that material doubt exists regarding the energy indebtedness, as calculated under the current methodology, of the BSC Party, and thus \n\n (iii) withhold the necessary authorisation to the ECVAA for pursuing level one and level two credit default procedures.  \n","—","Yes","—","—","—","—"]
["P68","Modification to the BSC relating to the setting of Supplier Caps for use in the Supplier Charges (Liquidated Damages) calculation","BSC Panel","2002-02-14","The manner in which the Supplier Volume Allocation Agent (SVAA) can lead to a Supplier having negative 'Deemed Take'. 'Deemed Take' is used for the purpose of setting Supplier Grid Supply Point (GSP) Group caps for calculating Supplier Charges (Liquidated Damages). A negative 'Deemed Take' leads to a negative GSP Group Cap that would, mathematically, reward a Supplier for under-performance. This is the direct opposite of the principle behind LDs.\n\n","The objective of the proposed Modification is to formulate an appropriate means of apportioning the GSP Group Cap across Suppliers in accordance with their size.",null,"—",null,"2002-11-01","Approve","Approve"]
["P67","Facilitation of further consolidation options for Licence Exempt Generators (DTI Consolidation Working Group ‘Option 4’)","Powergen UK","2002-01-22","The Consolidation Working Group (CWG) has presented its interim report to the DTI. This states as its main finding that “the principle obstacle to consolidation is the inability to sell fixed volumes without becoming a Party to the BSC”. Whilst fixed volume trades may be accommodated by the use of MVRNs, some participants feel that option 4 would give more control to the Licence Exempt Generator. Option 4 was discussed extensively with various industry groups in the design phase of NETA and was endorsed in the Ofgem/DTI Conclusions Document on NETA, published in October 1999. Following publication of this document, the Special Experts Group (SpEG) further developed Option 4. However, because of time constraints imposed in the run up to the NETA Go Live, the proposed trading arrangement was not implemented.\n","This Modification Proposal proposes changes to the Code and the related Code Subsidiary Documents so that consolidation method 'Option 4', as outlined in the Interim Report to the DTI of the Consolidation Working Group, can be incorporated into the BSC. The modification provides an additional mechanism to allow the output of an Exemptable Generating Plant to be split into a fixed amount of energy and an unpredictable variable amount of energy.",null,"Yes",null,"2002-03-08","Approve","Approve"]
["P66"," ECVNAs and MVRNAs To Receive ECVAA Forward Contract Report","TXU UK Ltd","2002-01-18","Energy Contract Volume Notification Agents ad Meter Volume Reallocation Agents should receive an appropriate version of the Forward Notification Summary. ","This Proposal follows P17, which was rejected by the Authority due to the lack of appropriate allocation of Balancing and Settlement charges. Unlike BSC Parties, Party Agents such as ECVNAs and MVRNAs do not contribute to the costs of Balancing and Settlement, and so under P17 would have been receiving additional reports without contributing to the necessary development and operational costs.",null,"—",null,"−","Reject","Reject"]
["P65","Amendment To The Requirement For A Mod Proposer’s Representative To Attend The Relevant Panel Meeting In Certain Circumstances","TXU Europe Energy Trading Ltd","2002-01-14","As currently drafted F2.2.2 requires the proposer’s representative to attend the Panel meeting at which the Mod proposal is first presented irrespective of whether the Panel wish to discuss the Mod with the Proposer or not.","It is proposed that the Proposer's attendance is only mandatory on the prior request of the Panel. For the avoidance of doubt the proposers representative may attend the relevant meeting and the discretion of the Panel to invite the Proposer's representative to speak would be unaffected.","—","—","—","—","—","—"]
["P64","Reduction of GC values to Zero during a BSC Season","TXU Europe Energy Trading Ltd","2002-01-14","Section K3.4 does not allow a Trading Party to reduce the value of GC to zero within a BSC Season. NGC’s Use of System Charges are based on the values of GC applicable between April and February. The BSC Spring season is defined as 1st March to 31st May. The consequence of this is that in order to have a a zero value of GC for Transmission Network Use of System charging purposes it is necessary to notify the GC as being zero with effect from 1st March. The notification has to be done 10 Business Days before the effective date (14th Feb 2002 for this year). The consequence of the above is that in order not to breach the Code, the BM Unit is precluded from generating for a month.","The Modification would facilitate the reduction of Generation Capacity - GC - to zero within a BSC Season.","—","—","—","—","—","—"]
["P63","Change Of Contract Management of MPAN's For Data Collector, Data Aggregator And Meter Operator. ","British Gas","2002-01-06","The BSC does not support a supplier if they wished to change Party Agent; for example, if 2 million customers needed to be switched to a more cost efficient DC in bulk. Under current agreed data flow caps it would take approximately 6 months to manage effectively all data transfers once migrated. The main IT systems at ELEXON would not be able to cope with the increase in data flow transfer from additional suppliers wishing to pursue this option as currently only British Gas are carrying out the change o f Party Agent. ","P063 proposed that an alternative method be discovered for dealing with the change of Party Agent.   ",null,"—",null,"2003-02-18","Approve","Approve"]
["P62","Changes to Facilitate Competitive Supply On The Networks Of New Licensed Distributors","TXU UK Ltd","2002-01-03","The Utilities Act 2000 enables organisations other than PDSOs to become licensed Distributors. New Licensed Distributors will not be subject to the same BSC obligations as PDSOs, and this will hinder competition in supply for customers on their networks. \n\n","P062 proposed to amend the BSC to extend the benefits of competitive Supply to customers on the networks of all Licensed Distributors.",null,"—",null,"2003-08-01","Approve","Approve"]
["P61","Ad Hoc Adjustments to Settlement involving material errors without resorting to Ad Hoc Settlement Runs","Scottish Power","2001-12-31","The potential for using costly and inefficient multiple Ad Hoc Settlement Runs as the means to adjust Settlement after the resolution of a Trading Dispute involving a material error. ","P061 seek to make amendments to the current wording of the BSC to ensure that a Trading Party has access to an appropriate form of redress in order to correct a material Settlement error without resorting to an Ad Hoc Settlement Run.",null,"—",null,"2002-12-10","Approve","Approve"]
["P60","Amendment To Obligation To Register Metering Systems In Relation To Trade Sales","British Gas","2001-12-05","Section K, paragraph 7.6.2 is in conflict with the relevant BSC objectives. ","A proposal to amend the BSC following a Trade Sale to a single Replacement Supplier to relieve a single Replacement Supplier from being obliged to re-register Metering Systems, re-appoint and re-register Party Agents for the failing Suppliers assets, with in 3 months. This change will ensure that the stability and integrity of the SVA Trading Arrangements and Settlement data is maintained and is not unnecessarily undermined in a detrimental way.     ",null,"—",null,"2002-04-11","Approve","Approve"]
["P59","The acceptance of Bids and Offers to honour a BM Unit’s dynamic parameters beyond the Balancing Mechanism window","Innogy plc","2001-12-03","\"The Wall” is the name given to the period at the end of the Balancing Mechanism window, beyond which National Grid cannot issue Bid Offer Acceptances. Therefore any individual Bid Offer Acceptance that the System Operator issues can only honour a plant's dynamics (for example minimum zero time) up to \"the wall\". To date, the System Operator has been issuing multiple bid offer acceptances (subject to limitations) to honour a plant's dynamics beyond the initial wall. As this practice is not codified in the BSC, it has been handled as a “gentlemen’s agreement”. The System Operator is not obliged to return a Unit to its PN beyond “the Wall” in accordance with its dynamic parameters. BSC parties are therefore are discouraged from participating on the BM due to the risk of being left out of balance beyond “the wall”.","To codify in the BSC the \"gentleman's agreement\" between the System operator and BM participants regarding the acceptance of Bids and Offers \"beyond the wall\" to honour a BM Unit's dynamic parameters.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P58","Disapplication of Volume Notifications Relating to a Defaulting Party","Dynegy","2001-12-03","Sections H3.2.2 (a) and (b) allow the BSC Panel, on the occurrence of a Default, to disapply Energy Contract Volume Notifications or Metered Volume Reallocation Notifications that were submitted prior to the time that the Panel notified the Defaulting Party of its Default. However in certain circumstances there may be a time delay between the Panel notifying the Defaulting Party of the Default and the determination being made that this clause should be implemented.","This Modification Proposal is being raised to allow the Panel to determine that when a Default has occurred in accordance with Section H of the Code, Volume Notifications can be disapplied from such time (not to be effective in respect of Settlement Periods for which Gate Closure has taken place prior to the notice of disapplication) as the Panel so determines, on or after the Default occurring.",null,"Yes",null,"2001-12-04","Approve","Approve"]
["P57","Amendment To BSC Failing Supplier Process To Allow A Legal Entity To Have Two Party Ids For A Short Period","British Gas","2001-12-03","The current rules prevent a party from having more than one id. However, current issues surrounding the future of BSC signatories and the protection of customers following the termination or sale of a party have identified that there are circumstances where the ability to run two ids for a temporary period would be beneficial.","P057 proposed amendment the BSC to allow a party to have more than one BSC id for a short period in exceptional circumstances (ie. Supplier of Last Resort provisions, termination of User etc.) The period of 3 months is suggested to match in with the current timeframes for meeting BSC requirements in respect of metering arrangements.",null,"Yes",null,"−","Reject","Reject"]
["P56","Proposed Modification to the BSC in order to reflect amended references in The National Grid Company plc’s Transmission Licence.","National Grid","2001-12-03","Current references in the BSC to the numbering of specific provisions of National Grid’s transmission licence which need to be updated to match the revised numbering in the licence.","The Balancing and Settlement Code (“BSC”) contains numerous references to specific conditions contained within the “Transmission Licence” (as defined in the BSC). The purpose of this Modification is to amend the numbering of all those references within the BSC to specific provisions of National Grid’s transmission licence to match the revised numbering in the licence.",null,"—",null,"2002-03-18","Approve","Approve"]
["P55","BSC conflicts with consolidation of Embedded Generation in Central Volume Allocation","Smartest Energy","2001-11-30","This modification seeks to address the incompatibility in the BSC Section K Para 2.1.2, which requires that a metering system may be registered in CMRS provided that no associated metering system exists in SMRS, and the concept of a consolidator under NETA. The consolidator does not necessarily have a contract with the customer for the Supply of energy to a site, and does not necessarily have a Supply Licence to provide such energy in any case. In some circumstances the site may form part of a group supply contract and it is likely that the supplier will require the Import Metering system to remain in SMRS.","It is proposed that Sections K & J of the BSC are modified to allow, where a technical solution exists, consolidators to register the Export Metering on Embedded Generation Sites in Central Volume Allocation whilst allowing the Import to remain in Supplier Volume Allocation.  ",null,"—",null,"2002-06-06","Reject Pro\nReject Alt","Approve Pro\nReject Alt"]
["P54","Ability To Hold Short Notice BSC Panel Meetings","National Grid","2001-11-29","Currently, the Panel is unable to respond within 24 hours to major events that impact upon the electricity market. This may prevent the Panel from taking timely action in event of an emergency.","Proposes that the notice period required to hold a BSC Panel Meeting is reduced from 24 hours to 1 hour at the discretion of the BSC Panel Chairman.",null,"Yes",null,"2001-11-30","Approve","Approve"]
["P53","Changes to DC, GC and CALF and the Effect on Energy Indebtedness","BSC Panel","2001-11-16","The existing functionality of the Energy Contract Volume Aggregation Agent (ECVAA) does not enable application of revised values of BM Unit Credit Assessment Export Capability and BM Unit Credit Assessment Import Capability for a BM Unit in Energy Indebted ness calculations in the manner required by the Code, Section M 1.2.4.","It is proposed that the Code is modified to align it with the BSC System functionality, to remove the requirement for the change to BM Unit Credit Assessment Export and Import Capability to be applied in Energy Indebtedness calculations as if it were effective from the first 29 days.\n",null,"—",null,"2002-07-18","Approve","Approve"]
["P52","Non-Party Access to the BMRS via the High Grade Service","SEEBOARD","2001-11-14","Currently, the Balancing and Settlement Code (BSC) does not allow non Parties access to the High Grade Service and, even if it did, it does not contain provisions that would allow ELEXON to charge for the service. In addition, ELEXON has indicated that one non Party already has access to the High Grade Service and other non Parties have indicated an interest in obtaining one.","Proposes to allow non-Parties access to the High Grade Service, and to charge them for the service in accordance with the arrangements for Parties that are currently specified in Annex D3 3.1 d and e, and 3.4, of the BSC.  Also, to put in place arrangements to allow ELEXON to recover the charges for the service that has been provided to one non Party.",null,"—",null,"2002-05-31","Approve Pro\nReject Alt","Approve Pro\nReject Alt"]
["P51","Distribution Of BSC Data To All BSC And Non BSC Parties ","UK Coal Mining Ltd","2001-11-08","The need to place everyone concerned with the electricity market on an equal footing by making BSC information available to both BSC and non BSC parties, thus promoting more effective competition in the energy market.","To make available BSC data to all BSC and non BSC parties.","—","—","—","—","—"]
["P50","Distribution Of BM Aggregation Report Data To Non BSC Parties ","UK Coal Mining Ltd","2001-11-08","Lack of transparency since the introduction of NETA. This information was available under the Pool trading arrangements.","To make available BM Aggregation Report Data to non BSC parties, (or the data behind it). This proposal formed part of Modification P30 but was dropped because of the cost estimates.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P49","Timing Of Publication Of Indicative P18 Option A Prices On The B.M.R.S","BSC Panel","2001-10-31","On 22 August 2001, the Authority agreed the implementation of Modification Proposal P18 Option A (P18A) with a legal effective date of 25 September 2001. During the discussions at their meeting of 12 July 2001, the Panel recognised the definition of Continuous Acceptance Duration Limit within the P18A Modification introduced a delay to the calculation of Indicative Imbalance System Prices and their subsequent publication on the BMRS. Whilst the legal drafting of the P18A Modification reflected the relevant definition of the CADL parameter an inconsistency arose during the drafting procedure. The legal text submitted to the Authority on behalf of the Panel omitted a change required to the defined timescales for reporting information relating to a Settlement Period, as defined in Section V 2.3.3 of the BSC.","This proposal seeks to address an anomaly within the Authorised P18A Legal Drafting.  It seeks to formally record the delay to the publication of prices on the Balancing Mechanism Reporting Service (BMRS) by an additional 30 minutes to reflect the maximum length of time of the Continuous Acceptance Duration Parameter (CADL).",null,"—",null,"2002-03-27","Approve","Approve"]
["P48","Half Hourly Receipt And Publication Of BSAD Data ","National Grid","2001-11-01","The BSC currently states that the Balancing Services Adjustment Data (BSAD) shall be sent to the BMRA by the Transmission Company not later than 17:00 hours at the day-ahead stage with a post-event update. ","This modification proposes that an update to the BSAD data be sent by the Transmission Company as soon as possible after Gate Closure to allow the most up to date data to be published on the BMRS.",null,"—",null,"2002-04-02","Approve","Approve"]
["P47","Termination Process for ECVAA and MVRNA Authorisations","BSC Panel","2001-10-24","The Code states that the termination is effective when given in accordance with BSCP71 and received by the Energy Contract Volume Allocation Agent (ECVAA). BSCP71 and the ECVAA User Requirement Specification (URS) state that the Authorisation termination notification becomes effective one calendar day after receipt by the ECVAA.","It is proposed that the Code is modified to align it with the BSCP71 and ECVAA URS so that the Authorisation termination notification becomes effective one calendar day after receipt by the ECVAA ; not  effective when received by the ECVAA.\n",null,"—",null,"−","Reject","Reject"]
["P46","Housekeeping Modification","BSC Panel","2001-10-23","A number of minor inefficiencies, inconsistencies and typographical errors have been identified within the BSC.","Rectification of minor inconsistencies and errors within the BSC.",null,"—",null,"2002-05-20","Approve","Approve"]
["P45","Introduction of Price Adjusters for Settlement Days 5 April 2001 to 24 September 2001 inclusive","BSC Panel","2001-10-19","The BSC would need to be changed so that the changes implemented to the BSC for Modification Proposal P08 which apply Settlement Day 25 September 2001 are applied to all future Settlement Runs for historic Settlement Days 5 April 2001 to 24 September 2001 inclusive.","Proposes to implement Price Adjusters to reflect reserve option fees for System Sell Price (SSP) and System Buy Price (SBP) for Settlement Days from 5 April 2001 to 24 September 2001 inclusive. This will, in effect, retrospectively implement the calculation for Modification Proposal P08 for these Settlement Dates.",null,"—",null,"2002-03-27","Approve","Approve"]
["P44","Correction of Notification Errors where Parties are able to satisfy a Reasonable and Prudent Operator test","Powergen","2001-10-08","Notifications submitted before 18:30 of the day before their ‘effective from’ date will be ‘echoed back’ to both affected trading parties on the E0221 Forward Contract Report (7 Day Report). Both counter-parties can validate the notifications on the report against their internal trade database to confirm that the notification creation and despatch process has worked correctly. In the same way, day-ahead notifications that transfer of energy between production and consumption accounts or between parties within an affiliated group can be validated by at least one of the parties in the group. Unfortunately, no such facility is available for notifications that have to be submitted after 18:30 of the day before their ‘effective from’ date. The ECVNA will receive an ‘ACK’ (acknowledgement) to say that the notification was capable of validation by the ECVAA, and if nothing more is heard can assume that the notification has been loaded. The non-notifying party (or parties if a 3rd party ECVNA is being used) hears nothing. Non of the parties involved can be sure that the notification process has been successfully completed. It is not just the adjustment to the position that is put at risk. Many parties use over-write methodologies to notify both net traded positions with counter-parties and internal transfers. The introduction of a minor error into the notification creation process (e.g. multiplication by minus 1) can have a major impact on the final notified position of a party, even if the new information that was meant to be notified was a small quantity.","It seeks to modify the Code so that Parties will be able to apply to the Panel requesting the ex post creation of new ECVNs / MVRNs or\namendment of a previously submitted ECVN / MVRN.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P43","Provision of Annualised Advance (AA) and Estimated Annual Consumption (EAC) Data","Western Power Distribution","2001-10-01","Following separation of Supply and Distribution Businesses, the PDSO no longer has access to AA and EAC data. The PDSO requires an accurate forecast of consumption to enable it to calculate loading on its network and the AA and EAC has been used to determine the forecast demand.","Seeks to update the BSC to clarify that Annualised Advance (AA) and Estimated Annual Consumption (EAC) data should be sent by the Non Half Hourly Data Collector (NHHDC) to both the relevant Supplier and the relevant Public Distribution System Operator (PDSO).",null,"—",null,"−","Reject","Reject"]
["P42","Allow Appointment Of different  HHDCs For Import & Export Meters","Utility Link Ltd.","2001-09-27","Presently the BSC and associated BSCP state that the the same MOP & DC must be appointed by both Suppliers where the MPANs are jointly metered using different channels via the same meter. While this is important with regard to the Meter Operator, There is no technical reason why this should apply to HHDCs. Utility Link has spoken to HH data collectors who agree this is the case, and the only possibility is that both HHDCs may try to poll the site at the same time. However, most collection systems would redial the site at a later time if it failed at first attempt. The present constraint, means that any Supplier wishing to purchase the export from a site, must find out who the HHDC of the importing Supplier is (Which is not easily done, and almost impossible in the timescales for registration) and appoint them as their HHDC, possibly having to enter a contract on disadvantageous terms as the Supplier has no choice.","The proposal is to allow the appointment of a different HHDC by a Supplier to collect HH data from the export channels, where a meter has two MPANs attached one for import & one for export and a different Supplier has the import MPAN than that that has registered the Export meter.","—","—","—","—","—"]
["P41","Allocation Of individual NHH MPANs To different BM Units","Utility Link Ltd.","2001-09-27","Currently the BSC allows parties to allocate HH MPANs where they are the registered Supplier, to a BM unit other than their default BM unit in the appropriate GSP Group. However, in the NHH market it is only possible to allocate a PC/SSC combination to another BM unit, thus making it impossible to group specific MPANs into a specific BM unit for the purposes of allocating against a specific contract or for re-allocation to another BSC party.","The Proposed Modification is to allow NHH MPANs to be allocated to specific BM units on a MPAN by MPAN basis as is the case with HH MPANs",null,"—",null,"−","Reject","Reject"]
["P40","Calculation of Negative Estimates of Annual Consumption (EAC)","SEEBOARD","2001-09-25","ELEXON developed EAC/AA calculator allows a negative Estimate of Annual Consumption (EAC) to be calculated. A negative Annualised Advance (AA) may arise as a result of an erroneously large previous AA value or as a result of failure to detect a meter-rollover. In the former case, the erroneously large AA and negative AA will cancel out, in as much as overall metered volume over the two meter advance periods will be correct, albeit that profiled demand values will be inaccurate. In the latter case, no such compensation will take place. In either of these cases, a negative AA may (depending on its magnitude, the meter advance period and the value of Previous Estimated Annual Consumption (PEAC)) result in a negative EAC. Current value of Smoothing Parameter (SPAR) is set at 2. Any negative AA where the sum of Daily Profile Coefficients for the associated meter advance period is 0.5 or more will lead to a negative EAC. A negative EAC is counter-intuitive. It can only arise from an erroneously calculated AA value and estimating future demand as negative merely compounds the original error. Where, within the Settlement window, a negative EAC is not replaced by an AA, a Supplier would receive a credit from a PDSO for using its distribution network rather than a charge. ","Amendments to calculation of EACKR in BSC Annex S-2 paragraph 4.3.7.  This will introduce an extension to this calculation to remove the ability for EACKR to be calculated as a negative value.  Negative EACs are logically inconsistent and should be replaced by a more appropriate value. ",null,"—",null,"−","Reject","Reject"]
["P39","Improvements To The Administration Of The Payment Default Process","BSC Panel","2001-09-20","The BSC Panel raised Modification Proposal P39, on the recommendation of the BSCCo, on 20 September 2001. This was raised in accordance with Section F2.1.1 (d) of the Code, on the basis that the proposal would better facilitate achievement of the objective in Condition C3 (3) (d) of the Transmission Licence, i.e. promoting efficiency in the implementation and administration of the balancing and settlement arrangements.","The proposal aims to remove inconsistencies between operating practices and the payment default procedures documented in the Code.",null,"—",null,"2002-08-12","Approve","Approve"]
["P38","Redefined Definition Of  C A D To Allow Prompt Price Reporting","Slough Energy Supplies Limited","2001-09-19","Modification 18A has a detrimental impact on BM reporting timescales.","A proposal to redefine the definition of CAD such that any CAD that starts less than CADL (currently 15) minutes before the end of the settlement period should automatically be tagged and excluded from imbalance settlement price calculations for that settlement period (but, for the avoidance of doubt, can be counted within the next settlement period if appropriate).  ",null,"—",null,"−","Reject","Reject"]
["P37","To provide for the remedy of past errors in Energy Contract Volume Notifications and in Metered Volume Reallocation Notifications","London Electricity plc","2001-09-11","Past notification errors in Energy Contract Volume Notifications and in Metered Volume Reallocation Notifications.","Enable past (but not future) errors in Energy Contract Volume Notifications and Metered Volume Reallocation Notifications to be remedied on an ex-post basis.",null,"Yes",null,"2002-05-17","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P36","The generation of Bid-Offer Acceptances relating to energy delivered as a result of providing Applicable Balancing Services","Innogy plc","2001-09-10","The provision of certain Balancing Services results in imbalance exposure to providers. To the extent that imbalance is as a result of delivering Applicable Balancing Services, it is inappropriate to charge imbalance prices to parties that have assisted in system balancing. Furthermore, the energy delivered as a result of providing Applicable Balancing Services should be valued on the same basis as other energy deliveries associated with Bid-Offer Acceptances. Current Ancillary Services Payments do not provide adequate incentive to deliver the contracted levels of these Services since delivery does not reduce imbalance exposure. This proposal would have the added incentive for correct delivery by exposing non-delivering parties to imbalance and to non-delivery charges.","For BM Units instructed to provide Applicable Balancing Services the Transmission Company will calculate the expected delivered energy volume for each minute in which the Service is instructed based on an agreed methodology. The methodology could be incorporated within the code, or appended as a subsidiary document albeit still part of the code. Once such volume has been calculated, the Transmission Company will submit Bid-Offer Acceptance data to the SAA in the form described in T3.1.2 of the BSC. Thus, the calculated volume of energy delivered as a result of providing the services in any minute shall be included in the calculation of the Period BM Unit Total Accepted Offer Volume (QAOn ij) and the Period BM Unit Total Accepted Bid Volume (QABn ij). The definition of Applicable Balancing Services would need to be included within the code and would specify those services to which this process would apply. The definition should be developed as part of the modification process. As a minimum it should apply to the Mandatory Ancillary Service of Frequency Response, but it is for consideration as to whether it should extend to other specified services.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P35","Qualified ECVNAs","APX","2001-09-05","A number of reasons have been cited for the lack of liquidity in the short term markets and they include: inadequate reporting from central systems of notified contracts, the length of Gate Closure, and the inability to undertake dual contract notification.","The BSC should be changed to recognise the status of appropriately \"Qualified ECVNAs\" such that any contract notifications held by them at Gate Closure are considered to be firm Settlement Data for the purposes of imbalance settlement, irrespective of whether such contract notifications are received by the ECVAA prior to Gate Closure.",null,"—",null,"−","Approve","Reject"]
["P34","Transfer of imbalances caused by Balancing Services to the Transmission Company Energy Account","National Grid","2001-08-14","Certain Balancing Services, required by the System Operator for economic operation of the Transmission System (notably Response and Standing Reserve) and the testing of other Balancing Service (such as Black Start), result in the provider’s energy account (or their supplier’s) being exposed to imbalance charges. Imbalance charges are designed to reflect the cost of being out of balance. To the extent that the imbalance is as a result of delivering balancing services, it is inappropriate to charge imbalance prices to parties that have assisted in system balancing. Risk of exposure to high imbalance charges is making service providers (in particular, smaller demand side providers) reluctant to provide services, and some services are being withdrawn. The loss of these services will result in the Transmission Company having to use more expensive service providers; this will increase the overall cost of system balancing, and potentially reduce system security. The Transmission Company’s energy account is not exposed to imbalance charges, and this is appropriate for services that assist in the balancing of the system.","A proposal to modify the calculation of Credited Energy Volume (QCEiaj) such that the imbalance caused by the delivery of Balancing (Ancillary) Services is transferred from the provider's energy account to the Transmission Company's energy account.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P33","Rectification of inconsistencies in terminology between the BSC and Grid Code OC2","National Grid","2001-08-10","National Grid has recently identified that it has been inadvertently providing an incorrectly labelled data item to the BMRS forecast pages, due to inconsistencies in terminology between Grid Code OC2 data and the requirements of the BSC.  This is compounded by nomenclature differences between the BSC and the BMRS Forecast and Help pages.  This proposal seeks to resolve all these issues, and remove any potential misunderstanding by the provision of an additional data item on the BMRS.","This proposal seeks to resolve all these issues, and remove any potential misunderstanding by the provision of an additional data item on the BMRS.",null,"—",null,"2002-09-30","Approve","Approve"]
["P32","Limited Redefinition Of B M Units","AES Fifoots Point Ltd","2001-07-17","Where a Power Station comprises several generating units of similar type then the Lead Party should be entitled to aggregate the meters into a single BM Unit for purposes of Physical Notification unless the Transmission Company notifies that the proposed aggregation prejudices system operation.","—","—","—","—","—","—"]
["P31","Waiving Of Charges Under Annex D3  For Parties Who Are Setting Up Their Operations During The Commissioning Periods With Effect From 27 March 2001","Greenwich Energy Trading Limited","2001-07-16","Currently the Balancing and Settlement Code or \"BSC\" requires that parties to pay charges, irrespective as to whether they are trading or not (whether they are commissioning their systems to commence trading or not.) Although parties are (in theory) supposed to know the BSC back-to-front, that is not necessarily the case for all parties; specially new entrants who are faced not only with the issues of a complex business sector but also with the added problem of continuing changes.","That with effect from 27 March 2001 (i.e. retrospectively) that the charges under Annex D-3 (section 3.1) be suspended for new entrants to the electricity market who are commissioning their infrastructure with a view to supply (or otherwise trade) in electricity in the England and Wales market during such commissioning stages until such time as they commence trading.","—","—","—","—","—"]
["P30","Availability Of Market Information To B.S.C. Parties And Non-B.S.C. Parties","Utilyx","2001-07-12","In the half-hourly market, line loss factors are an essential component in the conversion of an Energy Price on the Grid into a delivered price at a customers premises. At present energy buyers and agents on their behalf are required to obtain line loss factors (part of the DMDD) from distribution businesses individually; the process is extraordinarily wasteful and time consuming. In the non half-hourly market, energy prices are based on the predicted consumption based on load profiles, which vary geographically and between different types of customers. Information on load profiles, also part of the MDD, is therefore essential for suppliers and buyers in accurately comparing market price quotations. In both these circumstances, the full availability of MDD is crucial to the promotion of effective competition in the energy market. In addition release of this data to buyers should improve the efficiency of the system and lead to a better understanding of demand patterns amongst buyers. In a different area of the market, information on Genset Meters Generation is important for upstream and downstream market players in providing additional market transparency and improved planning.","It is proposed that Market Domain Data and information on Genset metered generation be fully available, subject to reasonable commercial safeguards, to BSC parties and non-BSC parties in accordance with their requirements.\n",null,"—",null,"2002-03-27","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P29","Improve Efficiency Of PARMS Reporting Requirements","Utility Link Ltd.","2001-07-11","The PARMS reporting process was original devised in anticipation of the opening of the 1998 market, and due to market start-up it was considered important to allow peer comparison between GSP groups. With the introduction of agent competition, the emphasis has switched from GSP groups to the performance of Suppliers and their agents who provide Suppliers with some of the data required to report Supplier serials. Suppliers are increasing the number of Supplier Hubs in operation so the amount of man days required to complete the PARMs data each month is increasing for both Suppliers and Agents. This is becoming a significant burden, particularly on smaller Suppliers and agents and could be seen as a barrier to increasing competition. This increasing reporting burden could be relieved by removing the GSP group element of PARMS returns, and by removing any serials, where historical data suggests that performance is not an issue.","Request that the PA amends the PARMS reporting requirement so that Suppliers only need to report each of their Supplier serials as a whole rather than split down into GSP groups.  In addition, that PAB also conduct an historical review of PARMs data, and remove any serials which it feels does not provide any significant value to the performance assurance process.   ",null,"—",null,"−","Reject","Reject"]
["P28","Review of Governance and Modification Procedures","Dynegy","2001-07-03","Amerada Hess believes that there are a number of areas in the current drafting of Sections B & F of the Balancing and Settlement Code which potentially limit the transparency of the industry to Trading Parties, particularly new entrants, thus impacting their ability to compete effectively.","A proposal to increase the efficiency and transparency of the BSC governance arrangements and BSC Modification Procedures.\nThis proposal is the amalgamation of proposals P21, P23 and P24.\n",null,"—",null,"2002-07-10","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P27","Amendment To The Derivation Of Imbalance Prices","Electricity Direct","2001-06-26","Imbalances in the direction of system imbalances are more correctly calculated in that they apply the direct cost of managing their gross imbalances through system prices although it can still be argued that this is a potential over-recovery of costs given that NGC will only need to recover net imbalance costs from these parties.","Imbalance cash-out prices to be amended to more closely reflect the costs that out-of-balance parties impose on the system. This should be based around a correct valuation both of net imbalance energy and of energy for reverse-flow imbalances.  ",null,"—",null,"−","Reject","Reject"]
["P26","Market-Driven Trading Neutrality Band","BizzEnergy","2001-06-25","Participants have a strong incentive to balance their portfolio of contracts to their predicted metered output. This is made feasible by an ability to contract up until gate closure in spot markets. There is therefore a strong dependency on the liquidity and efficiency of the spot markets. This will take time to develop and, to an extent, is hampered by the degree to which flexible generation is in the control of a limited number of portfolio and vertically integrated participants.","All participants in the market should be allowed a Trading Neutrality Band decided annually by the Panel. The initial band should be 20MWh per half-hour. ",null,"—",null,"−","Reject","Reject"]
["P25","Commissioning Status In NETA","BP","2001-06-25","Under the Pool commissioning was essentially subsidised by the rest of the industry. At present the Code does not recognise the concept nor unpredictability of commissioning plants and as such commissioning plants are much more vulnerable to the balancing mechanism than any other generator. Without the knowledge of how the plant will perform, these stations are not in a position to accurately determine or control what their balancing mechanism exposure actually is. Based on the balancing mechanism prices since the start of NETA and the unreliability of brand new power stations, the substantial risks of the commissioning phase will be a major disincentive to building new plant."," Introduce a new participation capacity for commissioning power stations.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P24","Review Of The Modification Procedures","Dynegy","2001-06-22","Dynegy believes that operation of the BSC modification procedures has shown that a number of areas could be improved to increase the efficiency with which the industry operates the governance of this important multiparty contract. Discussion with other players suggest that they also have concerns, so a review of the procedures should be undertaken with particular focus on making the process quicker and more inclusive of the industry as a whole.","Review of the modification procedures to improve the efficiency of the BSC governance process.","—","—","—","—","—","—"]
["P23","Review Of The Imbalance Settlement Group (ISG).","Dynegy","2001-06-22","Dynegy has a number of concerns about the current arrangements of the ISG meetings. Areas of concern are the following: 1) Dynegy believes all ISG meetings should be open. 2) Dynegy would also like to improve ISG's present remit.","Review of the ISG to ensure maximum transparency to the industry and efficient operation of the processes it undertakes.","—","—","—","—","—","—"]
["P22","The Provision Of Generator Planned Outage Information to All BSC Signatories.","Dynegy","2001-06-22","This modification proposes that generator's planned outage information be released to all market participants via the BMRS. At present generators are required, under the Grid Code, to provide their planned outage programmes to NGC. NGC aggregates the information and distributes it only amongst generators. This proposal seeks to introduce a new section within the BSC, which will be referred to as the \"Provision of Market Information\". Within this new section, generators will be required to provide their planned outage information centrally, to the BSCCo, as well as to NGC. ELEXON will be responsible for publishing the data on the BMRS system so it is available to all BSC signatories. The requirements upon generators to provide the outage information, in terms of format and timing, will be the same as required under the Grid Code.","Proposes that generator's output usable data (aggregated on an NGC zone and national level) be published on BMRS.",null,"—",null,"2002-04-01","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P21","Review of Modification Group and Panel Procedures","Amerada Hess Gas Limited","2001-06-20","Amerada Hess believes that there are a number of areas in the current drafting of Sections B & F of the Balancing and Settlement Code which potentially limit the transparency of the industry to Trading Parties, particularly new entrants, thus impacting their ability to compete effectively.","Review of Modification Procedures and the operation of the Modification Panel and associated Sub Groups to ensure maximum transparency to the Industry and efficient operation of the processes.","—","—","—","—","—","—"]
["P20","Revision of Obligations of Parties in Relation to BM Unit Registrations","London Electricity plc","2001-05-18","There is currently some dispute within the industry regarding the complex area of which BSC Party a BM Unit should be registered to. Even ELEXON has the need to carefully consider internally what position in response to this question it should take. Clarification of this issue would therefore be very useful for all parties involved.","Proposes to clarify the position in relation to the registration of BM Units in the name of a BSC Party that is an affiliate of the company responsible for the exports or imports connected with that BM Unit.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P19","To provide for the remedy of errors in Energy Contract Volume Notifications and in Metered Volume Reallocation Notifications","London Electricity plc","2001-06-11","Condition 7A.1 of NGC’s transmission licence requires NGC to have in force a document (the BSC) setting out the terms of the balancing and settlement arrangements.","Amend Section P to enable errors in Energy Contract Volume Notifications and Metered Volume Reallocation Notifications to be remedied on an ex-post basis.",null,"Yes",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P18","Removing / Mitigating The Effect Of System Balancing Actions In The Imbalance Price Calculations","National Grid","2001-05-23","The current imbalance price calculations utilise Trade Tagging to identify system balancing actions and exclude them from setting SBP and SSP. The trade tagging methodology was based on the assumption that there would be a significant volume of balancing actions in both directions in each half-hour. However, experience to date is that many periods have only a small volume of balancing actions in one direction, and so the methodology is less effective at removing system balancing actions. It is recognised that it is not possible to separate balancing actions into 'energy' and 'system' in an unambiguous and clearcut manner. However, the current methodology is resulted in some extreme imbalance prices, as balancing actions that appear to be more related to system effects (such as minute by minute frequency control) are being included in price setting, and can have a disproportionate effect on the prices (when there are only small balancing volumes taken in one direction in a period).","A proposal to remove or mitigate the effect of system balancing actions on the imbalance price calculations under the current Trade Tagging methodology. \nP18A introduces the Continuous Acceptance Duration Limit (CADL) which will tag and remove from Energy Imbalance prices, BOAs that are less than 15 minutes in duration.\n",null,"Yes",null,"2001-09-25","Approve Pro\nReject Alt","Approve Pro\nReject Alt"]
["P17"," ECVNAs To Receive 7 Day Report","PowerEx","2001-05-18","Currently the 7-Day Report is received by participants, but not by ECVNAs. The report provides participants with confirmation that notifications have been processed correctly. However, there is no confirmation of notification to ECVNAs other than the protocol \"ACKs\". It is essential that 3rd Party ECVNA also receives these confirmations to manage their own errors and omissions risk. Especially for those 3rd Party ECVNAs which are guaranteeing that notifications will be processed on time and correctly. Notifications errors and omissions is a risk, not only to participants and 3rd Party ECVNAs, but to the entire industry. The more controls on these risks through tighter confirmation processes, the more comfortable participants will become with the transaction process, particularly transacting close to gate closure. This will lead to more short term liquidity and less exposure to the balancing mechanism.","A proposal to permit all Energy Contract Volume Notification Agents to receive an appropriate version of the 7-Day Report confirming notified volumes received by the ECVAA daily for periods up to 7 days before gate closure.",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]
["P16","Removal Of Restriction For Submitting Summer Demand Capacity & Generation Capacity","Northern Electric plc","2001-05-23","The removal of the restriction within K3.4.9 would result in market participants being able to submit DC/GC for the Summer Season. This clause was included within the BSC to prevent many changes being submitted to DC/GC immediately following NETA Go-Live. It is now evident that due to the April contract round market participants need to submit new DC/GC values. If market participants are unable to submit new GC/DC values this could have an adverse affect on their credit cover calculation.","A proposal to remove the restriction within K3.4.9 to permit market participants to submit DC/GC for the Summer Season.",null,"Yes",null,"2001-06-01","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P15","Removal Of Price Spikes Associated With System Balancing From System Prices","Vattenfall","2001-05-22","In Ofgem's April 2000 consultation (NGC systems operation under NETA: transitional arrangements), the view is reiterated that there is a distinction between NGC actions taken for system balancing as opposed to energy balancing reasons. In practice it is very difficult to distinguish between these factors but, in principle, system balancing actions should not impact upon imbalance prices.","It is proposed that bid-offer acceptances with an acceptance time after 30 minutes before the start of the real time half-hour period be tagged and excluded from the calculation of SBP and SSP.",null,"Yes",null,"−","Reject","Reject"]
["P14","Manifest Error Provisions Where the Bid/Offer Acceptance In Question Has Not Been Acted Upon","National Grid","2001-05-22","At present when a Manifest Error is made the Trading Disputes Committee can only amend the resultant imbalance prices and award costs where a party can demonstrate that they have been incurred. If the System Operator realises that an error has occurred before the bid or offer has been delivered it must either allow the offer to be delivered, or issue an \"unwinding\" acceptance. The former approach will incur costs which the counter party will then seek to recover, whilst the latter is likely to prove very expensive and further distort prices. In both cases the Trading Disputes Committee will ultimately be asked to resolve a complex case by amending the imbalance prices and identifying costs. It would be more effective and efficient to simply cancel or rescind the erroneous instruction.","A proposal to allow erroneous instructions to be cancelled or rescinded where manifest error is identified before a bid or offer has been delivered.  \"Erroneous\" and \"rescinding\" acceptances will then be excluded from setting imbalance prices.",null,"—",null,"−","Reject Pro\nReject Alt","Reject Pro\nReject Alt"]
["P13","Change to Modification Group procedures","Amerada Hess Gas Limited","2001-05-16","Section F Clause 2.4.18 states that ….”meetings of each Modification Group shall be held in closed session…” In the case of a new entrant BSC Party, the requirement in Section F Clause 1.5.3 …”that Parties shall make available a reasonable level of suitably qualified personnel to act as members from time to time of Modification Groups..” cannot be met unless such groups are open all all parties to attend and learn. Whilst in no way unsupportive of the principle of “expert” groups, Amerada Hess is keen that the Industry should seek to develop a wide range of such “experts” from all Parties, including new entrants, hence we believe that groups with a core membership of such experts, attended by other interested parties are the best way to learn the skills required, such that in time a greater depth of suitably qualified individuals will be available to serve on such groups. In addition, whilst acknowledging that the Panel can and does declare Modification Groups open, it is our belief that such groups should be open by default.","It is proposed that all Modification Group meetings should be held in open session by default.","—","—","—","—","—","—"]
["P12","Reduction Of Gate Closure From 3.5 Hours To 1 Hour","Damhead Creek Limited","2001-05-09","Damhead Creek believe the difficulty in forecasting output and demand 3.5 hours ahead of real time results in unnecessary exposure to imbalance charges that undermines competition in both generation and supply. Moving gate closure to 1 hour prior to real time would reduce exposure by making forecasting easier. Given the System Operator’s (SO) demonstrated preference and ability to balance the system “just-in-time”, they believe the original rationale for a gate closure period of 3.5 hours is redundant.","A proposal to reduce the Gate Closure period from 3.5 hours to 1 hour.",null,"—",null,"2002-07-02","Approve","Approve"]
["P11","Revision Of Minimum Credit Cover Requirements ","The European Power Source Company (UK) Limited","2001-05-09","Under the current credit arrangements provided by Section M, Trading Parties are expected to project their expected consumption and production volumes and post sufficient collateral with ELEXON to cover their projected EI level. This collateral then translates directly into the amount of ECC posted by that trading party. There is currently limited third-party oversight of the appropriateness of the ECC posted by Trading Parties. In particular, a Trading Party could sets its own ECC limit at zero and attempt to remain in balance at the end of each settlement period. As a result, a Trading Party could accrue EI on the system without ever having posted collateral. This proposal aims to modify the existing credit requirements so that Trading Parties are as fully protected as possible against EI that could arise due to the action of any one Trading Party by requiring a reasonable level of up-front collateral that, wherever possible, is based on historical trading data.","A proposal to introduce a minimum credit requirement for Trading Parties based on historical Energy Indebtedness (EI) levels. Trading Parties would be required to maintain a minimum level of Energy Credit Cover (ECC) in order to be able to transact.",null,"—",null,"−","Reject","Reject"]
["P10","Eliminating Imbalance Price Spikes Caused By Truncating Effects","National Grid","2001-05-02","The truncating of National Grid acceptances to a whole number of minutes or an integer volume of megawatts can result in the settlement software registering a “spurious” Bid/Offer Acceptance of a very small Bid/Offer volume in addition to the intended acceptance. If this is the only volume 'accepted' in that direction, an extreme Bid/Offer price combined with a very small volume (typically a fraction of a MWh) can lead to a price spike that is totally unrelated to the economics of system balancing. For example, a volume of 50kWh at £1000/MWh might be registered, implying a balancing cost of £50, but the imbalance price would be set to £1000/MWh. As with the price spikes caused by BSAD data which are currently being addressed, we do not regard such spikes as providing the correct economic message for participants to self-balance, and instead may create an artificial incentive for participants to adjust their position avoid exposure to imbalance price spikes.","Modification of the SBP and SSP calculations to remove price spikes caused by spurious Bid/Offer Acceptances registered by the settlement software as a result of truncating National Grid instructions to a whole number of minutes or an integer volume of megawatts.",null,"Yes",null,"2001-05-11","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P9","Correction Of Technical Error In Respect Of The Energy Contract Volume Notifications Under Section P.2.3 And Adjustment Of Settlement Data Under Section U.2.5.","Scottish Power","2001-05-01","The Total System Residual Settlement Cashflow under Section T of the BSC is calculated with reference to the imbalance charges arising due to the mis-match of the physical balance of the system as against the trades notified under the BSC. At present there has accrued and continues to exist a risk that the Total System Residual Settlement Cashflow can be distorted by trades which are notified erroneously through a no fault technical error in the software used by Participants. The position being that where trades have taken place between production and consumption accounts in order to match off the trading position against the physical flow the technical error undermines the position to create a distorted Total System Residual Settlement Cashflow. In order to correct this problem the ability should be given to parties who suffer such error to correct (retrospectively or otherwise) the data submitted to ensure that the correct calculation of the Total System Residual Settlement Cashflow is made","Modification to Section P.2.3 and U.2.5 to permit BSC Parties to correct submission of ECVNs (retrospectively or otherwise) which are incorrect due to no fault technical error.",null,"Yes",null,"−","Reject","Reject"]
["P8","Introduction Of A Price Adjuster To Reflect Option Fees For Balancing Services Contracts In Setting System Buy Price And System Sell Price","National Grid","2001-04-20","The recent Modification (P3) implemented a Price Adjuster for System Sell Price and System Buy Price by altering the Balancing Services Adjustment Data Methodology and implementing workaround W024.  ","This modification proposes to retain the same functionality, but to implement the Price Adjuster within the BSC and ELEXON's central systems.",null,"—",null,"2001-09-25","Approve","Approve"]
["P7","Allocation Of Supplier Demand To The Same BM Unit In A GSP Group For All Suppliers In The Same Company Group","Powergen","2001-04-18","The original modification, which was rejected by the Authority, proposed that the Supplier demand, for all supply companies in the same company group, can be allocated to the same BM Unit within a GSP Group. ","An Alternative Modification was developed and implemented which allows Supplier demand, for all supply companies in the same company group, to be allocated to the same Trading Unit within a GSP Group.",null,"—",null,"2002-02-28","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P6","Removal Of Obligation To Publish Price Data In Ft","BSC Panel","2001-04-05","The very high cost of daily publication of price data in the press is no longer justified, given the accessibility of the data via the BSC website.","A proposal to remove the obligation on BSCCo to publish System Sell Price and System Buy Price information in the press. It is proposed that the price data should continue to be published on the BSC Website.",null,"—",null,"2001-05-16","Approve","Approve"]
["P5","Extension Of Indemnity Under Section B2.9","London Electricity plc","2001-03-28","The new governance model under the BSC is untested and untried. Consequently, there are no precedents and no case history available to Panel Members to test the interpretation of the role. Therefore, it is unreasonable for Panel Members to be exposed to personal risk for accidental failure to correctly interpret the precise boundaries of a role that is imprecisely defined (there are over 1300 references to Panel in the Code and Panel members do not have legal training). In addition, it has become apparent that ELEXON is also unable to ensure that the Panel is not presented with decisions outside the Panel's vires. This should not be taken to indicate that ELEXON is not undertaking an appropriate role, but rather to highlight the potential difficulties.","Modification to Section B 2.9.1 to extend the indemnity to cover actions undertaken in good faith.  The words \"or in the proper exercise of the powers.\" in Section B 2.9.1 should be replaced with \"or in the proper or good faith purported exercise of the e powers.\"",null,"—",null,"2001-07-24","Approve","Approve"]
["P4","Dual Energy Contract Notification","Dynegy","2001-03-28","The existing notification system relies on the 7 day report and significant manpower in checking and altering positions during the early evening. The system has a high risk of failure, already experienced by a number of players, with associated high costs that will ultimately be born by customers. The 7 day report can also not confirm notifications of trades close to real time and thus acts as a disincentive for physical players to trade into position during each day, as the risks of incorrect notification are very high (£500 imbalance prices have already been seen). The risk seems to be acting as a barrier to trading, reducing the liquidity in the market and thereby its efficiency. Assuming the new market starts to encourage more trading, we are all already aware of the potential problems that central systems has with increased notification volumes, suggesting the system will require alteration anyway.","A proposal to introduce dual notification of all energy contract notifications. The contract notification process in the BSC would be altered such that both ECVNAs notify each energy contract and only matched notifications result in a contract being successfully notified.  Any non-matched notifications will automatically be rejected by the ECVAA, notifying both ECVNAs of their failure to complete an energy contract notification",null,"—",null,"2002-12-10","Reject Pro\nApprove Alt","Reject Pro\nApprove Alt"]
["P3","Correction Of Price Spikes Generated By De-Minimis NGC Purchases ","Electricity Direct","2001-03-27","In a period where NGC is carrying Standing Reserve, if - because the system is basically long, NGC purchases only a small amount of energy then - the resultant SBP can be extremely high. On 27th March the NGC BCA was set at £2,333.51 per period, for 14 hrs of the day. The smallest recorded non-zero total trade in a period was 1.403MWh of system sell (at 15:30). Given that there is no reason to expect system buy volumes to be significantly different from sell volumes, a system buy of 1.403MWh in a period where Standing Reserve fees applied would generate a price of £1,663.23/MWh. This level of price spike can be expected as a regular, perhaps daily occurrence, with NGC occasionally buying less than 1MWh (for example, a buy finishing 1 minute after the start of a period could feasibly mean an energy purchase of 1/120MWh hence a price of £280,021.20/MWh). This undue and unnatural price volatility is a function of NGC's prudent purchase of Standby Reserve, and their acceptance of BM Offers to minimise cost (not price) within a price mechanism that needs further development.","This Modification would prevent the occurrence of price spikes when option fees paid by NGC for provision of reserve (and other balancing contracts) are included in the numerator of the energy imbalance price calculations, but there is a very small volume of accepted offers (or bids) in such periods.",null,"Yes",null,"−","Reject","Reject"]
["P2","Revision Of The Methodology For Assessing Credit Indebtedness.","British Gas","2001-03-27","As the current methodology for assessing credit indebtedness does not use actual system inputs or outputs and uses the CAP for the whole period of indebitness, the indebtedness is far from accurate, exposing the whole community to significant credit risk.","It is proposed that credit indebtedness is assessed against actual inputs and outputs as soon as they are available and that best estimates are used until they are available.  It is further proposed that CAP is only used for pricing during periods when the ere is no ability to provide additional security.",null,"—",null,"2002-09-30","Approve","Approve"]
["P1","Extension Of The Definition Of ECVAA Systems Failure For Permitting Post Gate Closure Notification","OM London Exchange Ltd","2001-03-27","The current recovery procedures have an inconsistent treatment in relation to a member’s inability to submit contract notifications due to a failure of systems provided by ELEXON, in that a central system failure is included in recovery procedures but a communications failure is not. From a member’s perspective a central system failure or a communications failure would equally frustrate contract notifications. Failure to receive notifications increases potential imbalance and hence could have a significant effect on imbalance prices when in fact there were no changes in market conditions. Moreover, such inconsistent treatment implies that a member would be exposed to imbalance charges in the event of a communications failure, but would be protected from such charges through the ECVAA recovery procedures in the event of a central system failure.","A proposal to extend the definition of the ECVAA systems to include the High Grade Service communications medium provided by ELEXON from the party to the central ECVAA systems. It is proposed that the modification is applied retrospectively to take effect from March 27th 2001",null,"—",null,"−","Reject Pro\nApprove Alt","Reject Pro\nReject Alt"]

{"sheet":"Change Proposals","index":1,"n_rows":1002,"n_cols":41,"rows_kept":1002,"merged":[[5,11,5,40],[6,0,6,5],[6,6,6,9],[6,11,6,15],[6,16,6,20],[6,21,6,25],[6,26,6,30],[6,31,6,35],[6,36,6,40],[7,11,8,11],[7,12,8,12],[7,13,8,13],[7,14,8,14],[7,15,8,15],[7,16,8,16],[7,17,8,17],[7,18,8,18],[7,19,8,19],[7,20,8,20],[7,21,8,21],[7,22,8,22],[7,23,8,23],[7,24,8,24],[7,25,8,25],[7,26,8,26],[7,27,8,27],[7,28,8,28],[7,29,8,29],[7,30,8,30],[7,31,8,31],[7,32,8,32],[7,33,8,33],[7,34,8,34],[7,35,8,35],[7,36,8,36],[7,37,8,37],[7,38,8,38],[7,39,8,39],[7,40,8,40],[8,0,8,10],[16,12,16,15],[18,12,18,15],[22,17,22,20],[23,17,23,19],[24,21,24,23],[27,21,27,23],[28,0,28,10]],"flags":["formulas_cached_only"]}
[]
[]
[]
[{"$nulls":5},"BSC Change Register"]
[{"$nulls":5},"Change Proposals"]
[]
["Details",{"$nulls":5},"Progression",{"$nulls":3},"Decision","May",{"$nulls":4},"June",{"$nulls":4},"July",{"$nulls":4},"August",{"$nulls":4},"September",{"$nulls":4},"October"]
["CP","Title","Proposer","Date Raised","Problem/Issue","Solution","Current Status","CPC No.","Committee","Implementation date","Committee Decision","1st - 5th","8th - 12th","15th - 19th","22nd-26th","29th - 31st","1st - 2nd","5th - 9th","12th - 16th","19th-23rd","26th - 30th","3rd - 7th","10th - 14th","17th - 21th","24th-28th","31th","1st - 4th","7th - 11th","14th - 18th","21at-25th","28th-31st","1st ","4th - 8th ","11th - 15th ","18th - 22nd","25th - 29th ","2nd - 6th","9th - 13th ","16th - 20th ","23th - 27nd","25th - 29th "]
["Open Change Proposals"]
["CP1469","Changes to support the implementation of the SRAG’s recommendations","ELEXON","2016-07-19","Currently, there are no processes set out for elective Half Hourly (HH) Settlement of smart Meter data. Therefore, changes to the relevant BSCPs are needed to set out the processes required where the Supplier, rather than the Half Hourly Data Collector (HHDC), retrieves HH data. \nNew processes are needed for:\n1. the exchange of HH data between the Supplier and HHDC;\n2. data validation and estimation for smart Meters;\n3. informing the HHDC of the Supplier’s reading schedule (i.e. when to expect HH data);\n4. allowing Suppliers to send cumulative register readings to the Licensed Distribution System Operator (LDSO).    \nOther changes include increasing the precision data flows for transferring HH data hold HH values to the nearest Wh and removing the requirement for Proving Tests.","BSCPs 502, 503 and 514 have been redlined to outline the new processes.","Progression Paper was presented to SVG on 2 Aug. Consultation issued in 8 August batch. Assessment Report was presented to SVG on 4 October. The SVG approved CP1469 for implementation in Jun 2017. ","CPC00769","SVG","2017-06-29","Approve",{"$nulls":9},"Implement"]
["CP1474","Updating the CoMC processes to facilitate the elective HH Settlement of SMETS Meters","ELEXON","2016-10-14","The existing CoMC processes are not appropriate for smart Meters where the Supplier is responsible for configuring and collecting data from the Meter. The existing processes tend to focus on scenarios where a physical change of the Metering System is required to facilitate the CoMC which usually requires a site visit. Since smart Meters can collect both HH and NHH data, from a Supplier’s point of view it only needs to collect the appropriate data from the Meter. Ofgem asked ELEXON to chair a cross-code working group to look into the CoMC changes needed to enable the elective HH Settlement of smart Meters. The Change of Measurement Class for Smart Meters Working Group (CMSWG) was formed to discuss these changes and find a proposed solution.","The proposed solution looks to create new CoMC processes for smart Meters.","CP1474 was raised by ELEXON on 14 October 2016. The new CP Progression Paper was presented to the ISG, PAB and SVG for information on 25 October 2016, 27 October 2016 and 1 November 2016 respectively. The CP was issued for Consultation on 7 November 2016 with responses due by 2 December 2016. The PAB, SVG and ISG approved CP1474 on 15 December 2016, 3 January 2017 and 4 January 2017 respectively.","CPC00771","ISG/PAB/SVG","2017-06-29","Approve",{"$nulls":9},"Implement"]
["CP1475","Remove obligation to re-date final NHH Meter readings on CoMC","E.ON","2016-10-14","A Settlement Imbalance occurs with the Change of Measurement Class (CoMC) activity by the re-dating of reading taken by the newly appointed Half Hourly Meter Operator Agent (HHMOA), at the point the Meter is remotely reconfigured from Non Half Hourly (NHH) to Half Hourly (HH) and passed to the Non Half Hourly Meter Operator Agent (NHHMOA) who in turn passes these via a D0010 ‘Meter Readings’ to the Non Half Hourly Data Collector (NHHDC) for validation and processing to Settlement.\nThe re-dating of the readings taken on the date of the CoMC and the reconfiguration of the Metering System creates a gap in Settlement which in turn leads to exceptions and further work for Supplier and Supplier Agents to correct and manage.\n","Stop the re-dating of D0010 Data Flow Meter reads from the HHMOA to the NHHMOA and process these with the date of the CoMC Meter configuration.","CP1475 was raised by E.ON Energy Solutions on 14 October 2016. The new CP Progression Paper was presented to the SVG for information on 1 November 2016. The CP was issued for Consultation on 7 November 2016 with responses due by 2 December 2016. The SVG approved CP1475 on 3 January 2017 for implementation on 29 June 2017.","CPC00771","SVG","2017-06-29","Approve",{"$nulls":9},"Implement"]
["CP1476","Facilitation of Incremental LLFs","ELEXON","2016-10-27","BSCP128 requires all Licensed Distribution System Operators (LDSOs) to submit LLF data via the D0265 ‘Line Loss Factor Data File’ data flow.\nAs a result, a full data refresh is required for any change to the LLF data submitted. This means that, if an LDSO requires an additional LLFC the entire data  set will have to be re-submitted in order for the submission to be Code compliant.\nThe D0265 can hold large volumes of period data for potentially thousands of Line Loss Factor Classes (LLFCs). This means that any LDSOs have to pay DTN costs for a LLF full data set, irrespective of the size of the changes to the data set.","Amend BSCP128 Appendix 7 to allow LDSOs to submit incremental changes to their Line Loss Factor data set.\nThis change will reduce the DTN charges for LDSOs, as data will not need to be resubmitted via a full D0265. This change will also reduce the effort required by ELEXON to audit and validate the changes for mid-year submissions.\n","CP1476 was raised on 27 October 2016. It was presented to the ISG on 22 November 16 and to the SVG on 6 December 16. It will go out for Consultation on 12 December with responses due by 6 January 2017. CP1476 was approved by the ISG on 24 Jan and by the SVG on 31 Jan. \n","CPC00772","SVG/ISG","2017-06-29","Approve",{"$nulls":9},"Implement"]
["CP1477","Updates to BSCP537 Appendix 1 as a result of P283","ELEXON","2016-11-07","Modification P283 placed Commissioning obligations on the Metering Equipment owner. BSCP537 Appendix 1 has not been updated since the implementation of P283. Therefore, BSCP537 Appendix 1 does not reflect the new Commissioning obligation introduced by P283.","CP1477 proposes to update BSCP537 Appendix 1 to account for the new Commissioning obligations introduced by P283. Specifically, this CP will update the guidance to answering questions around the Commissioning process.","CP1477 was raised on 7 November 2016. The new CP Progression paper was presented to the PAB on 24 November 2016, and will be presented to the SVG and ISG on 6 December 2016 and 13 December 2016 respectively. The CP was issued for Consultation on 9 January 2017 with responses due 3 February 2017. This CP was presented for decision to the PAB on  24 February and to ISG on 28 March. The ISG approved the CP with additional changes to the redlining. The SVG approved the CP on 4 April but we will need to go back to the PAB to ask to approved the addiitonal changes. The PAB approved the additional changes. CP1477 will be implemente on 29 June 2017.  ","CPC00773","PAB/SVG/ISG","2017-06-29","Approve",{"$nulls":9},"Implement"]
["CP1478","Automate the loading of the DF Matrix","ELEXON","2016-11-22","Currently, information on upheld Trading Disputes for rectification in the Post-Final Settlement Run is entered manually into the SVAA system. ","CP1478 proposes automating the process of loading details of upheld Trading Disputes into SVAA to remove the risk of manual error.","CP1478 was raised by ELEXON on 22 November 2016. The Progression Paper was presented to SVG on 6 December and was issued for Consultation on 9 January 2017 and responses were received by 3 February 2017. It was taken to SVG on 28 February 2017 for final decision and was approved.","CPC00773","SVG","2017-11-02","Approve"]
["CP1479","Updates to the Defined Metering Points in Codes of Practice 1, 2, 3, 5 and 10","ELEXON","2016-11-23","On 6 February 2014 ELEXON raised Issue 54 ‘Discrepancies between the points of measurement required in the BSC and the CoPs and the physical points of connection’. ELEXON presented the Issue 54 Report (BSC Panel 225/13) to the BSC Panel on 12 June 2014. The Issue 54 Report highlighted three issues with Defined Metering Points (DMPs) in Codes of Practice (CoPs) 1, 2, 3, 5 and 10. ","This CP proposes to:\nchange the DMP between a Distribution System of a LDSO (with no other parties connected) and the Transmission System to the point of connection;\nchange the DMP for where Generating Plant connects to the Transmission System to be the point of connection; and\nmake the DMP between an External Interconnector and the Transmission System the point of connection, rather than specify all the existing External Interconnectors.","CP1479 was raised by ELEXON on 23 November 2016. It will be presented for information to the ISG on 13 December 2016 and to the SVG on 3 January 17. The CP will then be issued for Consultation on 9 January 2016 with responses due 3 February 2016. CP1479 was presented for decision to the ISG on 21 February 2017. The decision of the ISG was not unanimous. Therefore, CP1479 was presented to the Panel at its meeting on 9 March 2017. The Panel approved CP1479 with an Implementation Date of 2 November 2017.  ","CPC00773","ISG/SVG","2017-11-02","Approve"]
["CP1480","Creation of a new authorisation category for corrections to BOA related data","National Grid","2016-11-28","The BSCP18 ‘Corrections to Bid-Offer Acceptance Related Data’ is ambiguous on who may authorise corrections to Bid-Offer Acceptance (BOA) data.  This lack of clarity is creating problems for the Transmission Company (TC) when trying to identify the right individual to contact and can cause delays. These delays could mean that corrections to data are not made by the Settlement Final (SF) Run causing incorrect data to enter Settlement.","CP1480 proposes the creation of a new authorisation category specifically for consenting to corrections to BOA data. Details of individuals in this new category would be made available to the TC for the purpose of seeking consent for corrections to BOA related data to be made.","CP1480 was presented to the ISG on 13 December 2016 and to the SVG on 3 January 2017. CP1480 was issued for consultation in the January 2017 CPC batch and feedback has been received. It was taken to ISG on 23 February 2017 and SVG on 28 February 2017 for final decision, however, at both meetings the CP was deferred for one month to explore alternative solutions. ISG was updated on 28 March 2017 and SVG on 4 April 2017 and both agreed with the suggested amendement. The new redlining will be consulted on as part of the CP Consultation which was issued on 8 May 2017, with responses due by 2 June 2017. It will then be presented to the SVG and ISG  for decision at its meetings on 4 Jul 17 and 25 Jul 17. ","CPC00773","ISG/SVG","2017-11-02","TBC",null,"CP Consultation",{"$nulls":7},"ISG","SVG"]
["CP1482","Upgrade of NHHDA and EAC/AA systems from Oracle 11g to version 12c ","ELEXON","2016-12-21","The current version of NHHDA and EAC/AA applications that ELEXON provide to Party Agents run on Oracle 11g. This will become unsupported in 2017 and will therefore need updating to Oracle 12c. CP similar to CP1383.","Upgrade NHHDA and EAC/AA systems from Oracle 11g to version 12c when these become unsupported in 2017. ","CP1482 was approved by the SVG on 2 May 2017 for implementation on 22 February 2018.","CPC00775","SVG/STAG","2017-11-02","Approve","SVG"]
["CP1483","Changes to BSCP550","ELEXON","2017-01-18","At the time that Suppliers are required to appoint their agents to a shared Metering System it is unlikely that the agents will be aware that the site is to be shared. This makes it difficult for the Meter Operator Agent (MOA) and the HHDC to assist Suppliers by highlighting potential issues before the Metering System becomes effective. Due to this, the current process can result in any errors needing to be retrospectively resolved adding complications for all parties. ","This CP will make it a requirement for Suppliers to inform their agents, at the time of agent appointments, of the allocation schedule and any technical information necessary for the agent to deploy that solution. This will only be necessary for new arrangements or where new agents are appointed to existing sites. It is not required, therefore, to inform the existing agents of the allocation schedule on change of a Supplier only for example. This will be done in the following steps:\n3.1 New connection or Transfer from CMRS to SMRS;\n3.2.1 Single to Shared SVA Metering System;\n3.3 Change of HHDC for an Existing Shared SVA Metering System; and\n3.4 Change of Meter Operator Agent for an Existing Shared SVA Metering System.","The progression paper for CP1483 was presented at the SVG on 31 January 2017. It was published for consultation on 6 February to 4 March 2017. The CP was presented to SVG for decision on 4 April 2017 and they decided to defer it on the basis that the legal text be changed. This CP went out for Consultation In April. The Assessment Report will be presented to the SVG on 4 July 2017.","CPC00774","SVG","2017-11-02","TBC",{"$nulls":10},"SVG"]
["CP1484","DA686: Validation during Volume Allocation Runs","ELEXON","2017-02-08","Erroneous data is used in the Supplier Volume Allocation (SVA) run. This is because, currently, limited checks are performed and the ability to correct mistakes is minimal. This leads to mistakes occurring and being difficult to correct.","This CP proposes to introduce validation measures to reduce errors. Firstly, individual DA data will be validated and checked for the plausibility of the consumption values. Secondly, it will ensure there is a complete set of DA data ready for the VAR. Lastly, it will include checks on the results of VARs.","The CP was raised on 8 February 2017 and the initial paper was taken to SVG on 28 February 2017. CP1484 was issued for consultation on 6 March 2017 and responses were received by 31 March 2017. At its meeting on 2 May 2017, the SVG recommended that the Panel approves CP1484 at its meeting on 11 May 2017, a decision it is unable to make as the costs are above the SVG's £150k threshold. At its meeting on 11 May 2017, the Panel approved CP1484 for implementation in the November 2017 Release. ","CPC00775","SVG","2017-11-02","Approve","SVG","Panel "]
["CP1485","Validation of power transformer and cable/line loss adjustments","ELEXON","2017-03-13","The Issue 54 Group agreed with ELEXON’s proposed solution to validate power transformer and cable/line electrical loss adjustments as part of the (site specific) Metering Dispensation application process. They also agreed that, where the Registrant wishes to apply cable or line electrical loss adjustments as part of the proposed generic Metering Dispensation under CP01-PP, these should also be validated under BSCP32. \n","This CP proposes changed to BSCP32, CoP1, 2, 4, and 5 to address the validation of power transformer and cable or line electrical loss adjustments as part of the Metering Dispensation application process.","The CP was raised on 13 March 2017. It was presented to the ISG on 28 March 2017 and to the SVG on 4 April 2017. It went out for Consultation on 10 April with responses due by 5 May. CP1485 was approved at the ISG meeting on 23 May 2017 and at the SVG meeting on 30 May 2017 for implementation on 2 November 2017 ","CPC00776","ISG/SVG","2017-11-02","Approve",{"$nulls":3},"ISG","SVG"]
["CP1486","Removing example Advice Notes, Backing Sheets and Confirmation Notices from BSCP301","ELEXON","2017-03-17","The Funds Administration Agent (FAA) has implemented the reverse charge changes into their system, effective from 1 July 2014. However, reference to the old VAT arrangements are still included within examples in BSCP301 ‘Clearing, Invoicing and Payment’.  \nFurthermore, a VAT rate of 17.50% is incorrectly referenced in the examples of a Combined Advice Note, Combined Confirmation Notice and Advice Note Backing Sheet in BSCP301 ‘Clearing, Invoicing and Payment’.\n","CP1486 ‘Removing example Advice Notes, Backing Sheets and Confirmation Notices from BSCP301’ was raised by ELEXON on 15 March 2017. It also proposes numerous changes to communication methods.\n\n","CP1486 was presented to the ISG on 28 March 2017. It will now be sent out for consultation on 10 April 2017, with responses due 5 May. This CP went to ISG for decision on 23 May 17, and was aprroved for June 2017 release.","CPC00776","ISG","2017-06-29","Approve",{"$nulls":3},"ISG",{"$nulls":5},"Implement"]
["CP1487","Remove the exclusion of Change of Measurement Classes in BSCP533 Appendix B","ELEXON","2017-05-17","Where there has been a CoA concurrent with a CoMC. It currently means that the new HHDC should not report missing MTDs from the old NHHMOA in standards 2-7 of NM12 or HM12. This holds true for both DCs and MOAs reporting. The DC reports feed in to the metrics for SR0025 (missing HH MTDs) and SR0024 (missing NHH MTDs). Currently SR0033 and SR0034 (The risk that old MOAs don’t send MTDs to the new MOA) are not counted as top Settlement risks. Therefore whilst we have the data for these via the NM12 and HM12 as reported by MOAs, these data sets are only used for information and investigatory purposes, primarily where a MOA notifies us that the reason they have not forwarded MTDs to the DC is because they themselves have not received them from the previous MOA.  The NHHDC should only ever receive MTDs from a NHHMOA and the HHDC should only receive MTDs from the HHMOA (as outlined in BSCP514 section 7).  However, in order to facilitate a CoMC across sectors, MTDs need to be transferred from HHMOAs to NHHMOAs and vice versa. Therefore it can be argued that the exclusion of missing MTDs upon CoMC from Standards 2-7 of NM12 and HM12 as reported by MOAs is contradictory to this process. There is also an argument that instances of missing HHMTDs reported by the HHDC upon CoMC are no less important than missing MTDs, regardless of the trigger process. Both are  a risk to Settlement. Therefore HHDCs should be reporting on missing HHMTDs from the HHMOAs which have completed the CoMC from NHH to HH (and vice versa). ","Remove the exclusion of CoMCs from standards 2-7 from NM12 and HM12 reporting for both DCs and MOAs. ","CP1487 was raised on the 17 May 2017. This CP was  presented for information to PAB on the 25 May 2017 and to SVG on 30 May 2017. CP1487 went out for consultaion 5 June 2017 with responses due 30 June 17. ","CPC00778","PAB/SVG","2018-02-22","TBC",{"$nulls":3},"PAB","SVG",null,"CP Consultation"]
["CP1488","Align the NETA IDD spreadsheets with the live implementation of the SAA-I014 flow","ELEXON","2017-06-07","The changes to the SAA-I014 flow within the NETA IDD resulting from Modification P305 has erroneously listed some fields with the incorrect parent/child relationship. The system changes resulting from P305 have been implemented correctly and all the flows that are sent out from the SAA to BSC Parties, National Grid or ELEXON are currently correct. However, we need to ensure the documentation reflects the actual structure of the SAA-I014 flow.","This CP proposes to correct the manifest error within the NETA IDD spreadsheets, to ensure that they match the actual, correct, structure of the SAA-I014 flow","CP1488 was raised as a housekeeping CP on 7 Jun 17.  It will be presented to the ISG for decision on 27 Jun 17. ","N/A","ISG","2017-11-02","TBC",{"$nulls":9},"ISG"]
["CP1489","Amendments to BSCP128 to align with BSCP68 timescales for a Transfer of BM Units between SMRS and CMRS and vice-versa","ELEXON","2016-02-23","There is inconsistency in timescales for Line Loss Factor (LLF) mid-year submission and approval between BSCP68 ‘Transfer of Registration of Metering Systems between CMRS and SMRS’ and BSCP128 ‘Production, Submission, Audit and Approval of Line Loss Factors’.\nCP1423 ‘Amendments to BSCP68 following a review’ discussed Housekeeping changes to processes of transfer between the Central Meter Registration Service (CMRS) and the Supplier Meter Registration Service (SMRS) or vice versa.\nThe Imbalance Settlement Group (ISG) and the Supplier Volume Allocation Group (SVG) rejected CP1423 and proposed to raise two subsequent CPs. The first change addressed the simple changes to BSCP68 and was progressed as Housekeeping (CP1461 ‘Amending BSCP128 to reflect a new simple SVA file format for LDSO LLF submissions’).  This CP investigates the lead times of LLF submission with a view to aligning BSCP128 with the shorter timescales given in BSCP68.\n","To define processes for CVA to SVA and SVA to CVA within the Mid year submission processes of BSCP128. This will define timescales to match BSCP68.","CP1489 was raised on 7 June 2017. It will be presented  for information to the ISG on 25 July 17 and to the SVG on 1 August 2017. ","N/A","ISG","2018-02-22","TBC",{"$nulls":13},"ISG",null,"SVG"]
["CP1490","Changes to BSCP27 and TAA Service Descriptions to remove constraints to service improvement.","ELEXON","2017-06-14","Both the ‘Service Description (SD) for CVA Technical Assurance’ and the ‘Supplier Volume Allocation (SVA) Technical Assurance Service Description’ exceed the necessary purpose of the Technical Assurance Agent’s (TAA) role as set out in BSCP27 ‘Technical assurance of Half Hourly Metering Systems for Settlement Purposes’. They extend to specifying types of technology to be used by the TAA for the purposes of reporting and evidence capturing following an Inspection Visit. They also specify the hosting and operational requirements of the technology used. This is not necessary for Meter inspections, assurance or to articulate the reporting obligations. The consequence is that it restricts the TAA in its ability to deliver the service in improved or new ways. It also requires that the TAA provide the IT solution as well as conducting Inspection visits. In reality these two functions may be carried out by two separate companies.","Amend both SDs so that the TAA is not required to provide an online management tool for accessing and amending information. Instead, the TAA should be required to provide Management Information. All references to “the online management tool” should be by “the software system”. Amend BSCP27 so that it makes reference to the software system ‘used’ by the TAA instead of provided by the ‘TAA’.","CP1490 was raised on 7 June 2017. It will be presented  for information to the ISG on 27 Jun 17 and to the SVG on 4 July 2017. ","N/A","ISG/SVG","2018-02-22","TBC",{"$nulls":9},"ISG","SVG"]
["CP1491","Lack of clarification surrounding the timeliness of Proving Tests and documentation for CVA MOA in BSCP02","ELEXON","2017-06-15","Clarifications in BSCP02 so that a proving test is carried out for any Meter change.","The Balancing and Settlement Code (BSC) Auditor conducted an audit of Central Volume Allocation (CVA) Meter Operator Agents (MOAs) during the audit period ending 31 March 2015. The BSC Auditor identified an issue related to a lack of clarification regarding MOA BSC Procedure (BSCP) requirements (BSC Auditor’s Summary of Market Issues).\n\nWe have also included three Housekeeping Changes in this Change Proposal (CP) to address some minor errors. Including these Housekeeping Changes in this CP is more efficient than progressing a separate CP.\n\nThere are no Central System Impacts that have been identified to implement the solution proposed by CP1491. However, the Central Data Collection Agent (CDCA) may be required to update its documentation from the CP1491 solution so that it is clear that the CDCA will be expecting the Metering System Proving Test Record documentation from the CVA MOAs.\n","CP1491 was raised on 15 June 2017, and will go to the ISG for information on 27 June 2017. CP1491 will be issued for CP consultation on 10 July 2017 with responses due by 4 August 2017.","N/A","ISG","2018-02-22","TBC",{"$nulls":9},"ISG"]
["CP1492","Causes and treatment of large Line Loss Factors","ELEXON","2017-06-21","Line Loss Factors (LLFs) are values which are calculated and applied to Metered Volumes, scaling the Metered Volumes to account for distribution losses.  An LLF greater than 1 is typical of importing sites as more energy must be dispatched than required to account for the losses that will occur along the way. Exporting sites are normally assigned an LLF value smaller than 1.\nThe Supplier Volume Allocation Group (SVG) discussed two large SVA LLF values calculated for the forthcoming 2017/18 BSC Year (see SVG191 Headline Report). The SVG noted that the values were calculated correctly in accordance with BSCP128 and that there was therefore no audit non-compliance. The SVG also noted that the values were below the Data Transfer Catalogues (DTC’s) permitted maximum. However, SVG Members expressed concern over whether these values were representative of the losses caused by the site. The SVG recommended setting an Issue Group to discuss the problem. The Issue 65 Group agreed that a CP should be raised.","The proposed solution is to amend BSCP128 to introduce a 17th Principle to specifically address scenarios whereby low energy consumption/generation values for a Seasonal Time of a Day (STOD) period create a resultant LLF value that may not be reflective of the actual losses at the site. Amendments will be required also to BSCP128 Appendixes 1, 3 and 10 to reflect the necessary Audit steps that would be required alongside the extra principle. ","CP1492 was raised on 21 June 2017. It will be presented  for information to the ISG on 25 Jul 17 and to the SVG on 1 Aug 2017. ","N/A","ISG/SVG","2018-02-22","TBC",{"$nulls":13},"ISG",null,"SVG"]
["Closed Change Proposals"]
[1481,"Housekeeping Change to BSCP536 following approval of P339","ELEXON","2016-12-14","After approval of the P339 and the corresponding redlining, an error in the redlining to BSCP536 was identified. \nThe approved redlined changes to BSCP536 incorrectly redefined a definition to include both Active Export and Active Import, where it previously only included Active Import. The intent of P339 was not to change the definition but simply to remove the references to specific CCC IDs. There will be no change to the calculation of Supplier Charges. \n","CP1481 proposes to include the words ‘Active Import’ in the approved redlining for BSCP536 to correct a manifest error. "," SVG on 3 January 2017 and approved by PAB on 26 January 2017.","N/A","SVG/PAB","2017-04-01","Approve"]
[1473,"Alteration to the LTV Entry Criteria"," British Gas","2016-10-05","The LTV process today is reliant on the Site Visit Agent entering the correct SVCC once a site visit is completed. It is common for the Visiting Agent to enter an SVCC of ’20 – No Access’ with supporting evidence suggests that the site is vacant. Two D0004s with a check code of ’02’ can be received 75 calendar days apart but due to the receipt of a ‘20’ during this period the site does not qualify as vacant.\n\nThis unnecessarily prolongs timescales to enter a site as LTV as the process must be reset. In the worst case scenario the two consecutive ‘02’ may never be achieved. ","This Proposal is to alter the qualification criteria to be more reflective of the ‘Remain’ criteria.  A Site will be able to be enter into the LTV process even if D0004s with SVCC’s of 18, 19, 20 and 28 are received in between the two qualifying D0004s with a SVCC 02. Proactive attempts to identify the owner to obtain meter reads via mail or phone will still be required.","SVG","CPC00771","SVG","2017-02-23","Approve"]
[1472,"Removal of SVA proving tests for Meters with a pulse multiplier of one","NPower","2016-09-14","The BSC Audit Issue Review Group has been looking at whether proving tests are necessary in all cases. They have proposed that only the following scenarios require proving tests:\n• Complex sites\n• Where the Outstation can have a pulse multiplier other than 1\n• Meters with a separate Outstation\n","BSCPs 502, 514 and 601 have been redlined to remove the requirement for proving test for meter that only have a pulse multiplier of one. A new process for the validation of complex sites has been proposed.","ISG and SVG","CPC00771","ISG/SVG","2017-02-23","Approve"]
[1471,"Housekeeping - discrepancies in the requirements of the CRA URS","ELEXON","2016-05-10","There appears to be discrepancies in the requirements of the CRA URS, and the content of the NETA IDD, and what the systems and Service Provider deliver. ","Amendments to CRA URS Sections are 1)Section 5.13 CRA-F013: BM Unit Registration  2)Section 5.14 CRA-F014: View / Maintain BM Unit Registration 3) Section 5.21 CRA-F020: Maintain Credit Assessment Load Factor 4) Section 5.23 CRA-F022: Issue Credit Assessment Capability","ISG and SVG","n/a","ISG","2017-02-23","Approve"]
[1470,"Housekeeping Change to CoPs 1, 2, 3 and 5 following P266","ELEXON","2016-05-12","A manifest error was introduced into CoPs 1,2,3 and 5 as a result of P266 in February  2012. The errors, in all of the aforementioned CoPs, are in the sections that reference Overall Accuracy.","Housekeeping change to direct the references to other sections. For instance, 4.2.1 should note 4.3.1. Therefore, the solution changes references in CoPs 1, 2, 3 and 5.","SVG ","n/a","ISG/SVG","2017-02-23","Approve"]
[1468,"Adoption of a standard template for raising Modifications","ELEXON","2016-07-06","Phase 3 of Ofgem’s Code Governance Review (CRG3) made several proposals to improve governance arrangements across all the codes that under pin the gas and electricity industry arrangements. Although there are currently similar arrangements across all codes for raising Modifications they are not standardised. Ofgem has concluded that all Code Administrators should use standard templates for raising Modifications. The new template has been developed with input from across the Code Administrators and Ofgem has now instructed it should be adopted by all Code Administrators.","For the BSC, this will require that we remove the Modification proposal form (BSCP40/03) from BSCP (BSC Procedure) 40 ‘Change Management’. BSCP40 will instead make reference to the templates, which will be required to be made available on the BSC Website.","ISG Sep","CPC00769","ISG/SVG","2016-11-03","Approve"]
[1467,"Inclusion of site ID data within the BSCP11/07 'TDC Trading Dispute Findings' form","ELEXON","2016-06-14","As a result of CP1459 Consultation responses, it was identified that the MPAN details are not included in the BSCP11/07 form and it was suggested by one of the MOAs that this should be included","Include MPAN details relating to the Trading Dispute in the BSCP11/07 form.","TDC: 1 September 2016 ","CPC00768","SVG","2016-11-03","Approve"]
[1466,"Removing SMETS compliant Meters from the scope of BSCP601 ‘Metering Protocol Approval and Compliance Testing’","ELEXON","2016-05-18","The SRAG concluded that protocol approval and compliance testing were not appropriate for SMETS compliant Meters.","Remove SMETS compliant Meters from the scope of BSCP601."," Panel approved CP1466 on 8 December 2016","CPC00770","SVG/ISG","2017-02-23","Approve"]
[1465,"Sending revised Meter Technical Details following a change of Meter Operator Agent ","ELEXON","2016-06-13","An ELEXON/MRA joint initiative identified that the requirement in BSCP514 footnote 30 does not take into account those occurrences where the old MOA has not sent revised MTD by the de-appointment date or (unknowingly) carries out the Meter exchange after the de-appointment date. The requirement would therefore benefit from being extended to include these situations. CP1455 looked to address this by amending the footnote. However, that had unforeseen consequences. This CP proposes a different approach.","Rather than amend the footnote, this CP proposes to add an additional footnote to the relevant sections in BSCP514.","SVG approved CP1465 on 6 September 2016","CPC00768","SVG/ISG","2017-02-23","Approve"]
[1464,"Requiring HH consumption data to be processed to appropriate precision","ELEXON","2016-05-17","The SRAG identified an issue with the data flow granularity for HH consumption data, relating to the fact that smaller customers will need their HH consumption data processed to the nearest Watt hour (Wh).","Include a statement in BSCP502  ‘HH Data Collection for SVA Metering Systems registered in SMRS’ to place an obligation on Suppliers/HHDCs to process data to the nearest Wh where data to that granularity can be obtained from the Meter. Changes required to address getting HH data from DCC enrolled smart meters into Settlement and allow them to be validated and estimated. The SVG rejected CP1464 on 6 September 2016.","SVG: 06 Sep 16 "," CPC00765 - 8 Apr 16 ","Panel","2016-12-22","Reject"]
[1463,"Process for ELEXON to calculate category 1 non-compliance materiality","ELEXON","2016-05-09","Following approval of CP1454 that transferred responsibility for materiality calculations of the category 1 non-compliances from the (TAA to ELEXON, it has been noted that the methodology for the calculations has not been included within the BSCP27, and that there is no documented process for ELEXON to request data for the calculations. ","The calculations methodology to be included within The BSCP27 and the process for ELEXON requesting data required for calculations to be documented within BSCP27. ","SVG: 6 September.","CPC00768","ISG/SVG","2016-11-03","Approve"]
[1462,"Allow the CDCA to break and remake Metering Equipment seals to access local interrogation port","ELEXON","2016-05-09","With certain CVA Metering System Outstations a seal(s) has to be broken in order to access the Outstation’s local interrogation port to download metered data.\nWhere a communications link has not yet been installed for a new Metering System, or there is a communications link fault, the CDCA can, with the agreement of the Registrant, break a seal(s) to access the Outstation’s local interrogation port and download the metered data. Then, the CDCA can leave the Outstation’s local interrogation port unsealed until the CVA MOA can attend the site and reseal the Outstation’s local interrogation port. The Outstation’s local interrogation port is password protected so the risk to Settlement of leaving the local Outstation’s interrogation port unsealed is very low.\n","To avoid the unnecessary expense of the CVA MOA attending sites to reseal the Outstation’s local interrogation port (or other seals which are required to be broken to get to the Outstation’s local interrogation port), this CP proposes to change BSC Procedure BSCP06 ‘CVA Meter Operations for Metering Systems Registered in CMRS’ to allow the CDCA to break and remake seals, where necessary, in order to carry out on-site interrogation of Outstations.","ISG","CPC00768","ISG","2016-11-03","Approve"]
[1461,"Amending BSCP128 to reflect a new simple SVA file format for LDSO LLF submissions’","ELEXON","2016-05-05","Where an Embedded LDSO mirrors the relevant Host LDSO’s LLFs, it can create the D0265 flow by repeating the data already held by ELEXON. To generate this D0265 file, Embedded LDSOs require their own systems or else manually copy and paste the data. This process creates additional burden and introduces the potential for errors.\n\nELEXON has developed a central system that can create D0265 flows on behalf of Embedded LDSOs. ","The simple file format approach developed by ELEXON has operated successfully for a number of years. As such, we believe it should be formalised within BSCP128 so that the documentation reflects the current operational processes. ","ISG/SVG","CPC00767","ISG/SVG","2016-11-03","Approve"]
[1460,"Timely inclusion of SBR Actions\ninto imbalance cashout","Engie","2016-03-29","SBR Actions currently feed into the imbalance price using a manual process. The delay caused by this manual process means that the imbalance prices do not incorporate the pricing of SBR Actions at the prevailing VoLL until the Interim Information (II) Settlement Run, five Working Days (WDs) later.  ","Energie raised CP1460 on 29 March 2016. The Panel approved CP1460 for implementation on 22 December 2016, but noted that ELEXON will present a paper on the feasibility of this date at its May 2016 meeting. (10/06) At the June Panel meeting, ELEXON presented a paper advising that it is no longer possible to implement CP1460 for the Winter period 2016/17. The Panel therefore Rejected CP1460 as it is no longer required beyond this period.","Panel: 10 March 2016; 09 June 2016"," CPC00765 - 8 Apr 16 ","Panel","2016-12-22","Reject"]
[1459,"Amendments to the process for performing a Post-Final Settlement Run","ELEXON","2016-03-29","CP is looking to tidy up two issues: Due to an error in the red-lining for CP1428, the intention of the CP was not realised. There is now an erroneous obligation on ELEXON as the Disputes Secretary to alert DCs and DAs of Trading Dispute rectification details. In addition, following recent discussions at STAG regarding the Trading Disputes correction process and a number of Trading Disputes related to failures in the process, proposed amendments have been discussed.","Changes to BSCP11 to realise the intention of CP1428. This will remove the erroneous obligation on ELEXON. In addition, changes to the BSCP11 process by which TDC determinations on Trading Disputes are communicated through the Supplier hub. Under the new process, there will be a clearer obligations/timescales for BSC Parties to implement Settlement corrections and provide confirmation to ELEXON.","TDC: 2 June 2016.","CPC007661 - 11 Apr 16","TDC","2016-11-03","Approve"]
[1458,"Introduction of timescales for the P283 Commissioning process for SVA CT operated Metering Systems","ELEXON","2016-02-16","BSC Section L2.3.2 states that the Registrant must make ‘all reasonable endeavours’ to commission before energisation. However, it does not specify in what timescales Commissioning and its related activities should be completed. The findings from two TAPAP checks in 2015 highlighted a need for timescales throughout the end-to-end P283 Commissioning process","CP1458 seeks to introduce timescales in relation to activities performed during the Commissioning process and with the communications obligations introduced under Modification P283. The proposed timescales relate to the LDSO, MOA and Supplier activities and only apply to the SVA market and CT operated Metering Systems.","SVG:  6 September ","CPC00764 - 7 Mar 16; Version 2.0 CPC00768 - July","SVG","2016-11-03","Approve"]
[1457,"Changes to BSCP520 to support the introduction of Generic LED Charge Codes","ELEXON","2016-01-22","During the UMSUG's review of generic Charge Codes and Switch Regimes for LED lighting products, it amended the name of the Valid Dimming Combinations spreadsheet to the Variable Power Switch Regimes spreadsheet. This is referenced within BSCP520.","References to the Valid Dimming Combinations spreadsheet and to Valid/Invalid Dimming Combinations will be amended or removed within BSCP520. CP1457 was approved by the SVG as a Housekeeping CP on 02 Feb 16 for implementation on 30 Jun 16.","SVG: 02 Feb 16 ","n/a","SVG","2016-06-30","Approve"]
[1456,"Clarification to BSCP514 regarding the sending of Meter Technical Details on receipt of a D0170 data flow","ELEXON","2016-01-15","The clarification that it is sufficient to use the D0170 data flow alone for inter-agent transfer of Meter Technical Details (MTDs) was added to section 3.2.3 of BSCP504 in 2003. However, this clarification was not inserted into BSCP514 for MOAs under the ‘change of MOA’ section in the same way as BSCP504 did. ","CP1456 proposes to amend BSCP514 to align the MOA obligations with those for NHHDCs (as detailed in BSCP504) that Meter Technical Details should be sent on receipt of a D0170 data flow. CP1456 was issued for CP Consultation on 8 February 2016, with responses due by 4 March 2016. CP1456 was approved b the SVG at its meeting on 5 Apr 16 for implementation on 30 Jun 16. "," ISG: 22 March 2016; SVG: 5 April 2016","CPC00763 -     8 Feb 16","SVG","2016-06-30","Approve"]
[1455,"Sending revised Meter Technical Details following a change of MOA","ELEXON","2016-01-14","An ELEXON/MRA joint initiative identified that the requirement in BSCP514 footnote 30 does not take into account those occurrences where the old MOA has not sent revised MTD by the de-appointment date or (unknowingly) carries out the Meter exchange after the de-appointment date. The requirement would therefore benefit from being extended to include these situations.","CP1455 proposes to amend and enhance the requirement in BSCP514 footnote 30 for the current MOA to send the revised MTD when a Meter exchange is carried out after the transfer of MTD to the new MOA. The SVG rejected this change at its meeting on 5 July  2016. In its place, CP145 was progressed by the SVG to the Assessment stage.","SVG: 5 July 2016","CPC00763 -     8 Feb 16","SVG","2016-02-23","Reject"]
[1454,"Amendment to the Category 1 Materiality Calculation","ELEXON","2016-01-11","Historically, the TAA calculated the materiality of category 1 non-compliances using a calculation which provided an estimated value. ELEXON identified that the materiality calculation had been removed from BSCP27. However, the Working Instruction used by the TAA was never updated and we have been unable to locate any communication advising the TAA of a change. Therefore the materiality calculation continues to be used.\n","CP1454 proposes that a calculation is performed by ELEXON in the same way that the materiality of a Trading Dispute is calculated, in order to provide a more accurate materiality of each category 1 non-compliance. This CP will therefore require changes to BSCP27 to reflect this. CP1454 was issued for CP Consultation on 8 February 2016, with responses due by 4 March 2016. CP1454 was approved by the ISG at its meeting on 22 March 2016 and was approved by the SVG at its meeting on 5 Apr 2016 for implemenation on 30 Jun 16. "," ISG: 22 March 2016; SVG: 5 April 2016","CPC00763 -     8 Feb 16","ISG/SVG","2016-06-30","Approve"]
[1453,"Changes to SAA Service Description and SAA URS for P269 systems fix","ELEXON","2016-01-07","On 1 June 2015, the sum of BM Unit Relevant Capacities in a Base Trading Unit exceeded zero for the first time. The solution implemented by P269 failed to have its intended effect, and the P/C Status of all (non-Exempt Export) Supplier BM Units in the North Scotland GSP Group ‘flipped’ from Consumption to Production. ","CP1453 proposes to ensure that the detailed SAA system design and specification documents fully capture the steps used by the SAA to determine and use P/C Status as part of implementing the enduring solution for the P269 systems fix. ","ISG: 23 February 2016","CPC00762 -    11 Jan 16","ISG","2016-04-12","Approve"]
[1452,"Aligning BSCP502 with amendments to the Electricity Supply Licence","ELEXON","2015-11-18","There is currently an Electricity Supply Licence requirement (Standard Licence Condition (SLC) 12.14-16) for Non Half Hourly (NHH) Meters to be inspected every two years. This is also reflected in BSCP502. Following concerns that this requirement undermines the smart metering business case Ofgem issued a consultation to change the licence condition. It is expected that this change will be approved in early February 2016.","ELEXON raised CP1452  in  order to align the BSC with the proposed SLC amendments and to clarify the requirements for Measurement Classes C, E, F and G. The SVG approved CP1452 at its meeting on 02 Feb 16 for implementation on 30 Jun 16.","SVG: 02 Feb 16.","CPC00761 -    7 Dec 15","SVG","2016-06-30","Approve"]
[1451,"Allowing HH Default EACs for all HH Measurement Classes","ELEXON","2015-10-02","When CP1432 was progressed, we believed that a HH Default EAC would only be needed for Measurement Classes C, E, F and G. Following the approval of CP1432, it was identified by one participant that a value for Measurement Class D should also be provided. We agree that including such a value would be beneficial for completeness, as the original single value would have been applicable to all HH Measurement Classes, including Measurement Class D.","CP1451 proposes amendments to the MDD Entity 59 form in BSCP509 Appendix 1 to clarify that a HH Default EAC value can be registered for all HH Measurement Classes, rather than only for a specified sub-set.","SVG: 25 Feb 16.","CPC00760 -    5 Oct 15","SVG","2016-02-25","Approve"]
[1450,"Security Requirements for CoP10 Metering Equipment","ELEXON","2015-09-18","SMETS2 Meters do not meet the exact ‘Security Regime Requirements’ in Section 5.6 of CoP10, which requires the use of three levels of password to control access. The SVG agreed that, by exceeding the security requirements in CoP10, a SMETS2 Meter would be compliant with CoP10. The SVG asked us to raise a CP to include an explicit statement to this effect in CoP10.","CP1450 proposes to amend CoP10 Section 5.6 to state that Metering Equipment shall either comply with the SMETS, and therefore the security requirements; or allow for at least the levels of access currently defined. This will remove a barrier to elective Half Hourly Settlement for domestic and small non-domestic Metering Systems. The change will ensure that Meters that comply with the SMETS will also meet the CoP10 security requirements.","SVG: 25 Feb 16.","CPC00760 -    5 Oct 15","SVG","2016-02-25","Approve"]
[1449,"Updates to BSCP520 and the SVA Data Catalogue following a review","ELEXON","2015-09-18","After reviewing BSCP520 and speaking with UMSOs and the UMSUG, we believe this document does not reflect current operational practice for certain processes. To reduce ambiguity in the Settlement arrangements and improve efficiency, we believe it would be appropriate to align this document with current operational practice.","CP1449 proposes to remove some SVA data flows relating to UMS for which the information is, in practice, being sent by email without adhering to the flow structure. These have been identified following discussions with UMSOs and the UMSUG. We have also taken this opportunity to include some housekeeping and clarification changes.","SVG, 25 Feb 16.","CPC00760 -    5 Oct 15","SVG","2016-02-25","Approve"]
[1448,"Changes to allowable software for Method 3 Proving Tests","ELEXON","2015-09-09","Currently, there are ambiguities in the requirements between ‘Method 3’ and ‘Method 4’ of\nBSCP502 and BSCP514 for software used by MOAs for proving tests.  ","CP1448 proposes changes to BSCP514 and BSCP502 such that it will be a requirement for the MOA to use data retrieval software that is approved under BSCP601 for proving test ‘Method 3’. This will remove any risk to Settlement where unauthorised software may be used for a proving test.","SVG, 01 Dec 15 ","CPC00760","SVG","2016-02-25","Rejected"]
[1447,"Amendment to the timescales for sending the D0010 from Supplier to NHHDC on a Smart Change of Supply event","npower","2015-09-02","As part of P302, process steps have been created which detail the need for the new Supplier to send a D0010  data flow to the new NHHDC and old Supplier one Working Day after Meter reconfiguration. At this point in the new process the new Supplier will not have received the MSN from the new NHHMOA. It will therefore need to find the MSN from another source or use a dummy MSN to populate the D0010 data flow as the MSN is a mandatory field.  ","CP1447 proposes a limited change to the solution approved under P302 by amending the timescale for sending the D0010 data flow for smart Meters from 1WD to 3WD on a CoS.\nThis will enable the Meter readings to be sent with the Meter Serial Number installed on site that is contained in the Meter Technical Detail data flows as these should have been received within 3WDs. This makes the process more flexible so it can function prior to the anticipated DCC change to the Read Inventory command. CP1447 was approved by the SVG on 03 Nov 15 for implementation on 30 Jun 16.","−","CPC00759 -     7 Aug 15","SVG","2016-06-30","Approve"]
[1446,"Allow smart CoS agreed Disputed Reads to be entered into Settlement","EDF Energy","2015-08-13","Following the approval of P302 the MRA’s IREG reviewed MAP08 to identify any necessary consequential changes. This review highlighted that, where a disputed reading has been agreed for a Metering System that has gone through the P302 CoS process, a replacement reading will not always be able to be produced for all relevant parties. The D0086 data flow passed from the new NHHDC to the old NHHDC may not match the old Supplier’s configuration and will therefore fail validation. This will lead to discrepancies between the readings, and also uncertainty for the old Supplier as to what reading has been used by the new Supplier, as the Disputed Reads process would not have closed.","CP1446 proposes to amend the process for correcting disputed CoS reads for smart Meters that will be introduced by P302. These changes will allow each Supplier (old and new) and its Supplier Agents to be able to process any corrections independently of the other. This will remove the risk of flows failing validation due to the two Suppliers using different configurations for the Meter. CP1446 was approved by the SVG on 03 Nov 15 for implementation on 30 Jun 16.","−","CPC00759 -     7 Aug 15","SVG","2016-06-30","Approve"]
[1445,"BSCP516 alignment with revised P272 Implementation Date","ELEXON","2015-07-24","A full review of BSCP65 needs to be carried out to ensure that the processes are clarified and are brought in line with Section A of the Code. Inconsistencies have been identified as part of the BSC review (in particular with regard to Withdrawal from Acceded Status).","CP1445 proposes to amend references to the P272 Implementation Date within BSCP516 from ‘1 April 2016′ to ‘1 April 2017′ to reflect the extension granted to this date.","−","N/A","SVG","2016-08-11","Approve"]
[1443,"Standard Settlement Configurations for smart and advanced Meters","ELEXON","2015-05-12","With the introduction of smart metering, the DCC will process requests from Suppliers to remotely switch registers and control load. In addition, it will send commands to be applied by the relevant smart Meter. When an MOA replaces an RTS Meter with a smart Meter, the\nSupplier can retain the Metering System on its existing RTS SSC. The MOA can then\nconfigure the smart Meter’s switching calendar so that the load (and/or time-of-use\nregisters) is set to the same time as the RTS group to which the Metering System\npreviously belonged. However, this presents a number of problems that need addressing. ","CP1443 proposes to add a new requirement to section 4.2 of BSCP516 which will avoid mixing RTS and smart Metering Systems on the same SSC, and so facilitates Supplier reporting of RTS migration. CP1443 was approved by the SVG on 04 Aug 15 for implementation on 25 Feb 16.","−","CPC00758 -  10 Aug 15","SVG","2016-02-25","Approve"]
[1444,"Extend the timescale of CoP10 Proving Tests until the implementation of P272","Haven Power","2015-07-07","It is likely that the Proving Test itself would be rushed due to time constraints during peak times, which could introduce errors. Secondly, the CoMC process quality could be compromised by the burden placed on the Agent having to jointly contribute to the CoMC work as well as complete the Test in the existing timescales.","CP1444 proposes to extend the timescales in which to carry out a proving test for a CoP10 Metering System. These extended timescales would only be effective until P272 has been implemented. Once P272 has been implemented, these timescales would revert to those originally approved under CP1429.","SVG: 04 Aug 15","CPC00758 - 10 Aug 15","SVG","November 2015 Release","Approve"]
[1442,"Clarifying the application process for Metering Dispensations","ELEXON","2015-04-30","The BSCCo often experience delays and inefficiencies in the Metering Dispensation application\nprocess resulting from the exclusion of essential information from the initial application form (BSCP32/4.1.). As a result, processing times and costs are increased for the BSCCo, with delays for the raising Party. ","CP1442 proposes to update the guidance provided within BSCP32 on how to populate the Metering Dispensation application form for submission. This guidance will help to inform the applicant of the level of detail required for the BSCCo to progress the application and for the relevant Panel Committee(s) to make an informed decision.","ISG: 26 May 15              SVG: 2 Jun 15","CPC00757 - 8 Jun 15","ISG/SVG","November 2015 Release","Approve"]
[1441,"Allowing the Peer Comparison technique to be reported on a Supplier Agent level","ELEXON","2015-04-28","The current provisions in BSCP533 ‘PARMS data provision, reporting and publication of Peer Comparison data’ only permit the Peer Comparison technique to be performed at a Supplier level. However, the Peer Comparison PARMS Serials (BSCP533 5.15) report performance at a Supplier Agent level which is then aggregated to a Supplier level.","CP1441 proposes to amend Balancing and Settlement Code Procedure (BSCP) 533 to introduce Supplier Agents into the publication criteria of Peer Comparison.","PAB: 28 May 15               SVG: 2 Jun 15","CPC00757 - 8 Jun 15","PAB/SVG","November 2015 Release","Approve"]
[1440,"Exempting Metering Systems in Measurement Class F from proving tests","ELEXON","2015-04-28","BSCP514 requires Half Hourly Meter Operator Agents (HHMOAs) to perform a proving test under various circumstances. Proving tests will not deliver value for domestic HH Metering Systems in Measurement Class F. This is because data retrieval will be centralised for domestic Metering Systems which have smart Meters serviced by the Data and Communications Company (DCC). As such, the communications details, which are tested by a proving test, will not pass between different agents as they do for HH Metering Systems in Measurement Classes C, E and G. The cost of proving tests for domestic Metering Systems is likely to outweigh the benefit the tests will bring, given the low metered volumes associated with individual Measurement Class F Metering Systems.","CP1440 proposes to introduce an exemption from proving tests for Metering Systems in Measurement Class F.","−","CPC00756 - 5 May 15","SVG","November 2015 Release","Approve"]
[1439,"Proving Test Permissible Software","SmartestEnergy","2015-04-10","The Change of Measurement Class (CoMC) process from Non Half Hourly (NHH) to Half Hourly (HH) requires a proving test to take place. BSCP514 ‘SVA Operations for Metering Systems Registered in SMRS’ lists four different methods for carrying out proving tests. Method 4 allows the HH Meter Operator Agent (MOA) to use the manufacturer’s software to read information from the Meter as part of the proving test. However, the Meter manufacturer software only allows for one Metering System to be dialled at a time; this means that carrying out proving tests for a large number of Metering Systems will be a time consuming and laborious process.","CP1439 proposes to amend BSCP514 to allow the Half Hourly Meter Operator Agent (HHMOA) to also use other BSCP601 approved software during the Proving Test process.","SVG: 28 Apr 15","CPC00756 - 5 May 15","SVG","November 2015 Release","Approve"]
[1438,"Clarification of information required for raising a Trading Dispute","ELEXON","2015-03-30","BSCP11 Section 5.1.1 requires a Raising Party to “Identify [the] alleged Settlement Error and\nraise a Trading Dispute” using Form BSCP11/01 and in accordance with BSCP11 Section 1.4.\nHowever, the wording of Section 1.4 does not make it clear that the alleged Settlement Error\nmust be identified, and this is only implied in the BSCP11/01 Trading Dispute form. These\ninconsistencies can impact the efficient investigation into alleged Trading Disputes. ","CP1438 seeks to align Sections 1.4 and 5.1.1 in BSCP11 to remove ambiguity and clarify that in order for a BSCP11/01 form to be accepted by ELEXON it must identify a breach of the BSC or Code Subsidiary Document and indicate the relevant Settlement Error.","TDC: 30 Apr 15","CPC00756 - 5 May 15","TDC","November 2015 Release","Approve"]
[1437,"Recommended amendments to BSCP68","ELEXON","2015-03-16","Following the rejection of CP1423, it was recommended by the Imbalance Settlement Group (ISG) and the Supplier Volume Allocation Group (SVG), that the contents be separated into two changes and progressed separately. ","CP1437 proposes to add a footnote to BSCP68 Section 3.1.1.37 and 3.1.2.42 stating that in the described situation, the data flow described in BSCP515 is not required. The repeated steps will be removed from the appropriate procedures 3.1.1 and 3.1.2. After removing these steps, the remaining steps will be renumbered accordingly, and any references will be amended to match.\n","−","−","ISG/SVG","November 2015 Release","Approve"]
[1436,"EAC/AA and NHHDA Applications – Windows Server upgrade","ELEXON","2015-03-05","The Non Half Hourly Data Aggregator (NHHDA) and Estimated Annual Consumption (EAC)/Annualised Advances (AA) software applications are designed to support running on a ‘Solaris only’ and a ‘Solaris/Windows Server’ platform. Two out of the 13 NHHDAs currently operate on Windows Server 2003 and the support to Windows Server 2003 will expire in July 2015. ELEXON understands that the two NHHDAs will be upgrading their systems to Windows Server 2012, which will be supported until 2023. Therefore CP1436 proposes that ELEXON and its Application Management and Development (AMD) service provider will develop, test and deploy new versions of the NHHDA and EAC/AA applications that are compatible with a currently supported version of Windows Server.","CP1436 proposes that ELEXON and its Application Management and Development (AMD) service provider will develop, test and deploy new versions of the NHHDA and EAC/AA applications that are compatible with a currently supported version of Windows Server.","SVG: 03 Mar 15","CPC00754 - 09 Mar 15","SVG","November 2015 Release","Approve"]
[1435,"Amendments to the SAA-I042 flow","ELEXON","2015-03-03","Currently the SAA-I042 ‘BM Unit Gross Demand report’ data flow does not include any BM Units that have no gross demand, such as Supplier BM Units with no Import Metering System Identifiers (MSIDs) assigned to them, or Central Volume Allocation (CVA) BM Units that are net generators in the Settlement Period. This behaviour is consistent with the Interface Definition and Design (IDD) document and Settlement Administration Agent (SAA) User Requirements Specification (URS).\nHowever, testing for the new Electricity Market Reform (EMR) system has revealed that it is not consistent with this behaviour. This issue has the potential to lead to invoicing of incorrect Contracts for Difference (CFD) charges to Suppliers, and therefore needs to be resolved.","CP1435 proposes amendments to the SAA-I042 data flow to ensure that the Contracts for Difference (CFD) Settlement Services Provider has a complete set of BM Unit data for use in calculating CFD charges.","−","CPC00754 - 09 Mar 15","ISG","June 2015 Release","Approve"]
[1434,"Amend the three digit numeric Line Loss Factor Class (LLFC) Id to an Alphanumeric LLFC Id","SSEPD","2015-02-16","The current limitation of available LLFCs needs to be resolved. The risk of not doing so means a temporary workaround will be needed until an enduring solution is in place. This may impose additional billing and administration costs on BSC Parties. If an enduring solution is not achieved DSOs may have to seek long term workaround, potentially increasing costs, inefficiencies and business risks.","CP1434 proposes to amend the format of the LLFC ID from a three-digit integer value to a three-digit alphanumeric value (consisting of the digits 0-9 and the capital letters A-Z excluding I and O). This will increase the number of LLFCs from 999 to 39,303. CP1434 was approved by the Panel on 11 Jun 15 for implementation on 30 Jun 16.","Panel: 11 Jun 15","CPC00757 -    8 Jun 15  ","SVG","2016-06-30","Approve"]
[1433,"Clarification of which Metering Systems are captured by the P272 requirements","ELEXON","2015-02-16","Many Meters installed to date are capable of recording the MD, and many of these record the\nMD without a requirement to do so. Therefore, it can be unclear as to which PC a Metering\nSystem should be allocated to and therefore which is captured by the P272 requirements. ","CP1433 proposes to clarify which Metering Systems are captured by the P272 requirements.","SVG: 03 Mar 15","CPC00754 - 09 Mar 15","SVG","June 2015 Release","Approve"]
[1432,"HH Default EAC by Measurement Class","ELEXON","2015-02-16","With the increase in the number of non-100kW HH Metering Systems as part of implementing\nP272 ‘Mandatory Half Hourly Settlement for Profile Classes 5-8’, the HH Default EAC that\ncovers all HH Metering Systems will be too high for these and will increasingly become too low\nfor the 100kW HH Metering Systems.","CP1432 proposes to allow for HH Default EAC by Measurement Class. As with the migration of PC5-8 Metering Systems under P272, the number of non-100kW Metering Systems will result in the current HH Default EAC being too low for 100kW sites and too high for the non-100kW sites.","SVG: 03 Mar 15","CPC00754 - 09 Mar 15","SVG","November 2015 Release","Approve"]
[1431,"Extend Site Check Exemption to Measurement Classes F and G","ELEXON","2015-02-16","Under Approved Modification P300 ‘Introduction of new Measurement Classes to support Half\nHourly DCUSA Tariff Changes (DCP179)’, Measurement Class E is in effect being split into\nthree Measurement Classes for non-100kW metered sites. At the time of progressing P300,\nchanges to BSCP502 to extend the exemption to Measurement Classes F and G were not\nidentified.\n","CP1431 proposes to extend the exemption to carry out HH Metering System checks to also include Measurement Classes F and G.","SVG: 03 Mar 15","CPC00754 - 09 Mar 15","SVG","November 2015 Release","Approve"]
[1430,"Clarification to the ECVN/MVRN processes","ELEXON","2015-02-09","A ‘Lessons Learned’ exercise was conducted following the consideration of Trading Dispute DA618. The exercise took account of the views of both BSC Panel Members and Trading Disputes Committee (TDC) Members. The exercise concluded that BSCP71 is unclear on how reallocations between energy accounts can be terminated. It is not clear that the submission of a Metered Volume Reallocation Notification Agent (MVRNA) Authorisation Termination Request will end only the authorisations for the agent, leaving any existing MVRNs in place. As a result, Parties may fail in their initial attempt to cancel these notifications. The ECVAA Service Description and User Requirement Specification are also unclear on the effect of Termination Requests. As a result, it may be unclear what request is suitable for a Party’s intentions.","CP1430 proposes to clarify instances of ambiguous or unclear advice regarding the Energy Contract Volume Notification (ECVN) and Metered Volume Reallocation Notification (MVRN) processes. In particular CP1430 will better enhance the clarity of the methods for terminating these notifications.","ISG: 20 Feb 15","CPC00754 - 09 Mar 15","ISG","November 2015 Release","Approve"]
[1429,"Proving Test timescales ","ELEXON","2015-01-16","CP1411 ‘Remove Exemption from Proving Tests for Code of Practice 10 Metering Systems’ removed the exemption from proving tests for Code of Practice (CoP) 10 Metering Systems in BSCP514 ‘SVA Meter Operations for Metering Systems Registered in SMRS’ so that proving tests are mandatory for all Half Hourly (HH) Metering Systems. As part of the consultation responses to this CP, it was identified that an entry for CoP10 was required to the table in section 8.3.5 of BSCP514 which details the timescales for proving tests.\n","CP1429 proposes to add Proving Test timescales for CoP10 Metering Systems to section 8.3.5 of BSCP514 and amend BSCP514 section 8.3.5 footnote 79 to include the commissioning date in the list of trigger events. ","SVG: 03 Feb 15","CPC00753 - 09 Feb 15","SVG","June 2015 Release","Approve"]
[1428,"\nInclusion of Party Agents in the event of Post Final Settlement Runs\n","RWE npower","2015-01-15","If a Trading Dispute is upheld, the Trading Dispute Committee (TDC) authorises corrective\naction to be taken to correct the Settlement Error. Some corrective actions cover a Post Final\nSettlement Run (PFSR). To enter the corrected values into the Settlement process, the Supplier\nmust inform their Agents of the corrective action as mentioned within BSCP11 and captured on\nthe BSCP11/07 Findings form. The Supplier informs their Data Collector (DC) to perform the\ncorrective action. An ambiguity has been identified when the DC and Data Aggregator (DA)\nresponsibilities are administered by different companies. The Supplier informs their DC but\ninadvertently forget about the DA. The DA then receives a request from the DC to perform\nPFSR for a given period and questions or reject it because they have ceased performing PFSR.","CP1428 proposes amendments to the existing BSCP11 to mandate that, when the Trading Disputes Committee (TDC) authorises to correct a Settlement Error, a Supplier must inform both their DA and DC to perform such corrective actions. ","TDC: 05 Feb 15","CPC00753 - 09 Feb 15","TDC","June 2015 Release","Approve"]
[1427,"Housekeeping change to BSCP503 for EMR","ELEXON","2015-01-14","Changes to the BSC and its Code Subsidiary Documents (CSDs) to support the Electricity\nMarket Reform (EMR) arrangements were directed by the Secretary of State on 1 August 2014\n(Other Regulatory Decision (ORD) 005). Unfortunately, it has been identified that the data being requested in MWh in the new step is incorrect and should instead be in kWh as per the new D0357 data flow to which this new step relates. Although this manifest error was picked up as part of the Electricity Intensive Industry (EII) changes to be directed by the Secretary of State (most likely as part of the June 2015 BSC Systems Release), this will leave an inconsistency in the period between February 2015 and June 2015.","CP1427 proposes to make a housekeeping change to correct the manifest error in BSCP503 to amend the new step in 3.4.2.3A for EMR to state “in kWh” instead of “in MWh”.","−","N/A","SVG","February 2015 Release","Approve"]
[1426,"Receipt of the D0296 flow at II","Scottish Power","2015-01-12","Currently, the D0296 ‘Supplier BM Unit Report’ data flow is produced by the Supplier\nVolume Allocation Agent (SVAA) for all Settlement Runs, but is only made available to\nSuppliers for the Initial Settlement Volume Allocation Run (SF) and subsequent Volume\nAllocation Runs. However, Suppliers will need access to this data at the Interim Information\nVolume Allocation Run (II) in order to assist with the new EMR validation processes.\n","CP1426 proposes to amend the amend the routing data in the SVAA Data Marshalling Systems to make the D0296 data flow available to Suppliers at II. ","−","CPC00752 - 12 Jan 15","ISG/SVG","June 2015 Release","Approve"]
[1425,"Consequential changes to BSCP201 following EMR","ELEXON","2014-12-22","Changes to the BSC and its Code Subsidiary Documents (CSDs) to support the Electricity\nMarket Reform (EMR) arrangements were directed by the Secretary of State on 1 August 2014\n(Other Regulatory Decision (ORD) 005). This direction included changes to BSC Section G ‘Contingencies’. Subsequent consequential changes were therefore required to BSCP201 ‘Black Start and Fuel Security Contingency Provisions and Claims Processes’ to reflect the changes made to the BSC. Unfortunately, these changes were not identified at the time and did not form part of the direction.\n.","CP1425 proposes to make housekeeping changes to BSCP201 to reflect changes made to BSC Section G 'Contingencies'.","−","N/A","Panel","February 2015 Release","Approve"]
[1424,"Amending the requirement for Data Aggregators to perform annual Full SMRS refreshes","ELEXON","2014-11-14","This CP has been considered by the Software Technical Assurance Group (STAG) following\nELEXON’s concern that the SMRS refresh process introduces significant delays for Data\nAggregators in normal instruction processing. ELEXON notes that at the point where the SMRA\ngenerates the D0209 ‘Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator’ flow,\nData Aggregators have to suspend all other instruction processing until the refresh has been\nreceived, tested and applied. ","CP1424 proposes that, rather than refreshes being performed for all agents and all SMRAs at regular intervals, indicators of material Settlement errors will be the trigger instead such as D0095 ‘Non Half Hourly Data Aggregation Exception Report’ flows and D0023 ‘Failed Instructions’ flows. ","SVG: 2 Dec 14","CPC00749 - 08 Dec 14","SVG","June 2015 Release","Approve"]
[1423,"Amendments to BSCP68 following a review","ELEXON","2014-11-14","As BSCP68 has not been updated since 2009, ELEXON has taken this opportunity to review these\nprocesses.\n","CP1423 proposes to make housekeeping changes to BSCP68 to clarify procedures and amend steps so that they are consistent with other BSCPs.","ISG: 25 Nov 14,\nSVG: 2 Dec 14","CPC00749 - 08 Dec 14","ISG/SVG","−","Reject"]
[1422,"Add a DMP for an Offshore Transmission Connection Point to the HH Codes of Practice","ELEXON","2014-09-25","A new Defined Metering Point (DMP) is required in Appendix A of each Half Hourly Code of Practice (CoP) to cover Offshore Transmission Connection Point (OTCP). It would clarify where the DMP is for such connections so that a Metering Dispensation from this CoP requirement could be sought where the Actual Metering Point (AMP) is not at the DMP.","CP1422 proposes that the DMP for an OTCP shall be described in Appendix A of CoPs 1, 2, 3, 5 and 10 as: ‘For transfers between an Offshore Transmission System operator (or Offshore Transmission System User Assets) and a Distribution System operated by a Licensed Distribution System Operator, the DMP shall be at the point(s) of connection to that Distribution System operated by a Licensed Distribution System Operator.’","−","CPC00747 - 06 Oct 14","ISG/SVG","February 2015 Release","Approve"]
[1421,"Linking BSCP520 obligations to the Operational Information Document","ELEXON","2014-09-12","This CP proposed to strengthen the wording in BSCP520 to ensure that ELEXON obtains the appropriate test data from applicants and constructs Charge Codes and Switch Regimes in line with the guidance set out in the OID.","CP1421 proposed to strengthen the wording in BSCP520 to ensure that ELEXON obtains the appropriate test data from applicants and constructs Charge Codes and Switch Regimes in line with the guidance set out in the OID.","SVG: 30 Sep 14","CPC00747 - 06 Oct 14","SVG","February 2015 Release","Approve"]
[1420,"Allowance of mid-year LLF resubmissions due to material consumption or generation changes","ELEXON","2014-09-12","This CP proposes to change the wording in BSCP128 around material change to allow mid-year resubmissions for LLFs due to material change in consumption or generation for Site Specific sites. This would allow more reflective losses to be allocated and increase accuracy for Settlement.","CP1420 proposes to change the wording in BSCP128 around material change to allow mid-year resubmissions for LLFs due to material change in consumption or generation for Site Specific sites. This would allow more reflective losses to be allocated and increase accuracy for Settlement.","−","CPC00747 - 06 Oct 14","ISG/SVG","−","Reject"]
[1419,"Improving data accuracy by enabling the D0312 flow to be sent on a Change of Supplier","ELEXON","2014-08-20","Enhancements have been approved by the MRA Executive Committee to the Electricity Central Online Enquiry Service (ECOES) to facilitate the optional sending of the D0312 'Notification of Meter Information to ECOES' flow on a change of Supplier or Agent. These enhancements are due to go live as part of the February 2015 Release. Consequential changes to BSCP514 are required to facilitate this change.","CP1419 proposed changes to BSCP514 to facilitate the optional sending of the D0312 'Notification of Meter Information to Electricity Central Online Enquiry Service (ECOES)' flow on a change of Supplier or Agent.","SVG: 02 Sep 14","CPC00746 - 08 Sep 14","SVG","February 2015 Release","Approve"]
[1418,"Validation of D0041 flows","ELEXON","2014-07-01","There has been a recent issue with erroneous D0041 ‘Supplier Purchase Matrix Data File’ data flows being created by a Non-Half Hourly Data Aggregator (NHHDA) where an aggregation run was performed twice for the same Settlement Date and Settlement Run Type.","CP1418 proposes to introduce an additional step to the SVAA validation of the D0041 flow.","−","CPC00743 - 07 Jul 14","SVG","February 2015 Release","Approve"]
[1417,"Reading validation for smart Meters","ELEXON","2014-06-10","ELEXON required a clarification around remote disablement of smart Meters being treated as energised within Settlement.","CP1417 proposes to amend BSCP504 4.1 to place a high-level requirement on Suppliers to check for faults and prevent clock-drift when remotely contacting Meters. BSCP504 4.2 also needs amending to allow the Supplier to carry out pre-validation checks, add remote disablement to the list of valid conditions giving rise to zero Meter Advances; an add an equivalent obligation for Suppliers to act upon error flags from remotely read Meters. A mechanism will also be required for the Supplier to notify the NHHDC of readings from remotely disabled sites, so that zero advances do not fail validation.","SVG: 1 Jul 14","CPC00743 - 07 Jul 14","SVG","June 2015 Release","Approve"]
[1416,"Remotely disabled smart Meters","ELEXON","2014-06-10","ELEXON required a clarification around reading validations for smart Meters.","Cp1416 proposed to add a clarification to the energisation and de-energisation processes in BSC Procedure (BSCP) 504 ‘Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ and BSCP514 ‘SVA Meter Operations for Metering Systems Registered in SMRS’ to the effect that a remotely disabled smart or advanced Meter shall be treated as energised for the purpose of Settlement.","SVG: 1 Jul 14","CPC00743 - 07 Jul 14","SVG","June 2015 Release","Approve"]
[1415,"Reading submission frequency for smart Meters","ELEXON","2014-06-10","ELEXON required a clarification about frequency of readings for smart Meters.","CP1415 proposes to amend these requirements so that the decision about which readings to process should be made by the Supplier rather than the NHHDC, in those cases where the Supplier is retrieving the readings e.g. for smart Meters serviced by the Data and Communications Company (DCC).","SVG: 1 Jul 14","CPC00743 - 07 Jul 14","SVG","June 2015 Release","Approve"]
[1414,"Combining LDSO and Embedded LDSOs UMS Inventories on to single LDSO MSID.","ESP Electricity Limited","2014-05-21","ESP Electricity limited intend to raise a CP in support of their DCUSA CP, to add IDNO inventories to DNO MPANs. This will involve adding new process steps to BSCP520","CP1414 proposes to give Unmetered Supply (UMS) customers the option to trade their UMS connections from embedded Distribution Systems under a single distribution MSID. This would be achieved by combining such inventories of connections with the existing inventory linked to the already-registered host distributor’s MSID. This will involve adding new process steps to BSCP520.","−","CPC00749 - 08 Dec 14","SVG","−","Reject"]
[1413,"Amendments to BSCP535 ‘Technical Assurance’ following a review","ELEXON","2014-05-20","Following a review of BSCP535, changes are proposed to make a number of changes consisting of either; housekeeping changes; clarification changes; changes to reflects how the TAPAP process operates in practice; and process improvement changes. The changes were discussed by the PAB in April, and they agreed that a CP should be raised to take the changes forward.","CP1413 proposes a number of changes to make a number of changes consisting of either; housekeeping changes; clarification changes; changes to reflects how the TAPAP process operates in practice; and process improvement changes. ","SVG:3 Jun 14","CPC00741 - 03 Jun 14","SVG/PAB","November 2014 Release","Approve"]
[1412,"Reporting of deleted BOAs within the SAA-I014 report","ELEXON","2014-05-02","BSCP18 ‘Corrections to Bid-Offer Acceptance Related Data’ allows for the Transmission Company to amend erroneous Bid-Offer Acceptance (BOA) related data after a Settlement Period has been completed but prior to the Initial Settlement (SF) Run. It is also possible for BOA data to be amended after the SF Run as a result of a Trading Dispute.\nWhen a BOA is wholly or partly deleted, the SAA-I014 ‘Settlement Report’ sub flow 2 (file ID S0142) report will continue to report the relevant BO3 ‘BMU Period Bid-Offer Acceptance’ record with the N0390 ‘CADL Flag’ and the N0546 ‘Acceptance SO-Flag’ fields populated as normal.\nHowever, the NETA Interface Definition and Design (IDD) Part 2 ‘Interface to other Service Providers’ document states that where an acceptance has been deleted the ‘CADL Flag’ field in the BO3 record will be listed as null. This is inconsistent with what happens in practice.","CP1412 proposes to remove a discrepancy between the description in the NETA IDD Part 2 document and current practice regarding how deleted Bid-Offer Acceptances are reported in the SAA-I014 sub flow 2 report.","ISG: 27 May 14","CPC00741 - 03 Jun 14","ISG","November 2014 Release","Approve"]
[1411,"Remove Exemption from Proving Tests for Code of Practice 10  Metering Systems","SSE Energy Supply Ltd","2014-03-20","Metering Systems assigned to Code of Practice (CoP) 10 ‘Metering of Energy via Low Voltage\nCircuits for Settlement Purposes’ are currently exempt from proving tests. This exemption was reviewed by the Issue Group considering Issue 49 'Change of Measurement Class (CoMC) process for advanced Meters'. A number of Group members were of the view that proving tests should be applied for all HH Metering Systems, whether mandatory (above 100kW maximum demand) or elective (100kW maximum demand or below).\n","CP1411 proposes to remove the exemption from Proving Tests for Code of Practice (CoP) 10 Metering Systems in BSCP514 8.3.1 and BSCP502 4.6.1. Proving Tests will then be mandatory for all HH Metering Systems.","SVG: 1 Apr 14","CPC00740 - 7 Apr 14","SVG","June 2015 Release","Approve"]
[1410,"Transfer of Outstation Level 3 Passwords for Advanced Meters","ELEXON","2014-03-13","The Issue 49 Group identified a problem relating to the transfer of the J1713 data item ‘Outstation Password Level 3’ between the NHHMOA and HHMOA on a NHH to HH CoMC. NHHMOAs are understandably reluctant to lose control of the Meter too far ahead of their de-appointment date whereas HHMOAs need to receive the D0313 ‘Auxiliary Meter Technical Details’ flow far enough in advance of their appointment date to be able to determine whether they can support the existing Meter, decide whether they need to carry out a site visit, and to arrange the site visit. This creates conflicting requirements from the NHHMOA and HHMOA, which can put the CoMC process at risk.","CP1410 proposes a two-stage process for transferring the D0313 flow, which will provide the HHMOA with the information needed in sufficient time to plan for the CoMC date, whilst allowing the NHHMOA not to surrender control of the Meter until their de-appointment date.","SVG: 1 Apr 14","CPC00740 - 7 Apr 14","SVG","−","Reject"]
[1409,"CoMC process for advanced Meters","ELEXON","2014-03-13","The Issue 49 Group discussed and agreed that it would be useful and of value for Parties to have some clarification on the issues addressed prior to the potential implementation of P272. ","CP1409 falls out of the Issue 49 Group who were asked to ensure that the complexity (real or perceived) of the CoMC process does not act as a barrier to elective HH Settlement.","SVG: 1 Apr 14","CPC00740 - 7 Apr 14","SVG","June 2015 Release","Approve"]
[1408,"Excessively Large EAC/AA Control Points","ELEXON","2014-02-14","CP for  mitigating the risk of extremely large erroneous EAC/AAs entering Settlement.","CP1408 proposes to change the Non Half Hourly Data Aggregator (NHHDA) System to reject any Estimation of Annual Consumption/ Annualised Advances (EAC/AAs) that exceeds a certain consumption threshold entering Settlement.","SVG: 3 Feb 14","CPC00739 - 3 Mar 14","SVG","November 2014 Release","Approve"]
[1407,"Updates to current LLF audit templates","ELEXON","2014-02-03","ELEXON required to update to BSCP128 to reflect new templates for use during the annual LLF Audits. ","CP1407 proposes to create a set of compulsory templates with consistent formatting for the Licensed Distribution System Operators (LDSOs) to complete as part of the annual Line Loss Factor (LLF) audit. As such amendments have been made to the current BSCP128 Appendices and an additional three Appendices have been added.","−","CPC00737 - 3 Feb 14                             CPC00740 - 7 Apr 14","ISG/SVG","June 2014 Release","Approve"]
[1406,"Electronic version of the Self Assessment Document","ELEXON","2014-01-31","The new BSC Auditor is seeking for the Self Assessment Document to be put online. This is ready, but would need a CP to reference that user should/could use the online forms.","In addition to the current SAD submission process of submitting a Word document, CP1406 proposes to have an alternative version of the SAD available to complete electronically via the current Qualification Service Provider’s online tool. This CP will require amendments to BSCP537 to include the additional alternative option to complete and submit the SAD either electronically or via the Word document.","−","CPC00737 - 3 Feb 14","ISG/SVG/PAB","June 2014 Release","Approve"]
[1405,"Facilitating Faster Switching in the NHH Market","EDF Energy","2013-12-19","The current processes for appointing agents and passing Meter Technical Details (MTDs) or read histories as part of the Change of Supplier (CoS) process can take up to 27 working days at a maximum, which leads to potential inefficiencies in the process and adds dead time. The Department of Energy and Climate Change (DECC) is keen to improve switching times, especially for domestic customers. As part of a review of the full end to end processes, the current timescales have been considered as a potential barrier to implementing a faster switching experience. CP1405 proposes to introduce reduced timescales for the CoS process.","As part of a review of the full end to end processes, the current timescales have been considered as a potential barrier to implementing a faster switching experience. CP1405 proposes to introduce reduced timescales for the CoS process.","−","CPC00736 - 06 Jan 14","SVG","November 2014 Release","Approve"]
[1404,"Allowing Registration of Multiple Transmission System Boundary Point on one BSCP25 form and removal of requirement for OS coordinates for Grid Supply Points and onshore Transmission System Boundary Points.","National Grid","2013-12-11","BSCP251 requires a single form (BSCP25/5.1) to be submitted to ELEXON for each new Transmission System Boundary Point (TSBP). In the case of Offshore transmission connected windfarms, depending on the chosen location of the Boundary Point between the Offshore Transmission Operator (OFTO) and Generator, there may be significantly in excess of 10-12 Boundary Points for each new connection, although in physical terms each Boundary Point could be located on a single Offshore substation/platform within a few metres of each other.","CP1404 will amend BSCP25, to remove the requirement to submit individual BSCP25/5.1 Transmission System Boundary Point Registration forms for each TSBP being registered. This will mean that one single form can be submitted for each site and user covering all TSBPs that are being registered. The CP will also remove the requirement to provide a Ordinance Survey (OS) reference for Grid Supply Points (GSPs) and TSBPs that are being register onshore.","ISG: 17 Dec 13","CPC00736 - 6 Jan 14","ISG","June 2014 Release","Approve"]
[1403,"Additional requirements to BSCP15 and BSCP25 for System Operators to provide more information on new connections’","ELEXON","2013-11-26","Changes to BSCP15 and BSCP25 to require the Registrant and the System Operator to give additional information upfront in the registration process.","CP1403 proposes changes to BSCP15 and BSCP25 to require the Registrant and the System Operator to give additional information upfront in the registration process.","SVG: 3 Dec 13                           ISG: 17 Dec 13","CPC00736 - 6 Jan 14","ISG/SVG","June 2014 Release","Approve"]
[1402,"Aligning the Deliverables in the Profile Administration Service Description with the Data Analyst Contract.","ELEXON","2013-10-09","The PrA Service Description need updating to reflect all the reporting deliverables from the ELEXON Contracted Analyst to match those defined in the aforementioned Contract.","CP1402 proposes to amend section 5 of the Profile Administration Service Description to align the list of Document Deliverables with those produced under the Data Analyst Contract.","−","CPC00734 - 25 Oct 13","SVG","June 2014 Release","Approve"]
[1401,"Replace residual negative EACs for pre-RF Settlement Days without affecting post-RF data","Npower","2013-09-27","Negative Annualised Advance (AA) values arise from the use of Gross Volume Correction (GVC) and/or the deeming process (e.g. deeming on Change of Supplier, or deeming at RF because a Meter Advance Period is greater than 14 months), and in turn cause Negative Estimated Annual Consumption (EAC) values. These negative EACs represent a known Settlement inaccuracy from which some Suppliers are benefitting through Grid Supply Point (GSP) Group Correction.","CP1401 will make it mandatory for NHHDAs to identify all residual negative EACs that are still being settled (included in aggregation runs). It will also make it mandatory for NHHDCs to replace these with positive class average EACs with effective from Settlement Dates that have not yet been subject to an RF Run by deeming a read at RF.","−","CPC00732 - 27 Sept 13","SVG","February 2014 Release","Approve"]
[1400,"Amendment of the System Operator flag via BSCP18.","National Grid","2013-09-06","As part of P217, Ofgem introduced a licence condition for National Grid to produce a System\nManagement Action Methodology (SMAF) statement; this document sets out the situations under which National Grid will flag BOAs as system actions. National Grid is also required to review the flagging process and produce a report detailing the accuracy of the SMAF process on an annual basis. The report for the period 1st May 2012 to 30th April 2013 has not yet been formally published; however, a flagging error caused a significant impact on cashout prices on 26th April 2013 for settlement periods 31 and 32. The System Sell Price was depressed for these periods from around £38/MWh to £18/MWh (~52% reduction) and £-54/MWh (~242% reduction) respectively because a BOA was not flagged as a system action. Whilst this flagging error was identified shortly after it occurred, there exists no process to correct incorrect flagging. A process to correct a flag error is also needed in light of Ofgem’s Electricity Balancing Significant Code Review (EBSCR) under which the cashout price may be set by the marginal MW.\n","CP1400 would make amendments to BSCP18 (and settlement systems)  to allow the Transmission Company to submit an amended BOALF file in which the SO-Flagged field has been corrected from True to False and vice versa. The correction of the flag should not require the agreement of any BSC party as it does not directly impact the volume or cash flow from the amended BOA or BOAs.  ","−","CPC00732 - 27 Sept 13","ISG","June 2014 Release","Approve"]
[1399,"Business Process Operations (BPO) Service  Rebranding","ELEXON","2013-09-06","The name of the company that provides the Business Process Operations (BPO) Service for the BSC Central Systems has changed from Logica to CGI. There are several references to “Logica” in BSC Configurable Items (CIs), which should be removed wherever possible; or replaced with “Business Process Operations (BPO) Service” (where this needs to be distinguished) or “CGI” (for email addresses).","CP1399 proposes to amend the relevant BSC CIs. Changes should, wherever possible, remove reference to a company; or replace with a more relevant reference (where this needs to be distinguished) or with “CGI” (for email addresses).","−","N/A","PAB/SVG/ISG/TDC","November 2013 Release","Approve"]
[1398,"Clarifications to BSCP520 ‘Unmetered Supplies registered in SMRS'","ELEXON","2013-08-22","ELEXON required to update to BSCP520 arising from a review overseen by the UMSUG","CP1398 seeks to clarify BSCP520 to prevent non-material audit issues and address any typographical errors, omissions and duplications.","−","CPC00731 - 30 Aug 13","SVG","February 2014 Release","Approve"]
[1397,"Improvements to the Balancing Mechanism Reporting System  (BMRS) Electricity Summary Page – Indicative Triad Demand Information tables","Npower","2013-08-22","The Balancing Mechanism Reporting System (BMRS) – Electricity Summary Page currently provides\ntables of ‘Indicative Triad Demand Information’. Due to the existing first table using operational metering rather than Settlement metering data, to calculate the three triad Demand peaks, the data provided can differ more widely from the definitive triad demand data published by National Grid in March each year following the end of each winter (triad) period. This can cause users issues where the operational metering based data has been used for winter forecasting purposes, as the misalignment between the operational metering based indicative data and the definitive data may be impacted. Therefore the CP has been raised to expand the triad data currently published to include indicative triad demand information data that is based on Settlement metering data. ","CP1397 will update the  Electricity Summary Page of the BMRS o create a new table called ‘Indicative Triad Demand Information (using Settlement Metering data). It will also rename the existing ‘Indicative Triad Demand Information’ to ‘Indicative Peak Demand Information (using Operational Metering data)’ to make it clear that the data in the existing table while using the same Triad calculation methodology uses operational metering data. Other minor changes to the Information boxes are also proposed to aid understanding of the source and calculation method for the existing and proposed new tables.","−","CPC00731 - 30 Aug 13","ISG","June 2014 Release","Approve"]
[1396,"Clarifications and Formalising scenarios for the BSCP509 Market Domain Data Changes Request Process","Smartest Energy","2013-08-22","BSCP509 ‘Changes to Market Domain Data’ has been designed to set out the process steps and timescales for submitting, progressing and getting approval of changes to Market Domain Data (MDD). A major drawback of these arrangements is that some types of errors and omissions are not picked up at the validation stage; Distributors on occasion send in MDD CRs with new Line Loss Factor Classes (LLFCs) but do not raise an associated combination at the same time. If the combination does not exist and the registration of it is forgotten, Suppliers then have difficulties billing the customer because they cannot validate MDD and if their systems validate correctly the customer cannot be billed on the information which is published in the DNO’s statements.","CP1396 proposes to clarify the requirements of all parties involved in changing MDD (including BSCCo) when completing and submitting a MDD change request (CR).\nThis involves updating and converting the MDD Handbook into a new BSCP509 Appendix. BSCP509 will then be amended to include cross references requiring parties raising MDD CRs to use the information in the new appendix when completing the MDD CRs, in order to ensure all the necessary information is provided. In addition, it is proposed to amend BSCP509 to capture the initial validation and feedback process carried out by BSCCo on receipt of a new MDD CR.","SVG:  30 Jul 13","CPC00731 - 30 Aug 13","SVG","February 2014 Release","Approve"]
[1395,"Distribution of Configuration Details for Smart Meters","British Gas","2013-07-19","Meter Technical Details (MTDs) are sets of data relating to the Metering Equipment installed at each customer premise. The role of the MOA will change with the roll-out of smart metering. The MOA will continue to install and maintain Meters via site visits, when requested by the relevant Supplier. However, only Suppliers will be able to configure smart Meters remotely, for example, to set and change the Meter’s tariff registers to effect a change of Standard Settlement Configuration (SSC). They will achieve this by sending the relevant service request via the Data and Communications Company (DCC) User Gateway, which will result in the appropriate command being sent to the smart Metering System. ","CP1395 provides detailed solution for communicating smart Meter configuration details to the appointed NHHMOA. This is an alternative solution to CP1388.","−","CPC00729 - 26 Jul 13","SVG","February 2015 Release","Approve"]
[1394,"Use of SMETS compliant Meters for Profiling","ELEXON","2013-07-05","Approved Modification P223 ‘Profile Administrator (PrA) Service’ introduced the minimum requirements for metering for sample participants. These requirements are defined in BSCP510.  Suppliers now want to fit smart Meters for Profiling. These Meters are Half Hourly (HH) capable and would provide valid sample data but may not meet the requirements defined in BSCP510. The solution therefore proposes to add SMETS compliant Meters as an option for Suppliers.","This CP proposes to extend the minimum metering requirements for Profile capable Metering Systems within BSCP510, 4.3 to include Meters that are compliant with the smart meter equipment technical specifications (SMETS).","−","CPC00729 - 26 Jul 13","SVG","June 2014 Release","Approve"]
[1393,"Changes to BSCP27 to align  with the current process carried out by the TAA for the Consumption Data Comparison Check.","ELEXON","2013-07-05","Section 4.1.5 of BSCP27 needs to be clarified to more accurately reflect the current CDC Check process and the term Meter Constant in this section needs to be replaced with Meter Register Multiplier. The TAA has confirmed that the CDC Check is always carried out on site (as the cumulative Meter register advance has to be read from the Meter’s display) so the flexibility provided in BSCP27 to do this offsite should be removed.","CP1393 therefore proposes to clarify BSCP27 to more accurately reflect the current CDC Check process.","ISG: 23 Jul 13  PAB: 25 Jul 13         ","CPC00729 - 26 Jul 13","PAB/ISG/SVG","February 2014 Release","Approve"]
[1392,"BSCP18 Bid-Offer Acceptance Related Data Corrections to the SAA system via Electronic File Transfer method,  instead of manual Email method  ","National Grid","2013-07-05","CP1392 proposes that the automated interface from National Grid to BMRA/SAA should be amended to allow automated corrections of Bid Offer Acceptance (BOA) data in the BMRA and SAA databases (once agreed with the Lead Party in accordance with BSCP18).","CP1392 proposes that the automated interface from National Grid to BMRA/SAA should be amended to allow automated corrections of Bid Offer Acceptance (BOA) data in the BMRA and SAA databases (once agreed with the Lead Party in accordance with BSCP18).","ISG: 23 Jul 13         ","CPC00729 - 26 Jul 13","ISG","February 2015 Release","Approve"]
[1391,"Clarify the existing MDD registration criteria for new Suppliers within the MDD (BSCP509) and Qualification (BSCP537) procedures","ELEXON","2013-03-06","The SVG144 has asked us to raise a CP to address the two issues, which we’ve identified in paper SVG144/08. To provide clarity, a CP is required to make document changes to an MDD Entity form in BSCP509 Appendix; and to the wording in BSCP537 Qualification Process.","Proposed Solution are: for Issue 1 amend BSCP537 section 2.1 to clarify that a new Supplier or new LDSO does not need to be Qualified (by the PAB) before registering in MDD and for Issue 2 to amend BSCP509 entity 61 notes for the Effective From Date {MPR} data item to clarify that the\neffective from date of the Supplier’s Market Participation Role must match the Effective From Date\n{BMUIGG} and the Supplier Base BM Unit in CRA in order for central systems to interface\neffectively.","SVG: 5 Mar 13","CPC00727 - 22 Mar 13","SVG/ISG/PAB","November 2013 Release","Approve"]
[1390,"New MDD Entity for SMETS Version","ELEXON","2013-03-06","To support arrangements for Smart Metering, a new DTC data item, ‘Smart Metering Equipment Technical Specifications (SMETS) Version’ has been created under the Master Registration Agreement (MRA) to be used by Suppliers to indicate their view of the version of the SMETS against which a particular Smart Metering System is compliant.  Through industry consultation carried out under DTC CP3362 (Revisions to the DTC related to SMIP consequential Changes: Registration), it has been requested that SMETS Version be included in Market Domain Data as a new entity. ","CP1390 proposed that ‘SMETS Version’ will be included in MDD as a new entity. In doing so: ‘SMETS Version’ would be established as a new entity in BSCP509 ‘Changes to Market\nDomain Data’, with BSCCo as the originator; a corresponding MDD Entity Form would be created to define the data format; and any subsequent changes to the valid values will go through the usual MDD Change Request process as set out in BSCP509. ","SVG: 5 Mar 13","CPC00727 - 22 Mar 13","SVG","November 2013 Release","Approve"]
[1389,"Removal of Lux Meter Requirement for PECU Arrays","ELEXON","2013-02-22","This CP will remove a requirement from BSCP520  that PECU arrays need a light meter. Light meters do not have anything to do with Settlement, so removing such requirement a will remove the cost burden for Meter Administrators (MAs) in providing the array while leaving the option to have a Light Meter to any MA that wished to have one.","CP1389 proposes to remove the Lux Meter specification, allowing it to be an optional item during procurement and during the working life of a PECU Array.","−","CPC00725  - 22 February 2013","SVG","November 2013 Release","Approve"]
[1388,"Meter Technical Details for Smart Meters","ELEXON","2012-12-28","The creation of Meter Technical Details (MTDs) for smart Meters and associated process changes to reflect responsibilities for these smart metering MTDs.","For smart Meters, CP1388 proposes that MTD are split into two flows: Smart Device Details and Meter Configuration Details. For the purpose of this Change Proposal, smart Meters will be defined as any Meters that comply with the Smart Metering Equipment Technical Specification (SMETS).","−","CPC00722 - 28 Dec 12\nCPC00729 - 26 Jul 13","SVG/Panel","−","Rejected                                                        "]
[1387,"Clarifications to BSCP533 and Appendices","ELEXON","2012-12-29","Amendments to BSCP533 ‘PARMS’ and its appendices to incorporate ELEXON guidance; and address housekeeping issues, to ensure clarity and consistency in interpretation. This CP doesn’t propose changes to PARMS.","CP1387 proposes amendments to BSCP533 ‘PARMS’ and its appendices to incorporate ELEXON guidance; and address housekeeping issues, to ensure clarity and consistency in interpretation. This CP doesn’t propose changes to PARMS.","−","CPC00722 - 28 Dec 12","PAB/SVG","November 2013 Release","Approve"]
[1386,"Improving Settlement Accuracy for Unmetered Supply on a Change of Supplier or Change of Agent","Npower","2012-11-30","Proposed changes to BSCP501 and BSCP520 to put timescales and process steps in place for an existing workaround, which involves the UMSO sending UMS EACs through to the NHHDC on a change of Supplier/Agent. Additional minor changes to BSCP504 (were included in CP1386v2.0) to reflect the BSCP520 changes.","CP1386 seeks to formalise a workaround where UMSOs send NHHDCs Estimated Annual Consumption data when a NHH UMS site has a Change of Supplier or Change of Agent.","−","CPC00721 -            30 Nov 12           CPC00723 -               21 Feb 13","SVG","−","Rejected                                                        "]
[1385,"Notification of NHH Energisation Status Change by LDSO","Npower","2012-11-30","Changes to BSCP514 and BSCP515 obligating Industry Parties to communicate Energisation status changes (and Meter readings if available) in a timely manner.","CP1385 proposes to make changes to BSCP514 and BSCP515 obligating Industry Parties to communicate energisation status changes (and Meter readings if available) in a timely manner.\n","−","CPC00721 -            30 Nov 12           ","SVG","November 2013 Release","Approve"]
[1384,"Clarification on disconnection and associated processes","ELEXON","2012-11-30","Through BSC Audit market issue 1922 we're aware that BSCP515 and BSCP514 are ambiguous and not in line with certain circumstances where the LDSO leads a disconnection. This CP will seek to add clarity and ensure consistency in the De-Energisation, Disconnection and Meter Removal processes.","CP1384 will seek to add clarity and ensure consistency in the De-Energisation, Disconnection and Meter Removal processes.","−","CPC00721 -            30 Nov 12","SVG","November 2013 Release","Approve"]
[1383,"Upgrade of NHHDA and EAC/AA systems to Oracle 11g’","ELEXON","2012-10-26","The current version of NHHDA and EAC/AA applications that ELEXON provide to Party Agents run on Oracle 10g, for which Oracle Corporation ended application support in July 2012, meaning these systems are now running on unsupported platforms. An upgrade to Oracle 11g is therefore required.","Cp1383 proposes to upgrade EAC/AA and NHHDA to the latest version of Oracle 11g that is available. ","−","CPC00719 -           26 Oct  12","SVG","June 2013 Release","Approve"]
[1382,"Clarification of IDD Rules for leading zeroes","ELEXON","2012-10-26","The NETA IDD Part 1 contains a definition of the decimal (n,d) data type that is misleading in its treatment of leading zeroes.","Cp1382 proposes to change the definition in the IDD should be changed. The new definition should be easier to understand and avoids adding the complication of n=d, which in practice, has the\nsame impact as any value being between -1 and 1.\n","−","CPC00719 -           26 Oct  12","ISG","June 2013 Release","Approve"]
[1381,"Negative Wind Generation Forecast on BMRS","ELEXON","2012-10-26","As it currently stands, the Balancing Mechanism Reporting Service (BMRS) does not support negative values for the Wind Generation Forecast, and so it rejects any WINDFOR files containing generation values less than zero.  In these circumstances, a workaround has to be applied in which any negative values are replaced with zeroes and reloaded into BMRS for storage and publication.","CP1381 proposes the  following to BMRS: WINDFOR generation values should be associated with the ‘FT Generation’ data item defined in the IDD Part 2 spreadsheet rather than ‘SPN Generation’; and the WINDFOR TIBCO message should use the ‘Fuel Type Generation (FG)’ field type defined in the IDD Part 1 document to report the data rather than ‘Generation Value (VG)’. Both the ‘FT Generation’ IDD data item and ‘Fuel Type Generation (FG)’ TIBCO field type have\nvalid sets of -99999 to +99999 and so can handle negative values.","−","CPC00719 -           26 Oct  12","ISG","−","Rejected                                                        "]
[1380,"Pre-site audit visits - Technical Assurance of Metering ","ELEXON","2012-08-01","The TAA has noted that during the time between the notification of a site visit and the actual visit some SVA sites have been visited by MOAs and work carried out on the HHMS (e.g. a Meter has been replaced). The TAA believes that this is potentially skewing the results of the audits and potentially preventing non-compliances from being identified.","CP1380 seeks to remove this restriction and allow a Supplier to appoint a mixture of the PrA nominated and Supplier chosen NHH Agents should they choose.","−","CPC00718 -              31 Aug 12","SVG/ISG","February 2013 Release","Approve"]
[1379,"Service Review of the Technical Assurance of Metering Systems","ELEXON","2012-08-01","The Technical Assurance of half hourly Metering Systems is designed to detect and correct error in the Meter set up and with the associated paperwork (Meter Technical Details etc.).  ELEXON have completed a service review of the Technical Assurance of Metering and identified some changes to be made to the process steps in BSCP27.  \n","CP1379 proposes various updates to be made to BSCP27 to reflect the process as it is currently operating and what is most effective for the process itself. The largest change, and therefore effect, is the inclusion into BSCP27 of a query process. Additionally, Attachment A includes information on the background of this change and details on the additional changes ELEXON recommend.","−","CPC00716 -            3 Aug 12","SVG/ISG","2013-03-29","Approve"]
[1378,"\nAlternative to CP1377 - Clarifying rules on Third Party Access on Licence Exempt Distribution Network\n","Smartest Energy","2012-08-01","This CP is identical to CP1377 except that it removes the requirement which states that Registrants have to appoint a common MOA and puts in a requirement that a customer may choose to appoint an MOA of their choice. CP1378 aims to demonstrate that a free choice of Meter Operator is important for competition and would not lead to any risks to Settlement.","\nCP1378 clarifies the example to the guides to complex sites to more closely reflect the\narrangement of customers within Exempt Networks/Private Network seeking third party access and also recognises export scenarios. This CP also makes it clear that you can choose an MOA.\nThe updated example will also be applicable to BSCP502 (section 4.9.3).\n ","−","CPC00716 -            03 Aug 12           CPC00721 -               30 Nov 12","SVG","−","Rejected                                                        "]
[1377,"Clarifying rules on Third Party Access on Licence Exempt Distribution Network","ELEXON","2012-08-01","The Electricity and Gas (Internal Market) Regulations 2011 describes the process for customers on Private Networks to choose their own gas and electricity Supplier. BSCP 514/502 currently recognises this arrangement, but CP1377 seeks to provide further clarification to the rules to more accurately reflect this arrangement of customers within Private Networks seeking third party access.","\nCP1377 seeks to clarify the example so it more closely reflects the arrangement of customers\nwithin Exempt Networks/Private Network seeking third party access and also recognises export\nscenarios. The updated example will also be applicable to BSCP502 (section 4.9.3).","     SVG: 140            ","CPC00716 ","SVG","November 12 Release","Approve"]
[1376,"Reporting Failed Instructions","ELEXON","2012-07-01","Each year, in order to ensure that Agents are processing Failed Instructions correctly, the BSC Auditor requests counts of outstanding Failed Instructions from NHHDAs and NHHDCs. Several Parties have received Audit Issues as a result of discrepancies between the NHHDA and NHHDC counts, and a Market Issue has also been raised (Market Issue 2289).\nThere are however, a number of aspects of the reporting process that contribute to these discrepancies and therefore bring into question the validity of these Issues: inconsistent reporting between NHHDAs and NHHDCs and inconsistent Reporting between NHHDAs. There is no standard query which NHHDAs. ","CP1376 from previous DCP49 seeks to make it explicit that the outgoing NHHDC should only remain responsible for material or high risk Failed Instructions; and provides a standard script that all NHHDAs should use.","−","CPC00715 -               29 Jun 13","SVG","June 2013 Release","Approve"]
[1375,"Increasing material impact threshold","ELEXON","2012-06-01","In BSCP128 (LLF production) a Manifest Error is can only happen where there is a material impact. In order to have a Material impact it must be more than £500, This £500 was set using the Trading Disputes Materiality Threshold as a guidance value. The Trading Dispute threshold is currently £3,000 and BSCP128 should be updated to align with this figure.\n","CP1375 proposes a change to the definition in BSCP128 of “Material impact: Retrospective Changes”. It will be amended from: “An impact or estimated impact that has a value or estimated value of over £500.” To: “An impact or estimated impact that has a value or estimated value greater than or equal to the Materiality Threshold for rectification of a valid Trading Dispute (as defined in BSC Procedure BSCP11).”","−","CPC00715 -               31 Jul 12","ISG/SVG","February 2013 Release","Approve"]
[1374,"TAA Audits","ELEXON","2012-05-01","There is currently nothing in BSCP27 that prevents participants from carrying out pre-audit site\nvisits and making changes during the notification period. Nor is there any way of letting the TAA\nknow of any intention to visit the site for genuine reasons (e.g. safety reasons or to fix a fault).\n","CP1374 proposes to make it a requirement for the MOA to inform the TAA if it needs to visit a site which has an audit pending, thus the TAA will have a record of visits and any work that has been conducted that could potentially alter their findings.","ISG: 139              SVG: 141               PAB: 139","CPC00712","ISG/SVG/PAB","−","Rejected                                                        "]
[1373,"Submission to EWS via spreadsheet","F&S","2012-05-01","Trading Parties notify the Energy Contract Volume Aggregation Agent (ECVAA) of trades via flows generated and submitted by Party Agents using either their own internal notification systems or the ECVAA Web Service (EWS). Use of the EWS involves manual data entry which is inefficient and error prone.","CP1373 would enable the EWS to accept files containing multiple notification details, with no effect on existing submission methods.","−","CPC00712 -             29 May 12","ISG/SVG","February 2013 Release","Approve"]
[1372,"Clarification to CP1356","ELEXON","2012-04-20","CP1356 'Demand BM Unit Aggregation Rule Example for BSCP75' has been approved for implementation in the June 2012 Release. It proposes to include in BSCP75 (‘Registration of Meter Aggregation Rules for Volume Allocation Units’) an example of Aggregation Rules for a BM Unit with Import metering but no Export metering. The example in the approved redlining for CP1356 states that “since there is no on-site generation, the Active Energy Meter is only set up to record Active Import volumes (AI)”. Configuring a meter in this way is consistent with Code of Practice Two (CoP2) or Code of Practice Three (CoP3), but not with Code of Practice One (CoP1). There is therefore a risk that the example could mislead Parties or Meter Operator Agents into configuring their metering in a non-compliant way at CoP1 sites.","Cp1373 is proposed to amend the BSCP75 wording to clarify that configuring the metering to record Active Import only (as described in the example) is not consistent with CoP1. This will avoid any risk that the CP1356 solution misleads Parties or Meter Operator Agents into configuring their metering in a non-compliant way.\n","ISG: 135                  ","−","ISG","June 12 Release","Approve"]
[1371,"LLF Audits offsite","ELEXON","2012-03-30","Existing practices requires that an audit of Line Loss Factors (LLFs) must be performed at the Licensed Distribution System Operator’s (LDSO’s) offices. However, experience gained from conducting these audits has shown that, in some cases, the audit can be completed remotely. This CP aims to facilitate this approach.","CP1371 will amend BSCP128 Section 3.5 ‘Audit Scope’ to say that the audit ‘may’, rather than\n‘will’, be performed at the LDSO’s office. Consequential changes will be made to BSCP128 to reflect that not all audits will require site visits and to clarity the process for remote audits. Consequential changes will also be made to Appendix 3 of BSCP128 (the Calculation Self Assessment Document, or CSAD).","ISG: 135              SVG: 136               ","CPC00710","ISG/SVG","June 12 Release","Approve"]
[1370,"Revised rules for default LLFs","ELEXON","2012-03-30","Currently default Line Loss Factors are applied on an equivalent day for day basis. However, it has been determined that applying this default rule could result in non-Working Day LLFs being applied on Working Days and vice versa. This would result in distribution losses being allocated less accurately. This CP proposes that to rectify this issue, the default LLFs should be applied on an equivalent Seasonal Time of Day (SToD) basis.","CP1370 proposes that to rectify this issue, the default LLFs should be applied on an equivalent Seasonal Time of Day (SToD) basis.","ISG: 135              SVG: 136               ","CPC00710","ISG/SVG","June 12 Release","Approve"]
[1369,"Increased Flexibility in BSCP550 Data Splitting Algorithms","ELEXON","2012-03-02","A number of areas in the data splitting algorithms used in BSCP550 are overly-prescriptive, and unnecessarily limit the options available to Suppliers and generators. CP1369 proposes changes to increase the flexibility of these algorithms where the HHDC systems allow.","CP1369 proposes changes to increase the flexibility of these algorithms where the HHDC systems allow.","SVG: 135","CPC00709","SVG","June 12 Release","Approve"]
[1368,"UMSUG BSCP520 changes","ELEXON","2012-02-01","UMSUG have a number of suggestions to clarify BSCP520","CP1368 is intended to address all these issues together.","ISG: 136                 SVG: 140                PAB: 135","CPC00716","PAB/ISG/SVG","November 12 Release","Approve"]
[1367,"Interconnector Fuel types","ELEXON","2012-02-10","The East-West Interconnector will become operational in 2012 and data relating to it should be reported individually on the BMRS. The BSC provides for the Panel to include new Interconnectors in reporting without the application of the Modification process, and the BSC Panel has approved a BMRA Fuel Type Category relating to the Interconnector with effect from June 2012. ","CP1367 proposes to make the changes required to the BMRS and the NETA Interface\nDefinition and Design (IDD): Part 1 in order for data relating to the East-West Interconnector to be reported individually on the BMRS. These changes are set out in the CP form and attached redlining.","ISG: 133","−","ISG","June 12 Release","Approve"]
[1366,"Data Quality Obligations for Outgoing Supplier Agents","ELEXON","2011-12-23","One of the conclusions from Issue 41 – “Improving the Quality & Accuracy of Data Flows” was that there is little incentive on an outgoing Supplier or Agent to resolve issues (including co-operating with the other Suppliers or Agents or carrying out sometimes complex analysis) once they were no longer associated with that metering point. CP1366 seeks to require Supplier Agents to be responsible for the quality of data, with respect to a Metering System, during their period of appointment; even if data quality issues are identified after the Agent’s de-appointment.","CP1366 seeks to require Supplier Agents to be responsible for the quality of data, with respect to a Metering System, during their period of appointment; even if data quality issues are identified after the Agent’s de-appointment.","SVG: 134","CPC00705","SVG","June 12 Release","Approve"]
[1365,"Shortening Profile Production Timescales","ELEXON","2011-12-23","Following a successful trial to ensure the approach was viable the SVG agreed that the Profile\nAdministrator would adopt the process to allow the use of profiles produced on a seasonal basis\n(SVG126/02) from 1 April 2012.","CP1365 seeks to amend the Profile Administration Service Description to reflect the shortening of Profile Production timescales and detail the revised timetable for data analysis.","SVG: 133","CPC00705","SVG","June 12 Release","Approve"]
[1364,"CALF Data Item","ELEXON","2011-11-25","Remove the obsolete PARMS serials which are no longer required.","CP1364 will amend BSC Systems to allow CALF values with up to four digits before the decimal point to be used in the Credit Cover calculation. However, these bigger values will be capped for reporting purposes to avoid National Grid and Parties having to change their own systems.","ISG: 132","CPC00706","ISG","June 12 Release","Approve"]
[1363,"GVC - Direction when addressing errors","ELEXON","2011-11-25","CP1363 was raised by ENW Ltd and seeks to place an obligation on Suppliers that any compensatory adjustments undertaken to address overstatements and understatements of energy are made in an overall balanced manner. Addressing or prioritising all issues causing overstatements in energy or all issues causing understatements in energy would result in an overall detrimental impact on the accuracy of Settlements as it would create a skew in the Settlement data.","CP1363 is intended to facilitate a reduction in the level of distortion that occurs when these adjustments are made and prevent any unreasonable skew in the volume settled. ","SVG: 132","CPC00706","SVG","−","Rejected"]
[1362,"GVC - Removal of extreme EACs","ELEXON","2011-11-25","The issue is that there are still a significant number of negative EACs being used in Settlements which were created before CP1311 was implemented. Removal of all residual negative EACs will increase the accuracy of the EACs used in Settlement and reduce uncertainty around Licensed Distribution System Operators regulated allowable revenue and Suppliers’ Distribution Use of System charges.","CP1362 was raised by ENW Ltd and seeks to remove all residual negative Estimated Annual Consumption (EACs) from Non Half Hourly Data Aggregators databases via a centralised script. CP1311 addressed this matter in part by preventing the creation of any new negative EACs. ","SVG: 132","CPC00706","SVG","June 12 Release","Approve"]
[1361,"GVC - Removing Negative EACs","ENWL","2011-11-25","Requires NHHDAs to set any negative EACs to either a) Class average, consistent with CP1311 ; or b) Zero. Zero will have lesser costs, but group waiting to see.\n","CP1361 was raised by ENW Ltd and seeks to place an obligation on Non Half Hourly Data Collectors (NHHDCs) to replace extreme EACs following a Gross Volume Correction (GVC), if the forward Estimated Annual Consumption (EAC) is demonstrably inconsistent with normal generation or demand for that Metering System and is likely to lead to failure to validate subsequent readings. ","−","CPC00706","SVG","−","Rejected                                                        "]
[1360,"GVC - DMX Audit Records","ENWL","2011-11-25","More specific audit obligations on Suppliers and their agents in relation to the use of GVC and DMX so that compliance can be more readily checked as part of the BSC Audit and so that quantification could be more readily undertaken.","CP1360 was raised by ENW Ltd and seeks to amend BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems in SMRS’ to make the audit obligations on Suppliers and their agents, in relation to the use of techniques such as Gross Volume Correction (GVC) and Dummy meter exchange (DMX), more specific. CP1360 seeks to enable consistent reporting by NHHDCs and to allow the volume and applicable period of the adjustment to be readily identified. This will facilitate any investigations and analysis associated with use of these techniques.","−","CPC00706 ","SVG","November 2013 Release","Approve"]
[1359,"Introducing new products into the MIDS","ELEXON","2011-10-28","At its meeting in October, the BSC Panel considered the annual Review of the Market Index Definition Statement (MIDS). CP1359 proposes to incorporate a 1 hour block product is being launched on the APX power exchange from Quarter 4 2011, this should be included in the MIDS with a weighting of one and hence included in the calculation of the Market Index Price, both the APX and N2EX power exchanges offer a Day Ahead Auction product. It is not proposed that this be used to calculate the reverse price, but that it should be included in the Market Index Definition Statement as a relevant product with a zero weighting.","CP1359 proposes to incorporate a 1 hour block product is being launched on the APX power exchange from Quarter 4 2011, this should be included in the MIDS with a weighting of one and hence included in the calculation of the Market Index Price, both the APX and N2EX power exchanges offer a Day Ahead Auction product. It is not proposed that this be used to calculate the reverse price, but that it should be included in the Market Index Definition Statement as a relevant product with a zero weighting.","ISG: 131","CPC00704","ISG","2012-04-01","Approve"]
[1358,"Change to timeband weightings in the MIDS","ELEXON","2011-10-28","The BSC obligates ELEXON to review annually the Market Index Definition Statement (MIDS). At its meeting in October, the BSC Panel considered the annual Review of the MIDS. The MIDS includes a set of relevant products and timebands in which trades are made on those products, and sets weightings on them to determine which should be used to calculate the Market Index Price and Market Index Volume submitted by each power exchange in their role as Market Index Data Providers. The products and weightings are reviewed annually.","CP1358 proposes to set to Zero the weightings for timebands 7 and 8, meaning that only trades made within 12 hours of Gate Closure (timebands one to six) are included in the calculation of the reverse imbalance price. ","ISG: 131","CPC00704","ISG","2012-04-01","Approve"]
[1357,"MSID Allocation Process","ELEXON","2011-10-28","The current wording of BSCP20 requires the CRA to notify details of the MSID allocation within 1 Working Day of Boundary Point registration (BSCP20 3.1.1). However, in many cases, the CRA\nwould not have received the BSCP20/4.1 form at the same time or before the Boundary Point\nRegistration occurs. This means that the CRA cannot allocate the MSID or notify the Registrant and MOA about the allocation. The CRA can only provide the MSID on receipt of the BSCP20/4.1. However, since this usually happens after Boundary Point registration, this process is currently non-compliant.\n","CP1357 proposes to amend the timescales in BSCP20 Section 3.1 to align with current practice. Rather than being required to allocate a MSID and notify details of the allocation within 1 Working Day of BSCP20 3.1.1 (Boundary Point registration)","ISG: 131","CPC00704","ISG","June 12 Release","Approve"]
[1356,"Demand BMU Aggregation rules","ELEXON","2011-09-30","See solution. ","CP1356 intends to make it clearer to Parties submitting Aggregation Rules how they should be formulated in situations where a demand only BM Unit is set up.","ISG: 130","CPC00702","ISG","June 12 Release","Approve"]
[1355,"Updates to BSCP537 (Testing requirements)","ELEXON","2011-09-30","Appendix 2 of BSCP537 states that:\n‘Test data will be provided by BSCCO for the purposes of performing the arithmetic testing, the Applicant will be required to format, validate and processes [sic] this data through its systems and processes. The output from the arithmetic testing will be compared against the expected results held by BSCCO.’ This is contrary to the intention of P197 which advocates self assessment and requires applicants to perform their own entry testing. In addition this data is not currently available. The only test data that BSCCO has is data that it provided under the old Certification, Accreditation and Entry Process processes. This data has not been maintained or updated for SVA Qualification (it is simply what was previously provided by the Entry Process Co-ordinator). The reference to this provision of test data by BSCCO should have been removed as part of P197. This is an oversight that has now been identified and needs to be rectified. ","CP1355 is intended to align testing requirements with the intent of P197 ‘SVA Qualification Processes Review’. The SVA Qualification Process advocates self assessment and requires applicants to perform their own entry testing.","ISG: 130","CPC00702","ISG","Feb 12 Release","Approve"]
[1354,"Updates to BSCP537 (SAD)","ELEXON","2011-09-02","A recent Technical Assurance (TA) check on how Metering System records are managed\nhighlighted non compliance with aspects of CoP 4 relating to performing and recording\ncommissioning correctly. In particular the check identified: MOAs operating incomplete commissioning procedures resulting in Meters being programmed incorrectly and errors in equipment installation leading to Settlement errors. Commissioning of parts of the Metering System is sometimes being performed by a third party (rather than the appointed MOA) and the details are not being passed on, creating inefficiencies.","CP1354 proposes to amend BSCP537 Appendix 1 as follows: make the guidance to the applicants clear about the level of communication to be established and maintained with Equipment Owners to ensure full commissioning is performed; introduce guidance to ensure that controls and procedures are in place to assess the quality of commissioning test results and records in accordance with CoP 4; and amend the guidance to require applicants to detail how they will transfer documentation to new MOAs when there is a Change of Agent.","ISG: 129","CPC00701","ISG","Feb 12 Release","Approve"]
[1353,"ECOES and BSCP514","E.ON","2011-09-02","To ensure consistency with the MRA change, and to strengthen the requirement on MOAs to keep\nECOES up to date, E.ON propose to amend BSCP514. ","CP1353 proposes to amend BSCP514 to require the Meter Operator Agent (MOA) to notify the Electricity Central Online Enquiry Service (ECOES) of any changes to the relevant data items by sending a ‘Notification of Meter Information to ECOES’ (D0312) flow.","SVG: 130","CPC00701","SVG","Feb 12 Release","Approve"]
[1352,"Changes to the FAA Billing Process","ELEXON","2011-09-02","ELEXON believes that continuing to post Advice Notes and Confirmation Notices is inefficient, as it involves time and manual effort which the FAA could spend on other activities such as dealing with Parties’ queries. Since the implementation of P214, email invoicing has become widely accepted and used. However, removing post must not disadvantage smaller Parties without the systems to load/read the ASCII backing sheets","CP1352 proposes to remove the option for Parties to receive FAA Advice Notes, Confirmation Notices and their associated backing sheets by post.  It will leave email as the single mandatory method of despatch for these invoices.","ISG: 129","CPC00701","ISG","Feb 12 Release","Approve"]
[1351,"CoP4 -  Meter Equipment Commissioning","CE Electric","2011-08-05","The Technical Assurance of Metering Expert Group (TAMEG) report to the PAB, dated 28 April,\nconcluded that the potential for inaccuracy in this area is significant, and the TAMEG believes there are fundamental concerns with commissioning of HH Metering Equipment. As stated in the report, ELEXON agrees with the TAMEG’s acknowledgement that there are issues with commissioning which have the potential to conceal significant problems affecting Settlement and remains concerned that the issues of commissioning, in particular, and records in general, remain to some extent an uncontrolled risk.","CP1351 proposes changes to CoP4 to clarify and tighten up requirements for commissioning new HH sites and where HH sites have changed metering equipment.","−","CPC00700 - 5 Aug 11","ISG/SVG","−","Rejected                                                        "]
[1350,"MTD update BSCP514","EDF","2011-08-05","Raised by British Gas to remove the scope for misinterpretation of the meaning of Meter Technical Details where they relate to Metering Systems that can be operated remotely.",null,"SVG: 130","CPC00700","SVG","Feb 12 Release","Approve"]
[1349,"Changes to accommodate EU metering standards","ELEXON","2011-06-01","Since the introduction of the MID, certain MID approved meters have not been considered compliant with certain CoP under the BSC for HHS, even though they meet the technical minimum standard. This is due to the wording of the current CoPs. CP1349 proposes to amend CoPs 2, 3, and 5 so that they include MID accuracy classes as well as those currently specified. This will allow Meters which carry MID approvals (and therefore comply with its standards) to also be used for HHS purposes where applicable.","CP1349 proposes to amend CoPs 2, 3, and 5 so that they include MID accuracy classes as well as those currently specified. This will allow Meters which carry MID approvals (and therefore comply with its standards) to also be used for HHS purposes where applicable.","ISG: 127              SVG: 127               ","CPC0698","ISG/SVG","Feb 12 Release","Approve"]
[1348,"Supplier Charges following implementation of CP1334 'New PARMS Serials'","ELEXON","2011-05-06","CP1334 will introduce a suite of new PARMS serials, going live on 1 July 2011.  Therefore the 'old' serials being made redundant under this change will no longer be valid and, following the July reporting period, will no longer be used for the purposes of reporting performance. Throughout the implementation stages, ELEXON and the PAB realised it would be incompatible to continue to apply SP01 Supplier Charges to these redundant serials and historic reporting periods and therefore we should not apply these charges to these old serials following 1 July 2011.  Removing the SP01 Supplier Charges for the old serials and reporting periods cannot be fully realised under the existing wording of BSCP533 and its Appendices and therefore this CP has been raised to remedy this.","CP1348 proposes to amend BSCP533 and Appendices to enable the removal of SP01 Supplier Charges for the old, redundant PARMS serials and the historic reporting periods, following the introduction of the new PARMS serials on 1 July 2011.","SVG: 125","CPC00697","SVG","June 11 Release","Approve"]
[1347,"SVAA process embedded networks","ELEXON","2011-04-27","With effect from April 2010, the Supplier Volume Allocation Agent (SVAA) implemented a reporting\nsolution for providing Host LDSOs with aggregated consumption data for embedded networks in their area. The DCUSA Working Group on IDNO/DNO Billing Governance has now concluded that there is no business case for appointing a new central agent, and that the enduring solution should be closely modelled on the current one. The current solution should therefore be improved to address the issues listed above, and make it suitable as an enduring solution.\n","CP1347  seeks to improve the process for reporting of aggregated consumption data for embedded networks to Host LDSOs by the Supplier Volume Allocation Agent (SVAA). It would require reports to be sent over the Data Transfer Network (DTN) rather than email, and provide a mechanism for excluding from the reports any directly connected networks in the Host LDSO area. These changes were recommended by a DCUSA Working Group looking at enduring arrangements for portfolio billing of embedded networks.","SVG: 125","CPC00697","SVG","Feb 12 Release","Approve"]
[1346,"Proving tests shall not be based on verbal MTDs","ELEXON","2011-04-01","BSCP203 requires MTD to be submitted by post/fax/email using either form BSCP20/4.3 ‘Registration of Meter Technical Details’ (which must be signed by an Authorised Signatory) or flow CDCA-I003 ‘Meter Technical Details’. In situations where MTD are initially communicated verbally during a Proving Test, the Registrant or MOA will then formally submit the MTD to the CDCA several days later in accordance with BSCP20. The CDCA inputs these subsequent MTD, which overwrite the earlier MTD verbally communicated by the MOA. The risk with this approach is that, if the subsequent MTD are different to those used for the Proving Test, this can result in Settlement errors even though the Proving Test was considered successful. This situation occurred recently and resulted in an overstated Settlement volume (estimated at £3.4m). Fortunately, the error was able to be corrected before the Final Reconciliation Run.\n","CP1346 will remove the risk of Settlement errors occurring as a result of basing Proving Tests on verbally-communicated Meter Technical Details, which are then overwritten by (and may be different to) the MTD formally submitted for Settlement under BSCP20. The CP will clarify in BSCP02 that Proving Tests must only be considered successful if they are based on the formal post/fax/email MTD submitted under BSCP20.","ISG: 134","CPC00696","ISG","Nov 11 Release","Approve"]
[1345,"NG interface XML","ELEXON","2011-03-04","The BM system is the source of System Operator data sent to key BSC Central Systems. National Grid intends to replace the BM system in 2013. The BM system currently sends data to the BSC Central Systems in CSV format. The new Electricity Balancing System (EBS) uses XML data format as standard in its interfaces with other systems.  This Change Proposal considers the requirement and timescales for migrating National Grid’s interface with the BSC Central Systems from CSV to XML format.","CP1345 considers the requirement and timescales for migrating National Grid’s interface with the BSC Central Systems from CSV to XML format.","ISG: 123             SVG: 122              ","CPC00694","ISG","Nov 11 Release","Approve"]
[1344,"Correcting errors in BSCP533","ELEXON","2011-01-28","While carrying out the necessary activities to implement CP1334 on 01 July 2011, ELEXON has identified a number of inconsistencies, typographical errors and issues with the wording of the appendices to BSCP533: Appendix A: ‘PARMS Data File Formats’; Appendix B: ‘PARMS Calculation Guidelines’ and Appendix C ‘PARMS Data File Formats and Calculation Guidelines for Obsolete PARMS Serials’. Following the implementation of CP1339 on 01 November 2010, ELEXON identified errors in BSCP533 and Appendices where there were incorrect references to ‘PAA’, which should instead be: ‘PARMS’ (where the reference is to the PARMS system or operator); or ‘BSC Service Desk’. The materiality of this issue regarding form F533/05 is low, as ELEXON has rarely received such forms in the past. Other changes are required to clarify the activities carried out by PARMS or the BSC Service Desk.","CP1344 has been raised to make necessary amendments and correct errors in BSCP533 (including appendices) identified following the approval of CP1334 ‘New PARMS Serials’ and approval and implementation of CP1339 ‘Amendments to BSCP533 to enable changes to the hosting and operation of the PARMS system’. ","SVG: 122","CPC00692","SVG","June 11 Release","Approve"]
[1343,"Appropriate Line Loss Factors for High Voltage Customers metered at primary substations","CE Electric UK","2011-01-28","In December 2010, the Authority directed changes to the Standard Licence Conditions (SLC) definitions of the Common Distribution Charging Methodology (CDCM) and Extra High Voltage Distribution Charging Methodology (EDCM). These changes had no intentional consequential impact on how High Voltage Line Loss Factors are assigned under the BSC.","CP1343 proposes to amend the definition of Extra High Voltage and High Voltage to ensure the appropriate treatment of losses for HV customers irrespective of changes, in the DCUSA.","ISG: 122             SVG: 122 ","CPC00692","ISG/SVG","June 11 Release","Approve"]
[1342,"Housekeeping change to CoP9","CE Electric UK","2010-09-21","CE Electric UK identified that a House Keeping Change is required to correct a Manifest Error in CoP9.","CP1342 is a House Keeping Change to correct a Manifest Error in CoP9.","SVG: 116","−","SVG","Feb 11 Release","Approve"]
[1341,"Multi-Level Static Dimming Devices","ELEXON","2010-09-01","Currently, BSC Settlement arrangements do not support the energy calculation for new products that are emerging for dimming/switching of street lamps.  These products can facilitate reductions in energy consumption and carbon savings for Unmetered Supplies (UMS).  We have raised CP1341 from DCP0046 to progress the majority industry view on the best solution for accommodating these products in Settlement.  The CP impacts UMS Operators, Meter Administrators, ELEXON and UMS customers who wish to use these products","CP1341 from DCP0046 progresses the majority industry view on the best solution for accommodating these products in Settlement  The CP impacts UMS Operators, Meter Administrators, ELEXON and UMS customers who wish to use these products","SVG:117","CPC00687","SVG","June 11 Release","Approve"]
[1340,"Changes to BSCP537 Appendix 1 - Self Assessment Document (SAD) to better reflect the BSC Obligations","ELEXON","2010-09-13","BSCP537 Appendix 1 ‘Self Assessment Document (SAD)’ contains the requirements for both Qualification and re-Qualification. Applicants are required to complete the SAD in accordance with BSCP537 ‘Qualification’ and Section J ‘Party Agents and Qualification under the Code’ of the BSC. An applicant’s responses to the questions within BSCP537 Appendix 1 (SAD) must support their self assessment conclusions as to whether they have met the Qualification Requirements.\nIt has been identified that sections in BSCP537 Appendix 1 (SAD) should be updated to better reflect BSC obligations.\n\n","CP1340 proposes to include a new question in Section 15 of BSCP537 Appendix 1 (SAD); include a new question in Section 9 of the SAD and replace instances of paa@elexon.co.uk with a cross reference to BSCP533 as the method of data submission is being revised via CP1339. Two housekeeping changes (shown by [Housekeeping]) have been included to correct a typographical error and remove a Change Proposal reference that is not required","ISG: 119           SVG: 119             PAB: 119","CPC00687/CPC00690","ISG/SVG/PAB","Feb 11 Release","Approve"]
[1339,"Efficiency Changes to BSCP533 & BSCP536","ELEXON","2010-08-02","ELEXON has added the hosting and operation of the PARMS to the scope of the BSC Services Agreement. Logica commenced the service from 1 August 2010.  From 1 November 2010, we want Performance Assurance Parties to submit PARMS files directly to (and receive acknowledgements directly from) PARMS at Logica.  BSCP533 and its appendices currently include numerous references to PARMS@elexon.co.uk, PAA@elexon.co.uk, ELEXON and BSCCo. BSCP536 also contains references to PAA@elexon.co.uk. Many of these references will be incorrect or obsolete as a result of outsourcing PARMS hosting and operation.","CP1339 proposes to amend BSCP533, BSCP533 Appendix B, BSCP533 Appendix C and BSCP536.","SVG: 116","CPC00686","ISG","Nov 10 Release","Approve"]
[1338,"Guidance for Complex Sites ","ESP","2010-07-02","The complex site arrangements are defined in Balancing and Settlement Code Procedures (BSCPs) 514'SVA Meter Operations for Metering Systems Registered in SMRS’ and 502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ as ‘…any site that requires a ‘Complex Site Supplementary Information Form’ to enable the Half Hourly Data Collector (HHDC) to interpret the standing and dynamic Metered Data relating to SVA MS for Settlement purposes…’. \rGuidance is also provided in these BSCPs by way of examples of situations that would require complex mapping to be applied by the HHDC to ensure that Settlement is correct. This guidance was originally designed for unusual situations within a Customer’s network.\rThe Technical Assurance process has recently identified a number of sites where non-Settlement flows (i.e. Distribution System flows or flows originating from the Customer’s own network) are affecting Settlement Meter readings. Meter Operator Agents have been using the complex arrangements to deal with these Customer and distribution ‘network’ related flows so that Settlement is not impacted by them.","CP1338 proposes that extra guidance is added into BSCP502 and BSCP514 in the form of two additional examples of complex sites where Network flows affect Settlement Meter Readings.","SVG: 115","CPC00685","SVG","Nov 10 Release","Approve"]
[1337,"Improvements to the TDC Process","ELEXON","2010-07-02","At the March 2009 Trading Disputes Committee (TDC) meeting, the TDC agreed that a review3\nof the BSC Trading Queries and Trading Disputes process should occur. The review aimed to: provide clarity; simplify the process; and make it more economical process (where possible). \n","CP1337 progresses three of the 12 changes recommended by the TDC following a review of the Trading Dispute Process in 2009. The three changes are: increasing the Disputer Materiality Threshold of a Trading Query/Dispute; clarifying what an ‘affected party’ is; and include the need for the raising Party to indicate whether they are claiming exceptional circumstances and provide supporting evidence.","TDC: 142","CPC00685","TDC","Nov 10 Release","Approve"]
[1336,"UMSO Adjustment to EACs and Pseudo HH Units based on Physical Audit Findings","EDF","2010-06-21","Inventory submissions can be inaccurate and updates aren’t always readily provided. There are even cases of large customers apparently hiding their true consumption in order to manage their electricity bills. EDF Energy Networks decided to undertake physical on-street checks and, so far, we’ve completed 12 major audits of local authority lighting customers. Average energy error was close to 10%. One local authority had an error rate of 28% - a Settlement shortfall of more than 2 gigawatt-hours (GWh).","CP1336 proposes introducing a technique to correct Settlement for UMS consumption promptly.  The physical audit has calculated an energy error percentage and so offers the means to address the difference between the EAC and actual consumptions. Distributors then can uplift the EAC by the determined percentage until the UMSO agrees the validity of a new inventory submission from the customer. The proposed solution can be applied to NHH and HH customers simply by: Uplifting the EAC value for NHH-traded customers and applying the percentage to the counts of items on the Summary Inventory for HH-traded customers.","SVG: 166","CPC00685","SVG","−","Rejected"]
[1335,"Creation of New Auxiliary MTD flow","ELEXON","2010-05-27","On 06/04/09 a new Supply Licence Condition came into effect that required the installation of advanced meters for Profile Class 5-8 sites.  On 29/04/10 the MRA Development Board approved an enduring solution in the form of a new data flow.  CP1335 proposes creating the necessary governance over the use of this flow, it needs to be referenced in the relevant BSC Procedures.  Furthermore, the data flow includes a new data item, ‘Communications Provider ID’, whose valid set is to be maintained through Market Domain Data.","CP1335 proposes creating the necessary governance over the use of this flow, it needs to be referenced in the relevant BSC Procedures.  Furthermore, the data flow includes a new data item, ‘Communications Provider ID’, whose valid set is to be maintained through Market Domain Data.","ISG: 114             SVG: 114              ","CPC00681","ISG/SVG","Nov 11 Release","Approve"]
[1334,"PARMS Review 2 - New Serials","EON","2010-05-27","A review of PARMS Serials determined that a number of Serials no longer provide meaningful metric data for Settlement Risks.  CP1334 recommends these Serials could be amended to better align to the key Settlement Risks and proposes 12 new Serials.","CP1334 recommends these Serials could be amended to better align to the key Settlement Risks and proposes 12 new Serials.","SVG: 114","CPC00681","SVG","Nov 11 Release","Approve"]
[1333,"Reporting of So-So Trades","ELEXON","2010-04-26","The current Balancing Mechanism Report Service (BMRS) System Operator to System Operator (SO-SO) Trade page presents SO-SO price data in an unstructured manner. This means that it will become extremely difficult for Parties to locate the information they need as the volume of data increases significantly. CP1333 proposes to change the BMRS to present the data in a structured manner.","CP1333 proposes to change the BMRS to present the data in a structured manner.","ISG: 113","CPC00680","ISG","Nov 10 Release","Approve"]
[1332,"Offshore T-mission - BSCP75 examples","ELEXON","2010-04-26","P237, P238 and P240 have been approved by the Authority.  These 3 Modification Proposals make changes to the ways in which Offshore generators can configure their Plant/Apparatus, BM Units and metering.  All of these changes affect how Offshore generators submit Aggregation Rules.  BSCP75 contains example Aggregation Rules for various different configurations of generator Plant and Apparatus. CP1332 recommends adding examples of Offshore Aggregation Rules to BSCP75.","CP1332 recommends adding examples of Offshore Aggregation Rules to BSCP75.","ISG:113","CPC00680","ISG","June 10 Release","Approve"]
[1331,"Streamline Party/Party Agent Registration process","ELEXON","2010-04-08","Section A of the BSC details the requirements for a Party to “apply for registration in CRS by\napplying to the CRA in accordance with BSCP65”, however BSCP651 requires the party to send it initial registration data via BSCP65/01 and its Party Agent registration details via BSCP71/05 to ELEXON.ELEXON no longer sees this checkpoint as a necessary step in the market entry process as parties are now advised of the requirements to enter the market prior to and whilst signing the BSC to become a BSC Party.\n ","CP1331 proposes to amend BSCP65 & BSCP71 to direct the BSCP65/01 & BSCP71/05 forms to the CRA. The CRA would validate the forms in accordance with BSCP38 and check with ELEXON that a Party wishing to register its details in CRA via BSCP65/01 has completed the accession process and is a Party to the BSC. The CRA will be informed by an email from the BSC Service desk when a Party/CVA Party agent has completed CVA Qualification testing in accordance with BSCP70 and will process the BSCP65/01 & BSCP71/05 forms to register in the roles it has applied for within CRA.  The CRA would be required to send notification of any new registration to ELEXON who will inform the industry via Newscast.","ISG: 112            SVG: 112       ","CPC00678","ISG/SVG","Nov 10 Release","Approve"]
[1330,"Streamlining Registration Process","ELEXON","2010-04-08","A clarification is required to clarify the requirements on participants and reduce the overall timescale for the CRA to register a BSC Party.","CP1330 aims to streamline the registration process by excluding non added value actions carried out by ELEXON such as: duplication of receipt of BSCP forms; duplication of forms acknowledgement from CRA and ELEXON to Parties; necessary email authorisation of forms to CRA from ELEXON; and dual liaison with National Grid by both ELEXON and CRA.","ISG: 112            SVG: 112       ","CPC00678","ISG","Nov 10 Release","Approve"]
[1329,"Streamline CVA Qualification Process","ELEXON","2010-04-08","The current BSCP70 test booking forms do not have a space for the Party submitting the request to\nselect a potential test date and highlight the Party role being tested. Having this information on\nreceipt of the form would allow us to determine availability and prepare test flows without having\nto make contact with the customer unnecessarily.","CP1329 proposes to streamline the CVA Qualification process by reducing ELEXON’s involvement in this process. This change would therefore 1) Enable Parties to communicate directly with the CRA throughout the CVA Qualification process. This would provide a more streamlined, efficient and expert service to our customers.  2) Support ELEXON in our drive to transfer responsibility for services to our BSC Agents where ELEXON are not adding value.  3) Reduce management overhead for the BSC Agent as a result of process improvement.","ISG: 112            SVG: 112       ","CPC00678","ISG","Nov 10 Release","Approve"]
[1328,"ECVAA Web Service request process ","ELEXON","2010-04-08","The current process of submitting the EWS request form is now redundant following the release of\nXSec version 3. XSec version 3 allows parties to create their own encryption keys using the XSec\nsoftware and does not require support from the BSC Service Desk to gain access to EWS. ","CP1328 looks at removing the BSCP71/12 ECVAA Web Service Request Form from BSCP71. Details of the EWS would be provided to parties at the same time as sending out information for XSec version 3 and parties would choose whether to use the service if they wish. The Logica Communications team would create individual account areas within the relevant central services servers and the EWS server at the same time following completion of CVA Qualification testing.  The BSC Service Desk would continue to provide parties with technical support if it is required but parties would not be delayed in using the service by needing to submit the BSCP71/12 form and waiting for the Logica Second Line support team to create individual account areas within the EWS Server. The ECVAA Web Service information sheet would also be updated to reflect the new process.","ISG: 112            SVG: 112       ","CPC00678","ISG","Nov 10 Release","Approve"]
[1327,"Inclusion of a new BSCP Entity 27 ","ENWL","2010-04-01","MDD entity forms provide a view of what data items needs to be amended or included for a particular version of MDD. There are presently 62 entity forms listed in BSCP509.  Presently the entity 27 form is not included in the list of forms in this BSCP. To allow participants make submissions related to this change, a historic spreadsheet form was created to allow participants fill in the relevant information for the change. In recent MDD publishes there have been a number of entity 27 changes and there is a possibility that the numbers will increase as Suppliers trial Smart Metering.  As a result, this change proposes to include an ‘entity 27’ form within BSCP509 to allow for a more consistent approach for participants to submit their data items.","CP1327 proposes to include an ‘entity 27’ form within BSCP509 to allow for a more consistent approach for participants to submit their data items.","SVG: 112","CPC00678","SVG","Nov 10 Release","Approve"]
[1326,"LLF updates to BSCP128","ELEXON","2010-02-23","ELEXON has completed the audit process for the first time which was introduced under BSCP128 and following a lesson learnt workshop, recommend updating BSCP128 and some of its appendices it make the process more efficient.","CP1326 recommends updating BSCP128 and some of its appendices to make the process more efficient.","ISG: 111            SVG: 111       ","CPC00676","ISG/SVG","June 10 Release","Approve"]
[1325,"Removal old PARMS Serials","ELEXON","2010-02-23","The Performance Assurance Reporting and Monitoring System (PARMS) is a database that contains information on the performance of Suppliers and their Supplier hubs against PARMS Serials.  A review of PARMS Serials determined that a number of Serials no longer provide meaningful metric data for Settlement Risks. Overall, there are 14 PARMS Serials which the PAB, PARMS review group and industry consultation respondents agree are now obsolete.","CP1325 proposes to remove the 14 Serials will require modification of the PARMS software. Logica's proposed solution relies on validating the reporting period for the submitted Serial and comparing against the end date for a Serial. The solution will allow SP01 to be calculated correctly and will not directly impact Supplier Charges. A new appendix will be created for BSCP533. The calculation guidelines for SP04 will be amended to reflect the BSC. A worked example will be provided to aid understanding. The exclusion deadline for NM03 and NM04 will be extended to +15 Working Days (WDs) from +5 WDs. Further examples and guidance will be added to BSCP533 Appendix B where needed. General housekeeping will be carried out in BSCP533, BSCP533 Appendix A and BSCP533 Appendix B where appropriate.\n","SVG: 111","CPC00676","SVG","Nov 11 Release","Approve"]
[1324,"Access to >=132kV Offshore Metering","ELEXON","2010-01-07","The Offshore Transmission Operator (OFTO) arrangements will go live in June 2010.  The GB Total System will extend to the offshore installations, hence there will be some additional health and safety risks associated with access to offshore Metering Equipment. We invited a number of industry experts to consider the existing Balancing and Settlement Code (BSC) requirements and to evaluate any potential technical solutions that may reduce the need for offshore site visits. The group believes that there are significantly higher risks associated with accessing offshore Metering Systems when compared with land based Metering Systems.  This will affect CoP1, CoP2, BSCP05, BSCP06, BSCP27, CDCA SD and CDCA URS.","CP1324 proposes changes to CoP1, CoP2, BSCP27, BSCP06, BSCP05, CDCA User Requirement Specification and CDCA Service Description.","ISG: 111            SVG: 109       ","CPC00674","ISG/SVG","June 10 Release","Approve"]
[1323,"Alignment of SVA Qualification and SAD","ELEXON","2010-01-08","The SVA Qualification Process has been in operation since August 2007.  During this time we identified a number of required changes.\r\nCP1323 proposes to clarify the relevant requirements on market participants, making the processes in the SAD easier to follow. It also seeks to align the Meter Administrator (MA) section in the SAD with the current obligations within BSCP520 so as to enable MAs to clearly demonstrate how they are able to meet BSC obligations in their submission of the SAD.","CP1323 proposes to clarify the relevant requirements on market participants, making the processes in the SAD easier to follow. It also seeks to align the Meter Administrator (MA) section in the SAD with the current obligations within BSCP520 so as to enable MAs to clearly demonstrate how they are able to meet BSC obligations in their submission of the SAD.","ISG: 109            SVG: 109       ","CPC00674","ISG/SVG","June 10 Release","Approve"]
[1322,"CSD Architectural Principles Document","ELEXON","2010-01-08","The Code Subsidiary Document (CSD) Architectural Principles Document has not undergone substantial revision since it was published as part of the BSC Baseline in November 2006. \r\nWe noted that the document contains a number of inaccuracies, as well as out of date information which makes it difficult for the Imbalance Settlement Group (ISG) and Supplier Volume Allocation Group (SVG) to use when approving updates to CSDs. \r\nCP1322 proposes to make changes to the CSD Architectural Principles Document, so that it is of sufficient quality to provide a basis for the production, review and approval of future changes to CSDs.","CP1322 proposes to make changes to the CSD Architectural Principles Document, so that it is of sufficient quality to provide a basis for the production, review and approval of future changes to CSDs.","ISG: 109            SVG: 109       ","CPC00674","ISG","2010-03-18","Approve"]
[1321,"Housekeeping Change to correct a manifest error in BSCP301 and NETA IDD Part 2","ELEXON","2009-12-09","The ISG approved CP13131 in October 2009; this CP streamlined the Minimum Eligible Amounts (MEA) process. However, the CP introduced an error into BSCP 301, where in section 4.6.1.5 it is stated that the ‘ECVAA-I027: Notification of BSC Party in Section H Default’ is sent from ECVAA to BSCCo. This is not correct as BSCCo sends ECVAA an I027 on an ad-hoc basis (as a standalone step), to inform ECVAA on any Parties that are in Section H Default2. This step is not required to be included in the BSCP as it is carried out currently by ELEXON as part of ELEXON’s standard working procedure. Section 4.6.2.5 also references I027, as a consequence of CP1313, this reference is no longer correct, and needs to be removed. Additionally, during the implementation of CP1313 we noticed that while the changes brought about CP1313 were correctly applied, these changes were not referenced in section 3 of the IDD. ","CP1321 proposes correcting the text in the ‘Information Required’ column for section 4. 6. 1. 5. Section 4. 6. 2. 5 also wrongly references the I027 as a result of the changes brought about by CP1313, and it is proposed that this reference is removed. Additionally, during the implementation of CP1313 we noticed that while the changes brought about CP1313 were correctly applied, these changes were not referenced in section 3 of the IDD.","ISG: 107","−","ISG","Feb 10 Release","Approve"]
[1320,"Replacing erroneous CoS Reads","ELEXON","2009-11-27","ELEXON held two working groups to consider clarification of the use of Gross Volume Correction (GVC) and guidance (GVC Guidance) on the retrospective correction of errors. The group recommended that clarifications should be made, both in terms of when the Change of Supplier (CoS) reading could be replaced and the method used to agree and carry out the replacement.","CP1320 proposes to add clarity to BSCP504 to the effect that a CoS reading can be disputed no later than 12 months after the Supply Start Date (SSD).","SVG: 108","CPC00673","SVG","−","Rejected"]
[1319,"Correction to table B4 of Appendix B in Code of Practice 4","ELEXON","2009-11-13","Following the November 2009 BSC Release, a review on CoP 4 highlighted a number of manifest errors which we believe should be corrected at the earliest possible opportunity. The “Test Point” heading in Table B4 of Appendix B in Code of Practice (CoP) 4 currently reads as “Cos Ø “. This title was inadvertently introduced by CP1288 (Revisions to Meter test points within Code of Practice 4) as part of the November 2009 Release. In addition, and following a full review of CoP4 we have noticed that: there are two instances where Meter isn’t capitalised; and the symbol used to represent ‘phi’ isn’t consistent throughout the document.","CP1319 proposes to: amend the “Test Point” heading in Table B41 of Appendix B in CoP4 to read: \"Value of Current (I)\"; capitalise the six instances of ‘meter’ in Appendix C (under Table C1 (a) and under Table C3 (a)) of CoP4; and correct all instances where an incorrect symbol for ‘j’ is used. This will mean changes to Appendix B (Tables B1, B2, B3, B4 and B5) and Appendix C (Tables C1, C1 (a) and C2). We recommend that ‘j’ is adopted (rather than ‘Ø’ which is used in some instances) as ‘j’ is used in the diagram following table B1, which is extracted from the British Standards.","ISG: 106            SVG: 106       ","−","ISG/SVG","2009-12-08","Approve"]
[1318,"Minor changes to BSCP601","ELEXON","2009-10-21","A number of minor errors exist in BSCP601 ‘Metering Protocol Approval and Compliance Testing’ which this CP is seeking to address.","CP1318 seeks to address a number of housekeeping errors which exist in BSCP601 ‘Metering Protocol Approval and Compliance Testing’.","ISG: 107            SVG: 107      ","CPC00671","ISG/SVG","June 10 Release","Approve"]
[1317,"Removal of requirement for NHHMOAs to notify NHHDCs of metering work before the event ","ELEXON","2009-10-21","As a result of merging two paragraphs from PSL110 v16. 0 (paragraphs 1. 5. 1. 2 & 1. 5. 1. 3) into BSCP514 (paragraph 2. 4. 1 b) a ‘new’ obligation has inadvertently been placed on Non Half Hourly (NHH) Meter Operator Agents (MOA) to give sufficient notice, except in an emergency, to the associated NHH Data Collector of the removal, reprogramming, Energisation or de-Energisation of any Meter. ","CP1317 seeks to clarify BSCP514 by replacing paragraph 2. 4. 1 c) in BSCP514 with the two separate paragraphs that originally appeared in PSL110.","SVG: 107","CPC00671","SVG","June 10 Release","Approve"]
[1316,"Removal from BSCP536 of obligation to attach a copy of Form 536/01 to BSCCo Bill ","ELEXON","2009-09-25","The Supplier Charges form 536/01 within BSCP536 section 4. 12. 1 places an obligation on ELEXON to send two copies of the form to Parties. Following a recent upgrade to our financial systems, the obligation for ELEXON to attach the second copy of the Supplier Charges form to the BSCCo Bill has become unnecessary. ","CP1316 will remove a superfluous procedure and align BSCP536 with actual processes.","SVG: 106","CPC00669","SVG","June 10 Release","Approve"]
[1315,"Maintenance of Outstation Types as part of Compliance and protocol approval ","ELEXON","2009-09-25","Outstation Types are not generic but rather act as references to specific Outstation makes and models, as in practice most metering communication protocols are manufacturer-specific.  However, this means that if and when a new piece of equipment enters the market, it may not be properly represented by the Valid Set and so the HHDC may not be able to tell which protocol should be used, preventing them from dialling in to the Outstation.  At present, altering the Valid Set requires a formal change to the DTC, yet new equipment may be introduced at any time, outside the DTC release timescales.  The result is that the Valid Set will often be out of date, and participants will frequently have to resort to manual workarounds in order to transfer the necessary information.  The Valid Set of Outstation Types should be removed from the DTC and instead be established as part of the Compliance and Protocol Approval process documented in BSCP601.","CP1315 proposes removing the Valid Set of Outstation Types from the Data Transfer Catalogue and instead be established as part of the Compliance and Protocol Approval process documented in BSCP601.","SVG: 109","CPC00669","SVG","Nov 10 Release","Approve"]
[1314,"Housekeeping change to SAA Service Description","ELEXON","2009-09-22","During implementation of P215 ELEXON omitted to change the identical wording in Section 5.2.1(b) of the SAA Service Description to match the revised Code obligation.\n","CP1314 will revise Section 5. 2. 1(b) of the SAA Service Description to mirror the new P215 wording in Section U2. 4. 2(b) of the Code.","ISG: 105","−","ISG","Feb 10 Release","Approve"]
[1313,"Removal of ELEXON’s role in processing Minimum Eligible Amount (MEA) requests","ELEXON","2009-08-28","A Minimum Eligible Amount (MEA) is the amount of credit cover a Party needs to have lodged with the Funds Administration Agent (FAA). Parties can request to reduce the credit they have lodged by submitting a form (in BSCP301 ) to ECVAA. This is known as a MEA request. ","CP1313 seeks to amend the current MEA process, as including ELEXON in this process does not add value, and creates an inefficient process.","SVG: 105","CPC00668","SVG","Feb 10 Release","Approve"]
[1312,"Use of Gross Volume Correction in Post Final Settlement Runs (PFSR)","ELEXON","2009-08-28","One of the features of GVC is an ‘Error Freezing Reading’. BSCP504 only covers the application of this technique outside the Trading Disputes process. Previously, ELEXON has issued guidance to the effect that an ‘Error Freezing Reading’ may be deemed in the current Post Final Settlement Run (PFSR) window, in the event that the relevant Metering System is subject to a Trading Dispute (and a PFSR has been scheduled for the relevant GSP Group). However, the Trading Disputes Committee (TDC) has recently agreed that its preference is for ‘Error Freezing Readings’ to be deemed at the RF boundary in all circumstances, and not to allow these readings to be deemed at a PFSR. ","CP1312 proposes to amend Section 4. 14 of BSCP504 to deliver the TDC’s preferred solution.","SVG: 105","CPC00668","SVG","Feb 10 Release","Approve"]
[1311,"Replacing Erroneous Forward Looking EACs","ELEXON","2009-08-28","There is an existing process in the Code (S-2 4. 3. 17) and in BSCP504 (4. 14. 4. 6) that allows an Estimated Annual Consumption (EAC) to be replaced by a representative value, but there are 3 problems with this process: Potential for inconsistent application of requirement Applicability of EAC replacement Manual process.","CP1311 proposes mandating the replacement of all negative EACs with a class average EAC (or a more representative EAC, if available), leaving the replacement of positive EACs as an optional process. Changes to BSCP504 and the EAC/AA software would be required to support this solution.","SVG: 105","CPC00668","SVG","June 10 release","Approve"]
[1310,"Clarifications to Gross Volume Correction (GVC) Process","British Gas","2009-08-28","CP1310 is the first of three changes (1310, 1311 and 1312) raised following the work undertaken by the Gross Volume Correction Expert Group, which was set up by the SVG. CP1310 highlights that there are a number of areas where the BSCP504 is not prescriptive enough, and that further clarity is needed. ","CP1310 proposes changes to BSCP504 to clarify how the principles should be applied in practice, and retains the original principles agreed by the Trading Stage 2 Committee.","SVG: 105","CPC00668","SVG","Feb 10 Release","Approve"]
[1309,"Include reference to D0303 in BSCP514 and circumstances in which its use is mandatory","British Gas","2009-08-28","Changes in the provision of metering services to British Gas in 2010 will increase the number of entities that provide service to Meter Asset Provider (MAP) and Meter Asset Maintainer (MAM). There is a risk that the data available to the MAP being out of date will increase. This separation of MAM and MAP roles can be expected to become more widespread as smart metering is deployed. ","CP1309 proposes that the Meter Operator must send the D0303 ‘Notification of Meter Operator, Supplier and Metering Assets installed/removed by the MOP to the MAP’ to the MAP in some circumstances (except where the MOP and MAP are the same commercial entity). This change would be achieved though amending BSCP514 – – ‘SVA Metering for Metering Systems Registered in SMRS’ to include reference to the D0303.","SVG: 105","CPC00668","SVG","June 10 Release","Approve"]
[1308,"Changes to Long Term Vacant Site process where a reading is obtained via a warrant","ELEXON","2009-07-31","Where a reading has been obtained through entry via a warrant, a site will drop out of the LTV process and will be assigned a non zero Estimated Annual Consumption (EAC) value. However, it is then likely to re-qualify for LTV in the future as a warrant will not be obtained for further readings (and SVCC of 02 will start to be received again). When the site re-enters the LTV process, a reading is deemed for the beginning of the new LTV period based on the non-zero EAC. This deemed read will cause energy to enter Settlement for the period between the date that the reading was obtained via the warrant process, and the date of the next D0004 (with the 02 SVCC), while the site is vacant. ","CP1308 proposes changes to BSCP504 and would prevent energy to be allocated where there was no consumption by allowing the warrant read to be replicated at the start of the next LTV period.","SVG: 104","CPC00667","SVG","Feb 10 Release","Approve"]
[1307,"Minor Changes to the Long Term Vacant Site Process","ELEXON","2009-07-31","A number of issues around the Long Term Vacant site process were discussed under BSCP40 issue 00004 ‘Improvements and Clarifications to the Long Term Vacant site process’. ","CP1307 proposes minor changes to BSCP504 to clarify three minor areas around the LTV Site process.","SVG: 105","CPC00667","SVG","Feb 10 Release","Approve"]
[1306,"Removal of second criterion for identifying a site as a Long Term Vacant (LTV)","ELEXON","2009-07-31","The second criterion for identifying a site as LTV is: ‘The NHHDC is unable to gain access to read the Meter’.","CP1306 recommends removing the second criterion for identifying a site as LTV should be removed from BSCP504, as it is superfluous.","SVG: 104","CPC00667","SVG","Feb 10 Release","Approve"]
[1305,"Use of Site Visit Check Code (SVCC) 20 with additional information in the Long Term Vacant (LTV) process","ELEXON","2009-07-31","Amongst other requirements, to enter the LTV process the Supplier must have: 1. received from the NHHDC at least two D0004 data flows, at least 3 calendar months apart and not more than 7 calendar months apart with the J0024 data item populated with code 02 ‘Site not Occupied’; and 2. not received any D0004s with the J0024 data item populated with anything other than 02 in the interim. Currently if the supplier receives a SVCC 20 (No Access), the site couldn’t enter the LTV process. ","CP1305 proposes changes to BSCP504 to allow SVCC 20 to be used to enter a site into the LTV process when ‘site not occupied’ or ‘long term vacant’ is entered into the additional information field.","SVG: 104","CPC00667","SVG","−","Rejected"]
[1304,"Exclusion of certain Site Visit Check Codes (SVCC) within the Long Term Vacant (LTV) site process","ELEXON","2009-07-31","A site will drop out of the LTV process if the Supplier has received a data flow with the Site Visit Check Code (SVCC) data item populated with a code other than 02 (Site not occupied). However, there are certain other codes that a Supplier may receive that do not indicate that the site is no longer vacant. Currently if one of the codes is received, the site must be removed from the LTV process – even though the site will still be vacant. ","CP1304 recommends changes to BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ to prevent certain SVCCs from causing a site from falling out of the LTV process.","SVG: 104","CPC00667","SVG","Feb 10 Release","Approve"]
[1303,"Requirement on Half Hourly Data Collectors to Estimate Missing Reactive Power Demand Values","ELEXON","2009-07-03","The estimation methods defined in section 4. 2. 1 of BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ have a proven track record of mitigating the impact of missing Active Power data on settlement processes. ","CP1303 recommends extending these methods to include Reactive Power. This would reduce the impact of missing data on DUoS charging and network management functions, and hence bring benefits to Suppliers, LDSOs and customers.","SVG: 103","CPC00666","SVG","Feb 10 Release","Approve"]
[1302,"Requirement on Half Hourly Data Collectors to Validate Reactive Power Demand Values","ELEXON","2009-07-03","The reporting of erroneous Reactive Power data to LDSOs and Suppliers potentially leads to incorrect DUoS charges and other issues. ","CP1302 recommends extending the scope of existing validation processes to include Reactive Power data.  This would reduce errors in those industry processes that use Reactive Power data (e. g. DUoS charging), and reduce the administrative overhead of data errors on Suppliers, LDSOs and customers.","SVG: 103","CPC00666","SVG","Feb 10 Release","Approve"]
[1301,"Registration Requirements for System Connection Points Between Onshore Distribution Systems and Offshore Transmission Systems","ELEXON","2009-07-03","For some time now, BERR and Ofgem have been developing a new regulatory regime for Offshore licensed Transmission Systems. In June 2009 the Secretary of State approved changes to the Balancing and Settlement Code. The approved changes are now in the relevant sections of the BSC. ","CP1301 recommends that these changes are reflected in the relevant Code Subsidiary Documents.","ISG: 103","CPC00666","ISG","Feb 10 Release","Approve"]
[1300,"System changes to support Change of Market Participant ID for the SVA Agent and MDD Agent Roles from ‘CAPG’ to ‘SVAA’","ELEXON","2009-06-02",null,"CP1300 proposes changing the Market Participant ID (MPID) for the SVA Agent and MDD Agent roles from ‘CAPG’ to ‘SVAA’. Whilst the change from ‘CAPG’ to ‘SVAA’ is a relatively simple MDD change, ELEXON recognises there are many potential impacts on BSC systems and BSC Party systems and processes.","ISG: 102            SVG: 102      ","CPC00662","ISG/SVG","−","Rejected"]
[1299,"Requirement on Half Hourly Data Collectors to Collect and Report Reactive Power Data (where the Meter is configured to record it)","ELEXON","2009-06-05","Following a Working Group on Absent and Erroneous Reactive Power Data ELEXON has raised CP1296. This is one of 4 CPs (1296, 1297, 1298 and 1299) which have resulted from the group’s work. ","CP1299 recommends that the current requirement in BSCP502 relating to collection of Reactive Power data should be strengthened to oblige the HHDC to collect and report Reactive Power data, where the MOA has so configured the Meter. This change will largely formalise existing practice.","SVG: 102","CPC00662","SVG","Feb 10 Release","Approve"]
[1298,"Requirement on MOAs to Configure Meters to Record Half Hourly Reactive Power Data (for Half Hourly Settled CT-Metered Customers)","ELEXON","2009-06-05","Following a Working Group on Absent and Erroneous Reactive Power Data ELEXON has raised CP1298. This is one of four CPs (1296, 1297, 1298 and 1299) which have resulted from the group’s work. ","CP1298 recommends the amendment of BSCP514. The change will place a specific obligation on MOAs – when they install or reconfigure Half Hourly Metering Equipment that is supplied via measurement transformers, they should configure the Metering Equipment to record Half Hourly demand values for both Reactive Import and Reactive Export (provided that the Metering Equipment has the capability to do so).","SVG: 102","CPC00662","SVG","Feb 10 Release","Approve"]
[1297,"Mandatory Capability to Record Reactive Power Demand (kvar) Values in Code of Practice 10 (CoP10) Meters","ELEXON","2009-06-05","Following a Working Group on Absent and Erroneous Reactive Power Data ELEXON has raised CP1296. This is one of 4 CPs (1296, 1297, 1298 and 1299) which have resulted from the group’s work. ","CP1297 recommends an amendment to Code of Practice 10 (CoP10), to require that the Meter has the capability to record Demand (kvar) values for Reactive Import and Reactive Export.","ISG: 102            SVG: 102      ","CPC00662","ISG/SVG","Feb 10 Release","Approve"]
[1296,"Mandatory Capability to Record Reactive Power Demand (kvar) Values in Code of Practice 5 (CoP5) Meters","ELEXON","2009-06-05","Following a Working Group on Absent and Erroneous Reactive Power Data ELEXON has raised CP1296. This is one of 4 CPs (1296, 1297, 1298 and 1299) which have resulted from the group’s work. ","CP1296 recommends an amendment to Code of Practice 5 (CoP5), to require that the Meter has the capability to record Demand (kvar) values for Reactive Import and Reactive Export.","ISG: 102            SVG: 102      ","CPC00662","ISG/SVG","Feb 10 Release","Approve"]
[1295,"Process for distribution of MDD Updates not included in D0269/D0270 flows","ELEXON","2009-06-05","Currently the majority of MDD updates are sent over the DTN. Certain MDD updates are sent separately as MS Word documents via email, and include: GSP Group Profile Class Default EACs (GGPCDEAC) – currently sent to NHHDAs; GSP Group Profile Class Tolerances – currently sent to NHHDCs and Suppliers; and HH Default EACs – currently sent to HHDAs, HHDCs, Suppliers and LDSOs. These values have historically not been changed often and separately have not warranted a change to include them in the MDD update flows. However it has come to ELEXON’s attention that several participants are not receiving this information and are not aware that they should be receiving this information.","CP1295 proposes that: it is highlighted (in BSCP505, BSCP508 and the SVA Data Catalogue) that NHHDAs will be issued GGPCDEAC data via email; and ELEXON provide SQL scripts to facilitate the loading of this data.","SVG: 102","CPC00662","SVG","Feb 10 Release","Approve"]
[1294,"Housekeeping Change to SVA Data Catalogue Volume 2","ELEXON","2009-06-02","CP1269 ‘Publication of Additional Non Half Hourly Combination Data in Market Domain Data’ was approved by the SVG on 3 March 2009 for implementation in the November 2009 Release. CP1269 introduces the following 3 new data items into the D0269 ‘Market Domain Data Complete Set’ and D0270 ‘Market Domain Data Incremental Set’ flows: Effective From Settlement Date {VMTCLSPC}; Effective To Settlement Date {VMTCLSPC}; and Preserved Tariff Indicator. All of these three data items will be included in the Data Transfer Catalogue (DTC) through DTC CP3300, which the MRA Development Board (MDB) has approved for a parallel implementation with CP1269. However, the approved redlined changes for CP1269 only added the Preserved Tariff Indicator to the data item index in Volume 2 of the SVA Data Catalogue. The new Effective From Settlement Date {VMTCLSPC} and Effective To Settlement Date {VMTCLSPC} were unintentionally omitted from this document. ","CP1294 proposes adding the following two data items to Volume 2 of the SVA Data Catalogue: Effective From Settlement Date {VMTCLSPC}; and Effective To Settlement Date {VMTCLSPC}. This is a minor consistency change, required to prevent confusion, promote clarity and help achieve the full intention of CP1269.","SVG: 101","−","SVG","Nov 09 Release","Approve"]
[1293,"Housekeeping changes to BSCP537 Appendix 1 – Self Assessment Document (SAD)","ELEXON","2009-05-05","CP1272 ‘Use of Appointment and Termination Flows in Unmetered Supplies (UMS)’ removed the requirement in BSCP520 for Suppliers to send 3 data flows to Unmetered Supplies Operators (UMSOs). In addition CP1272 introduced a requirement within BSCP501 for Licensed Distribution Systems Operators (LDSOs) to inform UMSOs of any changes. The Supplier Volume Allocation Group (SVG) approved CP1272 in March 2009 (SVG97/01) for inclusion in the June 2009 Release. Following the approval of CP1272, we have identified that the approved changes to BSCP520 and BSCP501 need to be reflected within BSCP537 Appendix 1: Self Assessment Document (SAD) to ensure consistency between the documents. This impact was missed during the impact assessment of CP1272. ","CP1293 proposes changes to BSCP537 Appendix 1. These changes are minor consistency changes, required to reflect the revisions to BSCP501 and BSCP520. On this basis they are being progressed via a Housekeeping Change.","ISG: 100         SVG: 100                 PAB: 100 ","−","ISG/SVG/PAB","Nov 09 Release","Approve"]
[1292,"Clarify Meter Administrator requirements relating to PECU arrays.","ELEXON","2009-05-01","ELEXON raised CP1292 on behalf of the Meter Administrator Expert Group (MAEG). This CP recommends changes to BSCP520 to provide additional clarity for Meter Administrator requirements relating to Photo-Electric Cell Unit (PECU) arrays. The recommended changes will ensure that Half Hourly (HH) Unmetered data is calculated accurately, by having clear requirements for the siting, upkeep and defaulting processes for PECU array data. "," This CP proposes changes to the BSCP520 to add clarity and remove the potential of doubt about the correct process, which is essential for the BSCP user. Additionally, the amended BSCP520 will provide a clearer guidance to the Auditor in terms of the expectations on the Meter Administrator following PECU or PECU Array failure.","SVG: 101","CPC00661","SVG","Nov 09 Release","Approve"]
[1291,"Clarify requirements on Meter Administrators relating to Equivalent Meters","ELEXON","2009-05-01","MAEG conducted a number of walkthroughs of BSCP520 via a page turn process. During the walkthroughs, the MAEG identified a number of inaccuracies and inconsistencies in the requirements on Meter Administrators (MAs) relating to Equivalent Meters (EMs).","The CP recommends changes to BSCP520 to: establish Population, Amendment and reporting of data within an Equivalent Meter (EM); clarify Fault Reporting; and include a requirement for a Technical Specification for EM Calculations. The inclusion of a Specification for EM calculations will assist the Auditor in assessing the MA action in executing its obligations under BSCP520. It will also ensure that MAs are clear on their obligations. The CP also proposes to clarify the MA responsibilities when managing faults, which is particularly important for new entrants, who may not be familiar with the arrangements","SVG: 101","CPC00661","SVG","Nov 09 Release","Approve"]
[1290,"Rationalise and Simplify Unmetered Supplies requirements following a review by an Expert Group","ELEXON","2009-05-01","ELEXON identified a number of inconsistencies on BSCP520 which can cause confusion, particularly for new entrants who may not be familiar with the arrangements.","ELEXON raised CP1290 on behalf of the Meter Administrator Expert Group (MAEG), to correct a number of inaccuracies and inconsistencies that were identified in BSCP520.","SVG: 101","CPC00661","SVG","Nov 09 Release","Approve"]
[1289,"Correction to the Level 4 password requirement in Code of Practice 2","ELEXON","2009-05-01","CP1051 v3. 0 ‘Review of Metering Code of Practice 1 ‘The Metering of Circuits with a Rated Capacity exceeding 100MVA for Settlement Purposes’ and Code of Practice 2 ‘Code of Practice for the Metering of Circuits with a rated Capacity not exceeding 100 MVA for settlement purposes’ was approved by the ISG and then implemented in the February 2006 Release. One of the changes recommended the introduction of four password levels of security for retrieving and/or programming various metering parameters in CoP1 and 2. During the implementation of CP1051 v3. 0, the words ‘other than’ were omitted from the level 4 password requirements in CoP2. ","CP1289 amends the level 4 password requirements in CoP2, in order to be consistent with the requirement in CoP1.","ISG: 101","CPC00661","ISG","Nov 09 Release","Approve"]
[1288,"Revisions to Meter test points within Code of Practice 4","RWE npower","2009-04-21","Code of Practice 4 (CoP4) deals with the testing commissioning and the calibration of Metering\nEquipment. It specifically references the tests that are to be conducted on Meters both before they are installed and during their in-service lives. The test points in CoP4 were intended to align with those in BS1 EN 62053-22:2003 and BS EN 62053-23:2003. However, CoP4 uses units of power factor (cos φ) for both active and reactive Meters whereas the British Standards use units of power factor for active Meters and units of sin φ for reactive Meters. This is causing some confusion to Meter Operator Agents and Meter manufacturers. The British Standards also allow a greater error when a single phase of a polyphase Meter is being tested. ","CP1288 proposes changes to CoP4 to create consistency between the British Standards and CoP4 for the text points in Meter Calibration checks. Consistency between the British Standards and CoP4 will help prevent Meter Operator Agents and Meter manufacturers from inadvertently using incorrect tests points for calibration checks.","ISG:  102                    SVG: 102            ","CPC00661","ISG/SVG","Nov 09 Release","Approve"]
[1287,"Correction of inconsistencies in BSCP536 ‘Supplier Charges’","ELEXON","2009-04-03","ELEXON identified a number of inconsistencies on BSCP536.","CP1287 recommends changes to BSCP536 ‘Supplier Charges’ to correct a number of inconsistencies as follows: the BSCP536/03 form to correctly use ‘Total GSP Group Take’ and include ‘Sum of Supplier Cap Take’ other minor inconsistencies in the rest of BSCP536; and  section 4. 11 to remove details of the P99 run off period which are no longer needed.","SVG: 100      PAB: 100","CPC00660","SVG/PAB","Nov 09 Release","Approve"]
[1286,"BSCP18 Operational Review: Additional flag in Transmission Company’s BOAL file to indicate an amended Bid-Offer Acceptance","ELEXON","2009-04-03","Currently the BSC Systems will reject any automatically sent BOAL data corrections. Therefore BOAL data corrections are entered manually. This is time consuming and introduces the risk of human error. A new field, the ‘Amended Acceptance Flag’, which identifies a BOAL data correction, would be added to the BOAL file. ","ELEXON raised CP1286 to introduce a process to automate Bid-Offer Acceptance Level (BOAL) data corrections. The BSC Systems would be amended so that they automatically accepted a BOAL data correction if the Amended Acceptance Flag was set to ‘True’. The change would: increase the efficiency of the process for ELEXON and the BSC Agent; and increase the transparency of the process to BSC Parties as data would be available on the BMRS (including TIBCO) earlier than it appears in the SAA Settlement Reports.","ISG: 100","CPC00660","ISG","Nov 09 Release","Approve"]
[1285,"Unmetered Supplies: Clarification of Central Management System Requirements","ELEXON","2009-04-03","ELEXON identified four issues for clarification of BSCP520.: the maximum file lines permitted in control files are insufficient to record expected amount of information and should be increased; the CMS Unit Reference for control devices requires clarification to help users meet the BSCP’s required 12-digit structure; the CMS Unit Reference for non-control devices requires clarification to prevent confusion with file naming conventions; and the definition of information flag.","CP1285 aims  to improve clarity around Central Management System (CMS) requirements in BSCP520. ELEXON has developed CP1285 in collaboration with UMSOs, MAs and CMS manufacturers who are involved in the CMS process.","SVG: 100      PAB: 100","CPC00660","SVG","Nov 09 Release","Approve"]
[1284,"Ability for Third Parties to raise Change Proposals and replacement of energywatch with National Consumer Council.","ELEXON","2009-04-03","ELEXON identified that BSCP40 in 'Parties designated by the Authority' the list currently has no reference to interested third parties designated by the Authority. ELEXON believes that BSCP40 should allow them to propose changes to the Code Subsidiary Documents and other configurable items. This would avoid the potentially anomalous situation of a body being able to propose changes to the Code, but not to the more detailed supporting documentation.\nIn October 2008, the Authority issued a direction3 (referred to on the ELEXON website as ADN0004) to change references to energywatch in the BSC (and other industry codes) to National Consumer Council. BSCP40 still references energywatch, and therefore requires amendment to reflect what is in Section F of the Code.","CP1284 proposes to amend BSCP40 ‘Change Management’ concerning: the ability for Parties designated by the Authority to raise Change Proposals (CPs) to be consistent with Section F2. 1. 1 of the BSC; replacement of references to energywatch with National Consumer Council, in order to be consistent with the code following the Authority Direction that replaced energywatch; and other minor housekeeping changes. The CP is also recommending the removal of references to energywatch from the PrA and Teleswitch Agent Service Descriptions.","ISG: 100                            SVG: 100           ","CPC00660","ISG/SVG","Nov 09 Release","Approve"]
[1283,"Revisions to data correction processes in BSCP18","ELEXON","2009-04-03","ELEXON noted concerns from the industry regarding the efficiency of the current BOA-related data correction process. In particular: the authorisation and processing of significant numbers of BOA-related data corrections following unplanned outages; and Parties not adhering to the timescales stated in BSCP18 will create delays in the processing and authorisation of BOA-related data. This creates a problem as it needs to be complete in time for the Settlement Final (SF) Run.\nThese industry concerns were captured in ISG paper ISG91/04 and presented to ISG at its meeting on 26 August 2008. The ISG agreed that an operational review of BSCP18 should be carried out in order to identify any changes required to BSCP18. ","CP1283 recommends changes to the data correction processes in BSCP18. The key changes to BSCP18 are: stating a specific time period for Parties to respond on receipt of amended Bid Offer Acceptances from the Transmission Company; and the basic principles of the BSCP18 process covers changes made prior to the SF run with the consent of the Transmission Company and Lead Party. It was agreed that ELEXON’s role should be removed from the process.","ISG: 100","CPC00660","ISG","Nov 09 Release","Approve"]
[1282,"Maintenance of Outstation Types as part of Compliance and Protocol Approval","ELEXON","2009-02-27","Outstation Type’ is a data item contained within the D0268 HH Meter Technical Details flow. It is used by Half Hourly (HH) MOAs and HHDCs to determine which protocols must be used in order to dial into a particular Outstation. The MRA Data Transfer Catalogue (DTC) defines ‘Outstation Type’ as a three-character identifier, along with a Valid Set of available codes. Outstation Types are not generic, but rather act as references to specific Outstation makes and models. This means that if and when a new piece of equipment enters the market, it may not properly represented by the Valid Set. At present, altering the Valid Set requires a formal change to the DTC. As a result the Valid Set will often be out of date, and participants will frequently have to resort to manual workarounds.","CP1282 proposes removing the valid set of Outstation Types from the DTC and instead establishing them as part of the Compliance and Protocol Approval process documented in BSCP601.","ISG: 99                    SVG: 100","CPC00658","ISG/SVG","−","Rejected"]
[1281,"Revenue Protection: requiring the NHHDC to send EAC/AA data to the Supplier via the DTC","Npower","2009-02-27","Currently when a Non Half Hourly (NHH) Data Collector (DC) receives advice from the Revenue Protection Business, they are required to record an adjustment to the meter advance based on the unrecorded units estimated by the Revenue Protection Business. The NHHDC then calculates a new Estimated Annual Consumption (EAC) and Annualised Advance (AA) and sends this to the NHH Data Aggregator (DA). ","CP1281 requires NHHDCs to send all EAC/AAs which have been updated in these circumstances: via a D0019 (BSCP504 does not currently specify this); and to the Supplier as well as the NHHDA.","SVG: 99","CPC00658","SVG","Nov 09 Release","Approve"]
[1280,"SVAA to provide LDSOs with aggregated consumption data for embedded Distribution Systems","Independent Power Networks Limited","2009-02-05","The BSC requires the SVAA  to provide Distribution System Operators with metering data for purposes of operating and charging for use of their Distribution Systems. Currently the BSCP only covers metering data for NHH Metering Systems directly connected to the network of the LDSO receiving the data. They do not include: Data for HH Metering Systems Data for Metering Systems connected to other LDSOs’ Distribution Systems embedded within the LDSO’s network. However, the DCUSA provisions for relationships between Distributors acknowledge that boundary metering is not necessarily required in all cases, and that an ‘Alternative Solution’ will be appropriate in some cases. The Primary concern with requiring the boundary metering for embedded metering for all embedded networks is that the cost per meter is high. As the number of IDNO and ‘out of areas’ networks increases, the total cost associated with metering the boundaries between networks will increase. ","CP1280 proposes hat the SVAA should provide each LDSO with aggregated consumption data for customers on licensed networks embedded within that LDSOs’ network, in order to avoid the cost to industry of unnecessary metering at the boundaries between networks.","SVG: 97","CPC00653","SVG","−","Rejected"]
[1279,"Housekeeping Change to BSCP515 – Licensed Distribution","ELEXON","2009-02-04","On page 11 of BSCP515, step 3. 3. 4 has the WHEN action of ‘Within 5WD  of 3. 3. 2′. This should say ‘Within 5WD of 3. 3. 3′. In addition footnote 4, also on page 11, refers to step 3. 3. 4. This should be 3. 3. 3. We implemented CP1199 ‘Changes to BSCP515 ‘Licensed Distribution’ to remove non functional information and add clarity’ in February 2008; however, the agreed redlined text contained this error. CP1199 introduced several changes to the steps of 3. 3, and moved step 3. 3. 2 to 3. 3. 3 but the reference in 3. 3. 4 was not updated. CP1199 also moved step 3. 3. 3 to 3. 3. 4, but didn’t update the reference in footnote 4. ","Cp1279 proposes to correct a change that was clearly not intended by CP1199 by; Updating the WHEN action in step 3. 3. 4 to say ‘Within 5WD of 3. 3. 3′; and Update footnote 4 to say: ‘Note that a Supplier must have appointed an MOA for that Metering System before step 3. 3. 3 can occur. ","SVG: 97","−","SVG","June 09 Release","Approve"]
[1278,"Streamlining the SVA Standing Data Change Process","ELEXON","2009-01-09","BSCP507 ‘Supplier Volume Allocation Standing Data Changes’ sets out the process by which Suppliers are required to update the SVAA each time any changes occur either to a Supplier’s appointment to a GSP Group, or a Supplier’s agent appointments (specifically Data Collectors and Data Aggregators) within a GSP Group. ELEXON believes that this process, introduced by CP1093 in February 2005, is sufficient to ensure that the SVAA maintains an accurate set of standing data without requiring Suppliers to provide manual updates after each change.  ","CP1278 recommends that BSCP507 is modified, so that the processes and forms currently used to notify changes to Standing Data are only used upon a new Supplier’s entry into the market. CP1278 would redesign Form BSCP507/01A to show exactly which information is required at the start-up stage, and to allow all the information to be entered into a single form.","ISG: 100                SVG: 100                PAB: 100","CPC00651/CPC00660","ISG/SVG","Nov 09 Release","Approve"]
[1277,"Change to UMS Charge code Approval Process","Scottish and Southern Energy","2008-12-31","BSCP520 ‘Unmetered Supplies Registered in SMRS’ currently mandates that applications for new Unmetered Supply (UMS) charge codes and switching regimes must be approved by the Supplier Volume Allocation Group (SVG) following a recommendation by the Unmetered Supplies User Group (UMSUG), which meets quarterly. Along with this, the charge code/switching regime must also go through the Market Domain Data (MDD) process which can take up to a month. The impact of this protracted approval process is that approval of a new charge code/switching regime can take up to 4 months. ","CP1277 proposes to incorporate the UMS Charge Code application process within the scope of MDD. ELEXON would construct Charge Codes in consultation with industry experts (where appropriate). ELEXON would use the Market Domain Data Change process (as detailed in BSCP509 ‘Changes to Market Domain Data’) as a means for informing/consulting with the industry on the changes and seeking feedback on impacts. This would include an Impact Assessment which goes out to the industry (including Distributors) as they are the ones most affected by Unmetered equipment. The final stage is approval by the SVG (already part of the BSCP509 process). CP1277 aims to reduce the length of time taken for UMS Charge Codes to be approved. ","SVG: 97","CPC00651","SVG","June 09 Release","Approve"]
[1276,"Process following the Installation of Small Scale Third Party Generating Plant (Alternative to CP1260 ‘Meter Investigation Process where a Site is Capable of Exporting (micro generation","Npower","2009-01-02","Import Suppliers should be able to take the most appropriate course of action on receipt of a D0001 from an LDSO informing them that a site is capable of exporting.","CP1276 takes CP1260 ‘Meter Investigation Process where a Site is capable of Exporting (micro generation)’ as its starting point and uses it to develop a process that enables Import Suppliers to take the most appropriate course of action on receipt of a D0001 from an LDSO informing them that a site is capable of exporting. Unlike CP1260, this Change Proposal is not proposing to mandate Suppliers to carry out an investigation to determine whether the Meter has a backstop if they are already aware that the Meter at site has a backstop. In addition to this it allows flexibility for Suppliers/Meter Operator Agents to maintain current or agree new contractual arrangements.","SVG: 97","CPC00651","SVG","−","Rejected"]
[1275,"Supplier Agents - Access to Meter Protocols ","ELEXON","2009-01-09","The proposed modification to the Standard Conditions of the Electricity Supply Licence condition\n(which is currently being progressed by Ofgem) requires that all Profile Classes 5 to 8 (PC5-8) sites will be metered using advanced metering by 2014. ","ELEXON raised CP1275 on behalf of the Advanced Metering Expert Group, who have developed it as part of the Advanced Metering Operational Framework for Profile Classes 5 to 8. This change will facilitate interoperability on a Change of Supplier where the new Supplier wishes to appoint new agents by enabling the agents’ access to the meter protocol.","ISG: 100           SVG: 99               ","CPC00651","ISG/SVG","Nov 09 Release","Approve"]
[1274,"Transfer of Meter Technical Details","Scottish and Southern Energy","2008-12-19","The NHH Meter Technical Details (D0150) flow does not contain all the required data items for\nadvanced metering. Additionally, there is no BSCP requirement to transfer communication and\npassword details, irrespective of whether the D0150 supports this information (although agents are currently transferring this information through other means). On change of agent, this can result in the new agent receiving Meter Technical Details via the Data Transfer Network (DTN), but not receiving (by other means) sufficient data to read the meter remotely. This can lead to register mapping issues and to further information about the meter having to be exchanged through alternative, less efficient methods. The increased number of advanced meters will make a process relying on communication outside of the DTN difficult to manage. ","Scottish and Southern Energy raised CP1274 on behalf of the Advanced Metering Expert Group, who have developed it as part of the Advanced Metering Operational Framework: Profile Classes 5 to 8. The purpose of the framework is to facilitate effective market operation and interoperability for Profile Classes 5 to 8. This change will facilitate interoperability on a Change of Supplier where the new Supplier wishes to appoint new agents as the agents will be able to read the meter only if they have the required communications and password information.","SVG: 97","CPC00651","SVG","June 09 Release","Approve"]
[1273,"Changes to the scope of CoP10 to cover current transformer operated Meters","E.ON","2009-01-06","Changes to Supplier Licences are due to become effective in April 2009. When implemented,\nSuppliers will be required to install advanced Meters for Profile Classes 5 to 8 customers. Since Profile Classes 5 to 8 customers will include sites which require CT operated Meters in the sub-100kW market, the only option available to Suppliers will be to use a more expensive CoP5 compliant CT operated Meter to provide the advanced functionality required by the new licence condition. ","CP1273 proposes widening the scope of CoP10. CoP10 would include CT operated Meters. This would allow Registrants have the choice of installing a less expensive CoP10 Meter where they envisage a site’s demand remaining below the mandatory HH threshold (100kW), despite requiring CT metering. Alternatively, the Registrant could chose to install a more expensive CoP5 Meter (or above), to meet the requirements for mandatory HH metering should the site’s demand exceed the mandatory HH threshold in the future.","ISG: 97          SVG: 97               ","CPC00651","ISG/SVG","June 09 Release","Approve"]
[1272,"Use of Appointment and Termination Flows in Unmetered Supplies (UMS)","ELEXON","2009-01-09","In a number of instances BSCP520 (BSC Procedure: Unmetered Supplies Registered in SMRS vs. 14.0) requires Suppliers to send D01551, D01482 and D01513 flows to UMSOs when establishing or amending inventories, disconnecting a Metering System ID, or following a Change of Supplier, Data Collector or Meter Administrator. These flows are normally used by Suppliers when appointing and de-appointing Supplier Agents, but in this context they are used to inform the UMSO of the identity of the Data Collector and Data Aggregator appointed for that Unmetered Supply.\nThe Data Transfer Network (DTN) is not configured to allow these flows to be provided to UMSOs electronically, so manual processes have to be used to transfer the information. Because of the difficulties involved, some UMSOs do not make use of the flows and instead retrieve the necessary appointment data from SMRS, which should be updated by the Supplier once the appointments have been made. ","CP1272 proposes to remove the requirement in BSCP520 for Suppliers to send D0155, D0148 and D0151 flows to UMSOs, because the necessary appointment data should have already been entered into SMRS by the Supplier, and so should be available to the UMSO. This option would remove the onus on the Supplier to send the flow to the UMSOs. CP1272 also seeks to include a requirement in BSCP501 for the LDSO to notify the UMSO of any appointment related changes associated with Unmetered Supply. CP1272 looks to remove inefficient processes and replace them with practical solutions that will align with current working practice.","SVG: 97","CPC00651","SVG","June 09 Release","Approve"]
[1271,"Align Market Domain Data Approval Timetable to SVG meetings","ELEXON","2009-01-09","An MDD Expert Group (MDDEG) was set up by the SVG to identify any issues within the current MDD process and to recommend improvements. The group identified that the existing ex-committee process does not allow adequate consideration (via discussion in a meeting) by the SVG of any issue associated with a MDD Change Request. The full conclusions of the  MDDEG can be found in SVG paper 92/04. ","ELEXON raised CP1271 on behalf of the MDD Expert Group. The key dates (e. g. the Change Request deadline and SVAA Impact Assessment) in the current MDD process are derived from monthly PAB dates. CP1271 suggests that these dates are calculated from the monthly SVG dates instead. CP1271 would also allow for a ‘fast track’ option, where newly qualified market participants can submit their MDD changes closer to the SVG meeting date, but still in time to be sent to the SVG for advance review and a decision made at the SVG meeting.","SVG: 97","CPC00651","SVG","June 09 Release","Approve"]
[1270,"Improvements to the Market Domain Data Process ","ELEXON","2009-01-09","At its meeting on 4 March 2008, the Supplier Volume Allocation Group (SVG) agreed that a review of the Market Domain Data (MDD) process should be carried out (see paper SVG85/09). The SVG\nagreed that ELEXON should set up an expert group to review all the current issues and to propose\nimprovements. The resulting MDD Expert Group (MDDEG) developed solutions to a number of identified issues in the MDD process. ","CP1270 proposes amendments to the relevant sections of BSCP509 and BSCP509 Appendix: MDD Entity Change Request Forms.","SVG: 97","CPC00651","SVG","June 09 Release","Approve"]
[1269,"Publication of Additional NHH Combination Data in Market Domain Data","ELEXON","2009-01-09","Market Domain Data (MDD) contains a number of entities that define the valid combinations of data items for an SVA Metering System. However, even when taken in combination, these tables do not provide Suppliers with enough information to know which combinations of NHH Metering System data items will be accepted by Supplier Meter Registration Services (SMRS). A registration request that is consistent with the above MDD tables may still be rejected by SMRS, or queried by the Distributor, if the particular combination of SSC, PC and LLFC does not correspond to a Distribution Use of System (DUoS) tariff on that Distributor's network. This leads to higher costs for both Suppliers and Distributors, who require manual processes to identify and correct these erroneous registrations. ","ELEXON raised CP1269 on behalf of the MDD Expert Group. CP1269 proposes publishing additional NHH Combination Data in MDD, aiming to provide Suppliers with a single, up-to-date source of valid combination data for use in their registration processes. This should make the process of registering Metering Systems in SMRS more efficient, facilitating the smooth operation of the retail market, and competition in supply.","SVG: 97","CPC00651","SVG","Nov 09 Release","Approve"]
[1268,"Publication of new Funds Administration Agent (FAA) Service Description","ELEXON","2009-01-09","Currently, section 5.5.4 of the live FAA SD states that the FAA must update the Credit Cover on notification of the parameter change, as opposed to changing Credit Cover prior to the Effective From Date of the change (which is actually the current process). \n","ELEXON raised CP1268, which aims to gain approval for a new version of the FAA Service Description (SD). We have updated the SD to ensure that the SD accurately and clearly reflects the requirements on the FAA. The new version does not introduce any changes to requirements.","ISG: 97","CPC00651","ISG","June 09 Release","Approve"]
[1267,"Registration of UMSOs and MAs in SMRS","ELEXON","2008-11-27","There are currently operational issues appointing an UMSO in a Grid Supply Point (GSP) Group where there is no longer a Non Half Hourly (NHH) Meter Operator Agent (MOA) which has the same ID as the UMSO operating in that area. There is also currently some confusion regarding the Half Hourly (HH) appointment for UMS, whether to appoint the MA or the UMSO in the MOA field.","CP1267 proposes to amend the validation rules when registering an Unmetered Supplies Operator (UMSO) or Meter Administrator (MA) in Supplier Meter Registration Agent (SMRA). ","SVG: 104","CPC00650","SVG","Nov 10 Release","Approve"]
[1266,"Updates and Refinements to BSCP504","ELEXON","2008-11-27","A review of the BSCP5041 has revealed certain issues/inconsistencies that needed to be corrected within the document. \n. \n","CP1266 will address issues that were highlighted within BSCP504. Addressing these issues will create consistency between the BSCP504, BSCP508 and the MRA Data Transfer Catalogue","SVG: 97","CPC00650","SVG","June 09 Release","Approve"]
[1265,"TAA Documentation Changes Following Review","ELEXON","2008-11-27","In April 2007 the TAA contract was awarded to C & C Group Holdings Ltd (‘C & C Group’).\nELEXON has reviewed the TAA-related documents and has identified changes required to reflect that C & C Group provides the TAA service, not Logica, and to ensure the current TAA activities and obligations are accurately documented. ","Following a review of the TAA documentation, CP1265 aims to create consistency between all TAA related documents, the Code and with the service provided by C& C Group. It will also ensure the services Logica are contractually obliged to provide are consistent with all Logica system and guidance documentation.","ISG: 96             SVG: 97                  PAB: 96","CPC00650","ISG/SVG/PAB","June 09 Release","Approve"]
[1264,"Clarification of Password Requirements in the Codes of Practice","Npower","2008-09-17","There is a current discrepancy amongst the existing Codes of Practice (CoPs) with regard to the password requirements for Half Hourly (HH) metering. ","CP1264 suggests removing the password requirements around case sensitivity, and leaving it to the Meter Manufacturers and Meter Operators as to whether they wish to develop additional security or not.","ISG: 94          SVG: 94               ","CPC00644","ISG/SVG","June 09 Release","Approve"]
[1263,"Changes to Communication Requirements Document arising from Project Isis","ELEXON","2008-09-18","During the implementation phase of the new BSC Services Agreement under Project Isis, there will be two key technical changes to the High Grade Service and Low Grade Service: Installation and transition to a new CVA Communications Network (affecting existing High Grade Service users); and Transition to a new version of the XSec security encryption software (affecting existing High Grade and Low Grade Service users). The new High Grade Service will be implemented as part of Project Isis. All existing users of the High Grade Service have been contacted by the Project Isis team in order to establish their chosen communication technical specification (as detailed in CP1263 Attachment A)The Communications Requirements Document (CRD) defines the communication requirements between participants and the BSC Central Systems. These need to be amended to reflect the new technical interface requirements as detailed above.","CP1263 proposes to amend the CRD to reflect the new communication requirements for the High Grade Service and Low Grade Service. The proposed changes to the CRD are detailed in CP1263 Attachment A.\n","ISG: 94          SVG: 94               ","CPC00644","ISG/SVG","Feb 09 Release","Approve"]
[1262,"Service Improvements - Enhancements to the SVA Applications","ELEXON","2008-09-18","Logica as the Developer and the future SVAA required to enhance the operational processes, functionality and security of the SVA Applications, and will be delivered at zero Service Provider cost ","CP1262 identified a number of potential system enhancements to the SVA Applications. These will support operational processes and improve the security and efficiency of these Applications. These enhancements will automate some of the more manual processes within the BSC Systems, and are an example of some of the service improvements which Project Isis is delivering. We believe that there are no impacts on Configurable Items documentation, or on BSC Party or Party Agent systems and processes. In addition these changes would be implemented at zero cost during the Project Isis Implementation phase.","SVG: 93","CPC0643","SVG","Feb 09 Release","Approve"]
[1261,"Introducing Metering Code of Practice 10 to facilitate smart metering in the Half Hourly (HH) market","ELEXON","2008-08-27","With the introduction of Automatic Meter Reading (AMR) / smart meters comes the opportunity to expand the Half Hourly (HH) elective (sub 100kW) market. The BSC requirements necessary to facilitate this were discussed during the BSC Smart Metering Review. It was agreed that the BSC, in respect of HH processes and controls, should not unnecessarily inhibit participation in this sector of the market. In addition, the processes and controls should be appropriate for the level of consumption being metered. \n","CP1261 has been raised by ELEXON on behalf of the Smart Metering Expert Group. The CP proposes the introduction of a new Code of Practice that should facilitate the use of smart metering in the elective HH market and in so doing, make it more viable for Suppliers to move from NHH to HH without incurring significant costs.","ISG: 93                                SVG: 93               ","CPC00642","ISG/SVG","Feb 09 Release","Approve"]
[1260,"Meter Investigation Process where a Site is capable of Exporting (micro generation)","ELEXON","2008-08-27","P213 ‘Facilitating Microgeneration1 ‘Optional Single MPAN’ was raised by E.ON on 27 April\n2007. The Panel requested that the Supplier Volume Allocation Group (SVG) raise a CP issue to consider whether any changes could be made to improve the current microgeneration Settlement processes in the Code Subsidiary Documents (CSDs). The BSCP40 issue 002 (Review of Microgeneration Processes in the Code Subsidiary Documents) group met twice, considered the microgeneration processes and recommended to made some changes.","The purpose of CP1260 is to ensure that Suppliers are aware when an Import Meter is at risk of capturing Export energy (i. e. when micro generation will be or has been installed on a site) and to create a process for checking (and if necessary, replacing) the Import metering. There is no requirement to fit an Export Meter.","SVG: 97","CPC00642/CPC00651","SVG","−","Rejected"]
[1259,"Distributor-Supplier Notification where a Site is capable of Exporting (micro generation)","ELEXON","2008-08-27","P213 ‘Facilitating Microgeneration1 ‘Optional Single MPAN’ was raised by E.ON on 27 April\n2007. The Panel requested that the Supplier Volume Allocation Group (SVG) raise a CP issue to consider whether any changes could be made to improve the current microgeneration Settlement processes in the Code Subsidiary Documents (CSDs). The BSCP40 issue 002 (Review of Microgeneration Processes in the Code Subsidiary Documents) group met twice, considered the microgeneration processes and recommended to made some changes.","The purpose of CP1259 is to ensure that a process in place for Licensed Distribution System Operators (LDSOs) to inform the Import Supplier on becoming aware that a site is capable of Exporting (micro generation).","SVG: 93","CPC00642","SVG","June 09 Release","Approve"]
[1258,"Changes to BSCP520 Following Walkthrough","ELEXON","2008-08-27","An Unmetered Supplies Expert Group (UMSEG) was convened in 2007 to discuss UMS issues identified by the BSC Auditor. As part of this work the UMSEG carried out a walkthrough of BSCP520 and identified a series of minor changes to improve processes, correct errors and remove any redundant steps. The proposed changes were issued to industry for comment via DCP0029 in February 2009.\n","CP1258 proposes changes to address industry comments. ","SVG: 93","CPC00642","SVG","Feb 09 Release","Approve"]
[1257,"Calculation of EAC for Temporary Supplies","ELEXON","2008-08-27","The UMSEG identified that the rules in BSCP520 for calculating Estimated Annual Consumption (EAC) for temporary supplies are not clear; in particular, they do not reference the splitting of an EAC by Average Fraction of Yearly Consumption (AFYC) or explain which Standard Settlement Configuration (SSC) the EAC should be attributed to.","CP1257 proposes changes to Section 4.4.3 of BSCP520 in order to clarify the current process and to clearly explain how UMSOs should annualise the EAC for temporary supplies. The proposed wording is included in Attachment A. ","SVG: 93","CPC00642","SVG","June 09 Release","Approve"]
[1256,"Action on Backdated D0052 Flows","ELEXON","2008-08-27","On occasions it may be necessary for Suppliers or UMSOs to issue D0052 ‘Affirmation of Metering System Settlement Details’ to NHHDCs with backdated Effective From dates in order to correct previously-provided data. It is not clear from the current documentation how such D0052s should be processed by NHHDCs, and in particular, whether the data on the new flow should overwrite all previous data provided via the D0052 or only that which is in place up to the next Effective From date.","CP1256 proposes the following when handling backdated D0052s: on receipt of a backdated D0052, NHHDCs should overwrite all previous data (including EACs) for that Metering System; if a Supplier or UMSO does not wish to overwrite any previously-supplied data, they must re-send the appropriate D0052s to the NHHDC in the correct order; a D0052 backdated over 14 months must be amended by the Supplier or UMSO to the earliest effective from date for which a Final Reconciliation Run has not taken place, otherwise it cannot be processed by the NHHDC. Changes are required to BSCP504 and BSCP520. ","SVG: 93","CPC00642","SVG","June 09 Release","Approve"]
[1255,"Service Descriptions and other CSD Inconsistencies","ELEXON","2008-08-27","As part of the procurement phase of Project Isis, ELEXON drafted detailed contracts of Business Requirements for the CVA, SVA and FAA Agent Services to issue to tenders. The Business Requirements were also reviewed against the BSC and Code Subsidiary Documents as part of a due diligence exercise. As a result of this review a number of inconsistencies have been discovered in a number of BSCPs, the CVA/SVA Data Catalogues and the Communication Requirement Document. The majority of these issues have been resolved by CP1223 ‘Inconsistencies within the Code Subsidiary Documents regarding Business Requirements’, which was implemented in the June 2008 Release. ","CP1255 proposes to amend step 3.1.10 of the process for the Registration of a New Metering System contained in Section 3 of BSCP20 to correctly reflect the role of the CDCA in the registration process. it also proposes to add a new paragraph 2.6.7 to the SAA Service Description to reference the receipt and usage of Arbitrage Flag. ","ISG: 93 ","CPC00642","ISG","Feb 09 Release","Approve"]
[1254,"Prevention of Unauthorised Access to AMR / Smart Meters","ELEXON","2008-08-27","AMR/smart meters are already being introduced in the Non-Half Hourly (NHH) market. The roll out of this type of metering is set to increase over the next few years. Meters with remote access are open to the risk of unauthorised access to meter reading data and/or the meter configuration and of insecure communication methods. This issue was identified during the BSC Smart Metering Review. ","CP1254 progresses the BSC requirements and the proposed solution which were considered and agreed by the smart metering expert group.","ISG: 93            SVG: 93               ","CPC00642","ISG/SVG","Feb 09 Release","Approve"]
[1253,"Remote Reading Assurance","ELEXON","2008-08-27","A number of issues were identified around providing assurance around remote readings entering Settlement: There is currently no requirement that readings retrieved remotely are the same as readings on the display of the meter. There is a risk that inferior / inappropriate communications equipment (hardware or software) could give rise to erroneous data entering Settlements. There is also a risk that a meter read remotely is not the meter the Data Collector / Data Retriever thinks is being read. Currently a number of checks are carried out by the NHHDC when visiting the site (Appendix 4. 1 of BSCP504 ‘Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’). If a meter is read remotely a site visit will not take place and so these checks will not be undertaken. These issues were identified during the BSC Smart Metering Review. ","CP1253 proposes changes to BSCP504 which would provide assurance against erroneous data entering Settlement due to a number of potential risk areas around meter reading and data transfer. ","ISG: 93            SVG: 93                 PAB: 93","CPC00642","ISG/SVG/PAB","Feb 09 Release","Approve"]
[1252,"Reading Submission Frequency for AMR Meters","ELEXON","2008-08-27","NHH Data Collectors are currently obligated to submit all valid readings obtained for credit meters to Settlements. This obligation is held within section 1. 2. 1 of BSCP504 ‘Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’. The increasing deployment of AMR / smart metering is likely to result in many more readings being obtained for the associated meters than is currently the case. If all these readings need to be processed within Settlements this is likely to have significant capacity and performance implications for NHHDC and NHHDA systems and processes. It is likely that the cost to the industry of this, and ultimately the customer, would be disproportionate to the increased accuracy of Settlements and would inhibit wide scale roll-out of AMR. This issue was identified during the BSC Smart Metering Review. The BSC requirements and the proposed solution were considered and agreed by the smart metering expert group.","CP1252 proposes that the requirement to submit all remote meter readings into Settlement irrespective of reading frequency should be relaxed (similar to the requirements around pre-payment meters in section 4.11 of BSCP504). The requirements to transfer meter reading history upon a change of NHHDC should also align with these relaxed data submission requirements. It is recognised that the NHHDC may receive readings from remotely read Metering Systems on a frequent basis. Readings should continue to be processed for Settlement purposes, subject to the following exception: routine readings that, if omitted from settlement, do not result in there being more than three months between valid readings for a Profile Class 1-4 MS or more than one month between valid readings for a Profile Class 5-8 MS. For the avoidance of doubt, if Meter readings have not been collected within the periods specified above, then no Meter readings are required to be processed. The Supplier and NHHDC could still decide to submit readings more frequently. The proposed solution would be the minimum Settlement requirement. ","SVG: 93","CPC00642","SVG","Feb 09 Release","Approve"]
[1251,"Ensuring Inferior / Inappropriate Peripheral Devices not used to Collect AMR Reads","ELEXON","2008-08-27","AMR / smart meters are already being introduced in the Non-Half Hourly (NHH) market. The roll out of this type of metering is set to increase over the next few years. With smart / AMR reads there is a risk that inferior or inappropriate peripheral devices (hardware and software) will be used to obtain readings for Settlement purposes, particularly as these devices are not subject to S. I. 2006/1679 or Ofgem approval and there are limited controls over their use. This issue was identified during the BSC Smart Metering Review. The BSC requirements and the proposed solution were considered and agreed by the smart metering expert group.","Cp1251 proposes to include a requirement in CoP8 and CoP9 that readings for use in Settlement must be the kWh values obtained from the primary register(s) of a meter that is compliant with S.I.1679 or are Ofgem approved.  Recommendations highlighted within CP1261 ‘Introducing Metering Code of Practice 10 to facilitate smart metering in the Half Hourly (HH) market’, would introduce a similar set of requirements within the proposed CoP10.\n","SVG: 93","CPC00642","SVG","Feb 09 Release","Approve"]
[1250,"Increase opportunity to update the NMTES","ELEXON","2008-08-27","The National Measurement Transformer Error Statement (NMTES) is a list of generic accuracy errors for some types of Metering Equipment used in Settlement. The Technical Assurance Agent (TAA) uses this information when site visits are made to assess compliance with a Code of Practice (CoP) where individual test results are not available. The items currently listed are not representative of all of the equipment in use and the mechanism for amending the list is not practical. ","CP1250 proposes that BSCP515 section 3. 10. 1. 1 should be change as follows: ‘Submit a minimum sample of 50 CT or 10 VT errors obtained from test records. ‘","SVG: 93","CPC00642","SVG","Feb 09 Release","Approve"]
[1249,"MDDM and SVAA Terminology","ELEXON","2008-08-08","One of the responsibilities of the Supplier Volume Allocation Agent (SVAA) is to maintain Market Domain Data (MDD). In carrying out this activity, the SVAA acts as the Market Domain Data Manager (MDDM) and has a specific Market Participant Role Code registered in MDD that relates to this activity. As part of the procurement phase of Project Isis, ELEXON has identified that the use of the terms ‘SVAA’ and ‘MDDM’ in the SVA Data Catalogue and associated BSCPs is not always accurate, and as a result it can be unclear whether a process is meant to involve the SVAA or MDDM role. This can have practical implications when handling MDD-related communications. ELEXON has carried out a review of the SVA Data Catalogue to identify instances where data flows are not using the correct SVAA/MDDM terminology, or are not giving an accurate reflection of flow usage as required by the BSCPs. ELEXON has also checked the Data Catalogue for any other non-material errors that may be resolved at the same time.","CP1249 proposes to modify the SVA Data Catalogue to correctly identify the SVAA or MDDM as the sender or recipient of MDD-related data flows.","SVG: 94","CPC00644","SVG","June 09 Release","Approve"]
[1248,"Early release of Meter Technical Details by Non Half Hourly Meter Operator Agent","ELEXON","2008-07-04","ELEXON analysed the timings around the change of supply D149 / 150 from Meter Operators which show that the majority of MOPs issue the D149 / 150 to the supplier approximately two days after receipt of the D148 into their systems (equivalent to 4 workings days after the D155 has been sent). The timely issuing of these flows enables suppliers to progress change of supply registrations swiftly allowing punctual set up of the customer within the suppliers systems. This has benefits to the supplier, customer and MOP. However, not all MOPs issue the D149 / 150 flows based upon the receipt of the D148 and some hold the flows until the supply start date which can be up to 16 working days later. This results in the customer’s record being set up unnecessarily late in the suppliers systems. ","CP1248 proposes to amend BSCP514 to reduce the time allowed for the NHH MOA to release the MTD to the Supplier, NHHDC, LDSO, current NHHMOA to new NHHMOA, and NHHMOA to HHMOA","SVG: 97","CPC00651","SVG","Nov 09 Release","Approve"]
[1247,"BMRS Amendments to Report Interconnector","ELEXON","2008-05-12","The BMRS has a System Warning page, which displays messages sent to BMRS by National Grid. At market start-up  it was envisaged that this page would be used primarily for System Warnings as defined in the Grid Code. However, National Grid also use it for other purposes. In particular, they currently send two messages per day relating to SO-SO Interconnector Trades (on the French and Moyle Interconnectors). There is concern that these SO-SO Interconnector messages may mask more critical messages. The proposed solution is to create a new page that will only display SO-SO Interconnector messages, leaving the existing System Warning page to display those messages that are not SO-SO Interconnector messages. This will add clarity so messages which may be more important to the market can be clearly seen.","CP1247 proposes to remove the messages relating to SO-SO prices from the System\nWarning page, and put them on a new page instead. The new page will be similar to the existing\nSystem Warning page, but display only those messages that relate to SO-SO prices. It is proposed\nthat any warning whose text contains the phrase “prices for SO to SO transactions” (in any\ncombination of upper or lower case) will be treated as falling into that category. ","ISG: 88","CPC00634","ISG","Nov 08 Release","Approve"]
[1246,"A New Interface from BMRS to the ETSOVista Reporting System","ELEXON","2008-05-12","ETSOVista is a market information website developed by the association of European Transmission System Operators (ETSO) in order to provide a single source of market data across the EU’s Internal Electricity Market. ETSOVista is designed to receive data from organisations within each member state and publish this data via a common web platform. National Grid (as TSO for Great Britain) has so far taken the lead on delivering British data to the ETSOVista platform. However, certain data items are calculated by BMRS, and National Grid has suggested to ELEXON that a more robust and efficient solution would be for BMRS to provide these data items to ETSOVista directly.","CP1246 noted the following data items are best provided to ETSOVista directly from BMRS:\n• A Balancing Mechanism Trend flag. This flag can have three different values, corresponding to\nthe cases NIVj>0, NIVj<0 and NIVj=0.\n• The Global Imbalance i.e. the value (in MWh) of NIVj.\n• The System Sell Price (SSPj) and System Buy Price (SBPj) for the Settlement Period.\nThe System Sell Price and System Buy Price will need to be converted from sterling to euros.","ISG: 88            SVG: 88","CPC00634","ISG/SVG","Nov 08 Release","Approve"]
[1245,"Communication of Data Estimations and Substitutions for Central Volume Allocation Metering Systems","British Energy","2008-04-24","BSCP03 (Data Estimation and Substitution for Central Volume Allocation) describes the process for agreeing the appropriate metered data values associated with Active Energy meters to be used by CDCA for CVA when there is a problem with the values obtained via the normal metered data collection process. In some circumstances the current process can lead to uncertainty for registrants as to precisely which data have been or will be used in Settlement aggregation. This can complicate validation and consequently has potential to reduce Settlement accuracy. \n","CP1245 proposes to increase the frequency of the I014 flow. Rather than monthly it would be issued regularly on a daily basis. The flow will be produced at the end of each day to report on estimation activity carried out during the previous day. The I037 flow would continue to be sent by CDCA for the purposes of agreeing to the estimates. Adopting this solution would ensure that should the Registrant consider comparing the aggregated BMU metered volumes provided by SAA with its own aggregation of the metered data provided by CDCA, it would be doing so with the certainty that its aggregation comprised the most up to date metered data submitted to Settlement.","ISG: 89","CPC00633","ISG","Nov 08 Release","Approve"]
[1244,"Remove Authorisation Categories ZB & ZC from BSCP38 and amend BSCP537 to remove relevant references to BSCP38 and to include an amended statement on who can submit BSCP537 forms to ELEXON","ELEXON","2008-04-02","The implementation of P197 “SVA Qualification Process Review” in August 2007 introduced two new Authorisation Categories into BSCP38, ZB and ZC. These Categories were initially managed by ELEXON, however the implementation of CP1193 “Recommended changes following an operational review of BSCP38″ as part of the November 2007 release effected the transfer of responsibility for all BSCP38 Authorisation Categories to the CRA. Authorisation Categories ZB & ZC relate to all Market Participants that are required to comply with BSCP537, which includes SVA Party Agents such as Data Collectors, Data Aggregators and SVA MOAs. The CRA system does not currently store information on SVA Party Agents, so cannot process requests from SVA Party Agents to register Category ZB & ZC Authorised Persons. ","CP1244 proposes the removal of Authorisation Categories ZB & ZC from BSCP38 and amend BSCP537 and BSCP537 Appendix 1 to remove all references to BSCP38 and to include an amended statement, in BSCP537, on who (Company Director or equivalent) can submit BSCP537 forms to ELEXON.","ISG: 88            SVG: 88           PAB: 88","CPC00632","ISG/SVG/PAB","Nov 08 Release","Approve"]
[1243,"Mandating HHDC checks on quality of Meter Technical Details","ELEXON","2008-03-11","Following the presentation of the check results, the SVG (SVG73) asked ELEXON to progress a\nchange to the existing arrangements to mandate that HHDCs carry out a check against their systems on a regular basis to identify instances of both: main and check Meter set up error and Meter registration against an incorrect CoP.","CP1243 proposes that a new section be added to the appendices of BSCP502. This new section will mandate that HHDCs run a check on their systems each month to identify all instances of CoP1, 2 or 3 MSIDs on their system which have two main Meters registered to them. Additionally, the section will mandate that HHDCs identify CoP5 MSIDs which have check Meters registered to them. The HHDCs should then follow up these instances as necessary with the HHMOA, in order to understand whether each of the instances identified is genuine or has incorrect Meter Technical Details held against it. Where an instance is identified the HHDC should request a corrected D0268 from the HHMOA and inform the Supplier. Though it is anticipated that instances of incorrect main/check Meter registration will relate to CoP2 and 3, it is proposed that CoP1 MSIDs are included in the provision to cover any situations not envisaged and to ‘future proof’ the check requirement. Several HHDCs currently run a check to identify main and check Meter set up errors. It is therefore the intent of this CP that the proposed requirement would be as flexible as possible, to minimise disruption to existing processes.","SVG: 88","CPC00632","SVG","−","Rejected"]
[1242,"Movement of the functional requirements within PSL 180 ‘CVA Meter Operation’ into BSCP02 and BSCP06","ELEXON","2008-02-29","The CSD review highlighted a large amount of duplication between the requirements in the PSLs and the corresponding BSCPs. To resolve this issue a single generic PSL has been created under CP1182 ‘Creation of a generic Party Service Line’ which will contain participants’ non-functional requirements. ","Following on from CP1182, CP1242 seeks to move the functional requirements of PSL180 ‘CVA Meter Operation’ into BSCP06.","ISG: 88           SVG: 88           PAB: 88","CPC00632","ISG/SVG/PAB","Nov 08 Release","Approve"]
[1241,"Clarification of Interest payments by Non-Paying BSC Debtors","ELEXON","2008-02-29","The current practice for charging interest to Non-Paying BSC Debtors is not as set out in the Code (N 9. 4). Modification P214 resolves this issue by deleting the current N9. 4. 1(a). However, the actual practice for charging interest to both the Non-Paying BSC Debtor and other Parties remains undefined. ","CP1241 proposes that the FAA Service Description is updated to include a statement describing the actual FAA practice for charging interest to Non-Paying BSC Debtors.","ISG: 88","CPC00632","ISG","Nov 08 Release","Approve"]
[1240,"Amendment to the Qualification Letter in BSCP537 to re-enforce the existing formulation for the legal status of the newly appointed Qualification Service Provider.","ELEXON","2008-02-29","On 11 January 2007 the Panel approved the establishment of a new BSC Procedure, BSCP537\n‘Qualification Process for SVA Parties, SVA Party Agents and CVA MOAs’ (122/07). Authority\nfor approval of subsequent changes to BSCP537 was delegated jointly to the ISG and SVG. ELEXON has appointed a Qualification Service Provider (QSP) to provide certain elements of the Qualification Process. During the QSP appointment negotiations, the QSP requested that additional\nwording be added to the Qualification Letter to emphasise the already stated legal position, i.e. that\nthe QSP shall have no liability to the Applicant. ","CP1240 seeks to add additional wording to the BSCP537 Qualification Letter as proposed by the Qualification Service Provider to reinforce the existing legal position.","ISG: 88            SVG: 88           PAB: 88","CPC00632","ISG/SVG/PAB","Nov 08 Release","Approve"]
[1239,"Registration of Non-Standard BM Units","ELEXON","2008-02-29","BSCP15 (Registration of BM Units) details the procedures and timescales a Party must follow to register a BM Unit. In practice a Party must start the registration process at least 30 working days before the Effective From Date of the BM Unit. However, there is no process or timescale detailed for the approval of nonstandard BM Units and some Parties have been leaving the submission for approval of such BM Units to the time set out in BSCP15 for the registration of standard BM Units. This does not always leave enough time for ELEXON to analyse the application and prepare and present a paper to the Imbalance Settlement Group (ISG) for decision and still meet the required Effective From Date of the BM unit. ","CP1239 proposes to modify BSCP15 to state that applications for non-standard BM Units will require longer timescales, and that Parties should contact ELEXON in the first instance so that potential Effective From Dates may be discussed.","ISG: 88            SVG: 88        ","CPC00632","ISG/SVG","Nov 08 Release","Approve"]
[1238,"Requirement to mandate compliance testing for Meters and Outstations","ELEXON","2008-02-29","ELEXON believed that in order to ensure consistency and clarity it is proposed that amendments be made to the relevant CoPs (being CoPs 1, 2, 3, 5 and 6) to confirm that the method of establishing that the relevant item or type of Metering Equipment complies with the relevant CoPs (and any other relevant Code Subsidiary Documents) is for Parties to demonstrate that the processes set out in BSCP601 for Meter Protocol Approval and Compliance Testing have been complied with and that any other requirements in the CoPs and any relevant Code Subsidiary Document have been met. ","CP1238 proposes to include an amendment to CoP1, 2, 3, 5, and 6 stating that for Meters and Outstations, compliance with the CoP shall be evidenced by following the relevant procedures and requirements set out in BSCP601 and obtaining the appropriate certificates and approvals.","ISG: 88            SVG: 88        ","CPC00632","ISG/SVG","Nov 08 Release","Approve"]
[1237,"Movement of functional requirements in PSL160 to BSCP501 following the creation of generic non-functional PSL100","ELEXON","2008-02-29","The CSD review highlighted a large amount of duplication between the requirements in the PSLs and the corresponding BSCPs. To resolve this issue a single generic PSL has been created under CP1182 ‘Creation of a generic Party Service Line’ which will contain participants’ non-functional requirements. ","Following on from CP1182, CP1237 was raised on 29 February 2008 by ELEXON following the implementation of CP1182 and seeks to move the functional requirements of PSL160 ‘Supplier Meter Registration Service’ into BSCP501.","ISG: 88             SVG: 88        ","CPC00632","ISG/SVG","Nov 08 Release","Approve"]
[1236,"Clarification of De-Energised and Disconnection Processes - Obligations under BSCP 515","Scottish Power","2008-02-29","The BSC Auditors have reported compliance failures with respect to LDSO’s not meeting the 5 Working Days (WDs) to issue confirmation of a change on Energisation status (D0139), an obligation in BSCP515. The reported failures relate to the BSC Auditor’s interpretation that the 5 WDs relates to the time of the request or the proposed date of visit contained within the flow, rather than the actual date of Energisation. ","CP1236 was raised by ScottishPower and proposes amendments to BSCP515 to provide clarity regarding the issuing of a change of Energisation status (D0139 flow) to prevent further differing interpretation of the code.","SVG: 88","CPC00629","SVG","−","Rejected"]
[1235,"Movement of Functional Requirements in PSL150 (‘Half Hourly Data Aggregation’) to BSCP503 following the creation of PSL100 for generic non functional requirements.","ELEXON","2008-02-29","The CSD review highlighted a large amount of duplication between the requirements in the PSLs and the corresponding BSCPs. To resolve this issue a single generic PSL has been created under CP1182 ‘Creation of a generic Party Service Line’ which will contain participants’ non-functional requirements."," Following on from CP1182, CP1235 was raised following the implementation of CP1182 and seeks to move the functional requirements of PSL150 ‘Half Hourly Data Aggregation’ into BSCP503.","ISG: 87          SVG: 87          PAB: 87","CPC00629","ISG/SVG/PAB","Nov 08 Release","Approve"]
[1234,"Movement of the functional requirements within PSL110 to BSCP514 and BSCP550, following the creation of a generic non functional PSL (PSL100) via CP1182.","ELEXON","2008-02-29","The CSD review highlighted a large amount of duplication between the requirements in the PSLs and the corresponding BSCPs. To resolve this issue a single generic PSL has been created under CP1182 ‘Creation of a generic Party Service Line’ which will contain participants’ non-functional requirements. ","Following on from CP1182, CP1234 was following the implementation of CP1182 and seeks to move the functional requirements of PSL110 ‘SVA Meter Operation’ into BSCP514 ‘SVA Meter Operations for Metering Systems Registered in SMRS’ and BSCP550 ‘Shared SVA Meter Arrangement of Half Hourly Import and Export Active Energy’.","ISG: 87          SVG: 87          PAB: 87","CPC00629","ISG/SVG/PAB","Nov 08 Release","Approve"]
[1233,"Transfer of the NHHDA functional requirements from PSL140 to BSCP505","ELEXON","2008-02-29","The CSD review highlighted a large amount of duplication between the requirements in the PSLs and the corresponding BSCPs. To resolve this issue a single generic PSL has been created under CP1182 ‘Creation of a generic Party Service Line’ which will contain participants’ non-functional requirements. ","Following on from CP1182, CP1233 was to move the functional requirements of PSL140 ‘Non Half Hourly Data Aggregation’ into BSCP505 ‘Non Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’.","ISG: 87          SVG: 87          PAB: 87","CPC00629","ISG/SVG/PAB","Nov 08 Release","Approve"]
[1232,"Clarification of Technical Requirements for CoP2","Npower","2008-02-29","Changes to CoP2 have resulted in existing Meters and/or Outstations that were previously compliant with CoP2, being non-compliant. Due to the lack of new products which have been developed that do comply with the requirements of CoP2, there are few products available for new installations. This relatively minor change would amend the requirements to the point where equipment, compliant before February 2008, would continue to be compliant and would continue to be available for new installations, whilst new products are being developed and approved.","CP1232 proposes to amend CoP2 Issue 4 v3.0, Section 5.5 ‘Outstation’, paragraph 8, to specify that Outstations that are not exclusive to one circuit shall be fitted with an auxiliary supply terminal to provide for energisation of the Outstation for remote interrogation purposes. It will also be necessary to amend the text relating to the check performed by the Compliance Testing Agent to confirm that Meters with integral Outstations have an auxiliary supply terminal. i.e. test reference number 049 in section 3.4.14 ‘Outstation {5.5}’ of BSCP601 ‘Metering Protocol Approval and Compliance Testing’. It is recommended that as part of this change a housekeeping change is made at the same time to remove a duplicated row in this section (i.e. test reference number 50). ","ISG: 88           SVG: 88        ","CPC00632","ISG/SVG","Nov 08 Release","Approve"]
[1231,"Housekeeping Change to BSCP15","ELEXON","2008-01-28","Changes to CoP2 have resulted in existing Meters and/or Outstations that were previously compliant with CoP2, being non-compliant. Due to the lack of new products which have been developed that do comply with the requirements of CoP2, there are few products available for new installations. This relatively minor change would amend the requirements to the point where equipment, compliant before February 2008, would continue to be compliant and would continue to be available for new installations, whilst new products are being developed and approved.","CP1231 proposes to replace the deleted “Effective From Date” text in BSCP15 form section 4.4.\nIn order to remove any confusion and to keep consistency with documentation versioning, it is proposed that CP1231 is implemented alongside CP1201 as part of the February Release. Meaning that v13.0 of BSCP15 will go live on 28th February 2008. ","ISG: 88           SVG: 88        ","−","ISG/SVG","Feb 08 Release","Approve"]
[1230,"Movement of the functional requirements within PSL120 ‘Non Half Hourly Data Collection’ to BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems registered in the SMRS’, following the creation of a generic non functional PSL (PSL100) via CP118","ELEXON","2008-01-11","A single generic PSL has been created under CP1182 which will contain participants’ non-functional requirements. ","Following on from CP1182, CP1230 was raised on 11 January 2008 by ELEXON and seeks to move the functional requirements of PSL120 ‘Non Half Hourly Data Collection’ into BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems registered in the SMRS’. The removal of the duplication between PSL120 and BSCP504 will mean that Meter Administrators (MAs) will only have to look in one place to find the functional requirements relating to their role, which may be particularly useful to new entrants. This change will also reduce the cost associated with preparing and maintaining numerous and duplicated PSLs.","SVG: 85","CPC00625","SVG","June 08 Release","Approve"]
[1229,"Effective Date Validation in the D0052","ELEXON","2008-01-11","The D0310 data flow is an error report for the D0052. It is generated when a D0052 either fails to load or is missing. The D0310 is sent from the NHHDC to the D0052 source and includes a Failure Reason Code for the Supplier/UMSO to act upon. The industry is currently experiencing large volumes of D0052 failures. A large proportion of these failures are the result of inconsistent Effective From Settlement Dates (EFSD), where in most cases the Settlement data values are consistent. ","CP1229 proposes to adopt a flexible approach to D0052 validation such that D0052s can not\nbe rejected solely on the basis of EFSD mismatches. Data can be stored and transferred in any\nconvention, but must be validated by NHHDCs according to defined rules. The changes relates to\nBSCP504 Section 4.12. The redline changes are laid out in the appendix section 1.","SVG: 85","CPC00625","SVG","Nov 08 Release","Approve"]
[1228,"CRA Service Description Re-write","ELEXON","2008-01-11","The Central Registration Agent (CRA) Service Description (SD) sets out the obligations and responsibilities placed on the CRA by the BSC and the BSCPs in respect of the receipt, validation, registration, and reporting of registration data pertaining to BSC Parties, Party Agents and BSC Agents. Project Isis background work has highlighted that the CRA SD does not accurately reflect the provisions of the BSC or current working practices."," DCP0015 proposes to update the CRA SD which will create an accurate description that will facilitate the efficient registration of participant details, and will make the operation of the CVA BSC Systems more efficient and effective.","ISG: 89","CPC00625","ISG","June 08 Release","Approve"]
[1227,"AFYC Recalculation","ELEXON","2008-01-11","Previously it had been thought that the Annual Fraction of Yearly Consumption (AFYC) recalculation was being carried out incorrectly. It has since been established that the calculation is correct but there is an error in Volume 1 of the ISRA Technical Specification which is in conflict with Volume 4 where the process is described correctly. ","CP1227 seeks to amend the Volume 1 description to bring it in line with Volume 4, in order to prevent further misinterpretation as a result of the inconsistency between Volume 1 and Volume 4.","SVG: 85","CPC00625","SVG","June 08 Release","Approve"]
[1226,"Amendment to the ‘Investigate inconsistencies’ section of BSCP504 to comply with DTC configuration","Npower","2008-01-11","Npower required to amend the ‘Investigate Inconsistencies’ section of BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems registered in the SMRS’ in order to comply with DTC configuration. ","CP1226 seeks to make amendments to the ‘Investigate Inconsistencies’ section of BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems registered in the SMRS’ to comply with DTC configuration. BSCP504 outlines the obligation for Supplier to notify the NHHDC of inconsistencies, and request investigation, on a D0001 flow. Additionally, this section also references the sending of the D0095 NHH Data Aggregation Exception Report from the Supplier to the NHHDC. Both the sending of a D0001 and a D0095 from the Supplier to the NHHDC is not supported in the Data Transfer Catalogue. CP1226 seeks to address this invalid instruction.","SVG: 85","CPC00625","SVG","June 08 Release","Approve"]
[1225,"Review of D0215 ‘Provision of Site Technical Details’ and surrounding processes","ELEXON","2008-01-11","ELEXON required to review the D0215 ‘Provision of Site Technical Details’. ","CP1225 details the review of the D0215 ‘Provision of Site Technical Details’ and surrounding processes. The solution identifies two areas of the D0215 review that is seeking support to progress to a CP The first proposed solution of the D0215 review, is to add a new process to BSCP515 ‘Licensed Distribution’ to cover the Change of Meter Operator Agent (CoMOA) scenario so that an incoming MOA can send a D0170 ‘Request for Metering System Related Details’ data flow to the Licensed Distribution System Operators (LDSO) after their appointment date, which will help incoming MOAs gain a fuller picture of the metering installation. The second proposed solution of the D0215 review is to add a new process to BSCP515 to cover updates to the LDSO systems such that these events will trigger LDSO systems to send an unsolicited D0215 to the relevant MOA and Supplier. CP1225 was previously issued for participant Impact Assessment as DCP0014 on 7 September 2007, and has since been converted into CP1225.","SVG: 85","CPC00625","SVG","Nov 08 Release","Approve"]
[1224,"The Review of Code of Practice 4","ELEXON","2007-11-09","In 2005 members of the Supplier Agent Forum (SAF) requested a review of CoP4 on the grounds that CoP4 has not been reviewed or changed substantively for over 10 years. Since that time Meter technology and standards technology has advanced sufficiently to warrant a review of their calibration periods. ","CP1224 was raised by ELEXON on 9 November 2007 and details the review process of Code of Practice (CoP) 4 and the suggested changes to the document that have come out of the review process. The requirements of the new version of CoP4 will better reflect the current market/environment and provide a more cost effective balance between monitoring Metering System accuracy and the impact inaccuracies may have on Settlement.","ISG: 89           SVG: 85            BSC Panel: 138","CPC00621","ISG/SVG/BSC Panel","Nov 08 Release","Approve"]
[1223,"Inconsistencies within the Code Subsidiary Documents regarding Business Requirements","ELEXON","2007-11-09","As part of the procurement phase of Project Isis, ELEXON drafted detailed contracts of Business Requirements for the CVA, SVA and FAA Agent Services to issue to tenders. The Business Requirements were also reviewed against the BSC and Code Subsidiary Documents as part of a due diligence exercise. ","CP1223 intends to amend the relevant BSCPs, Data Catalogues and IDDs to remove minor inconsistencies, which require updating to make sure that the new contracts in February 2009 are consistent with the Business Requirements of the CVA and SVA Operator hosts.","TDC: 109        ISG: 88           SVG: 84         PAB: 84","CPC00621","TDC/ISG/SVG/PAB","June 08 Release","Approve"]
[1222,"Inconsistencies within the SAA Service Description and URS","ELEXON","2007-11-09","As part of the procurement phase of Project Isis, ELEXON drafted detailed contracts of Business Requirements for the CVA, SVA and FAA Agent Services to issue to tenders. The Business Requirements were also reviewed against the BSC and Code Subsidiary Documents as part of a due diligence exercise. ","CP1222 details the minor inconsistencies discovered in the SAA Service Description and SAA URS, which require updating to make sure that the new contracts in February 2009 are consistent with the Business Requirements of the CVA and SVA Operator hosts.","ISG: 83","CPC00621","ISG","June 06 Release","Approve"]
[1221,"Inconsistencies within the ECVAA Service Description","ELEXON","2007-11-09","As part of the procurement phase of Project Isis, ELEXON drafted detailed contracts of Business Requirements for the CVA, SVA and FAA Agent Services to issue to tenders. The Business Requirements were also reviewed against the BSC and Code Subsidiary Documents as part of a due diligence exercise. ","CP1221 details the minor inconsistencies discovered in the ECVAA Service Description, which require updating to make sure that the new contracts in February 2009 are consistent with the Business Requirements of the CVA and SVA Operator hosts.","ISG: 83","CPC00621","ISG","June 06 Release","Approve"]
[1220,"Inconsistencies within the BMRA Service Description","ELEXON","2007-11-09","As part of the procurement phase of Project Isis, ELEXON drafted detailed contracts of Business Requirements for the CVA, SVA and FAA Agent Services to issue to tenders. The Business Requirements were also reviewed against the BSC and Code Subsidiary Documents as part of a due diligence exercise.","CP1220 details the minor inconsistencies discovered in the BMRA Service Description, which require updating to make sure that the new contracts in February 2009 are consistent with the Business Requirements of the CVA and SVA Operator hosts.","ISG: 83","CPC00621","ISG","June 06 Release","Approve"]
[1219,"Inconsistencies within the CDCA Service Description and URS","ELEXON","2007-11-09","As part of the procurement phase of Project Isis, ELEXON drafted detailed contracts of Business Requirements for the CVA, SVA and FAA Agent Services to issue to tenders. The Business Requirements were also reviewed against the BSC and Code Subsidiary Documents as part of a due diligence exercise. ","CP1219 details the minor inconsistencies discovered in the CDCA Service Description and CDCA URS, which require updating to make sure that the new contracts in February 2009 are consistent with the Business Requirements of the CVA and SVA Operator hosts.","ISG: 83","CPC00621","ISG","June 08 Release","Approve"]
[1218,"Movement of the functional requirements within PSL 170 ‘Meter Administrator’ to BSCP520 ‘Unmetered Supplies Registered in SMRS’, following the creation of a generic non functional PSL via CP1182.","ELEXON","2007-11-09","The Code Subsidiary Document (CSD) review highlighted a large amount of duplication between the requirements in the Party Service Lines (PSLs) and the corresponding Balancing and Settlement Code Procedures (BSCPs).\r A single generic PSL is being created under CP1182 ‘Creation of a generic Party Service Line’ which will contain participants’ non-functional requirements. \n","Following on from CP1182, DCP0010 seeks to remove PSL170 ‘Meter Administrator’ and include the functional requirements in BSCP520 ‘Unmetered Supplies Registered in SMRS’. The removal of the duplication between PSL170 and BSCP520 will mean that Meter Administrators (MAs) will only have to look in one place to find the functional requirements relating to their role, which may be particularly useful to new entrants. This change will also reduce the cost associated with preparing and maintaining numerous and duplicated PSLs.\n","SVG: 84","CPC00621","SVG","June 08 Release","Approve"]
[1217,"Discontinuing the BMRS High Grade Website","ELEXON","2007-11-09","In recent years the cost of amending the Balancing Mechanism Reporting Service (BMRS) to implement new reporting requirements has come to be perceived by the Imbalance Settlement Group (ISG) and industry participants as unreasonably high. As a result, BMRS has not tended to be considered as an implementation mechanism for new reporting requirements."," CP1217 was  raised by ELEXON on 9 November 2007, aims to achieve savings in the cost of changing and operating the BMRS by rationalising the current three delivery routes to two. CP1217 proposes to discontinue the private ‘High Grade’ BMRS website. The BMRS infrastructure would be reconfigured to provide access to the public ‘Low Grade’ website over the ‘High Grade’ network. This would allow continuing access to the BMRS website for users connected only to the High Grade network.","ISG: 83","CPC00621","ISG","−","Rejected"]
[1216,"Changes to Section 3.1 of BSCP509 to reflect a new process for the acceptance of the Profile Administrator (PrA) 'Technical Product Deliverables' (TPDs) for inclusion in the Market Domain Data (MDD).","ELEXON","2007-10-05","It was agreed at SVG 72 to set up an Expert Group to review the PrA TPDs acceptance process that is defined in BSCP509. The Group met on the 18 April 2007 to identify the defects in the current process and define a new process going forward. The Group had representation from National Grid, Centrica, Scottish and Southern Energy and E.ON UK as well as from ELEXON and the PrA. Additionally, the Group discussed contingency actions that could be implemented if the TPDs were deemed to be unsuitable for use in Settlement. The new process defined by the Group was put to the SVG in paper SVG76/07. The new process was agreed by the SVG and the SVG directed ELEXON to raise a Change Proposal to BSCP509 to reflect the new process.","CP1216 proposes to amend BSCP509, section 3.1 ‘Changes to Market Domain Data Provided by the Profile Administrator’ to reflect the new TPD review and acceptance process recommended by the Group and agreed by the SVG. ","SVG: 82","CPC00618","SVG","June 08 Release","Approve"]
[1215,"Housekeeping Changes to BSCP38 ‘Authorisations’","ELEXON","2007-09-21","As part of the implementation for the November 2007 BSC Systems Release 3 inaccuracies of low materiality have been identified in BSCP38 “Authorisations”. These inaccuracies have been created by the implementation of CP1193 “Recommended changes following an operational review of BSCP38”.","Amend BSCP38 as follows:\n\n• Section 2.2 – amend the definition of “Central Service Provider” to “A BSC Agent or BSCCo undertaking an activity requiring authorisation”;\n• Section 4 Delete “BSCCo” references (next to Authorisation Categories “ZB” and “ZC”) from the ‘Authorisation Register’ column; and\n• Form BSCP38/5.1 “CRA - Declaration of Authorised Persons” - remove Section B “Acknowledgement from CRA”.\n","ISG: 80          SVG: 80","−","ISG/SVG"," Nov 07 Release","Approve"]
[1214,"Removal of PSL130 (‘Half Hourly Data Collection’) following the creation of a generic non functional PSL via CP1182","ELEXON","2007-09-07","The Code Subsidiary Document (CSD) review highlighted a large amount of duplication between the requirements in the Party Service Lines (PSLs) and the corresponding Balancing and Settlement Code Procedures (BSCPs). A single generic PSL is being created under CP1182 ‘Creation of a generic Party Service Line’ which will contain participants’ non-functional requirements. ","Following on from CP1182, CP1214 has been raised to remove PSL130 ‘Half Hourly Data Collection’ and include the functional requirements in BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ and BSCP550 ‘Shared SVA Meter Arrangement of Half Hourly Import and Export Active Energy’. The redlined changes to BSCP502 are included as DCP0011 Attachment A and the redlined changes to BSCP550 are included as Attachment B. The removal of the duplication between PSL130 and BSCP502 and BSCP550 will mean that Half Hourly Data Collectors (HHDCs) will only have to look in the relevant BSCP to find the functional requirements relating to their role, which may be particularly useful to new entrants. This change will also reduce the cost associated with preparing and maintaining numerous and duplicated PSLs.","SVG: 81","CPC00615","SVG","Feb 08 Release","Approve"]
[1213,"Improvement to Proving Test process: Audit trail","ELEXON","2007-09-07","The Proving Test process is currently susceptible to failure/non-completion due to various generic Supplier Agent non-compliances and the current procedures used to administer and support the trading arrangement requirements. CP1213 proposes the amendment of BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ to put a requirement on the Half Hourly Meter Operator Agents (HHMOAs) and Half Hourly Data Collectors (HHDCs) to maintain an audit trail to explain a delay to the completion of a Proving Test.","CP1213 proposes to amend Section 4.6.5 of BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ and Section 8.3.5 of BSCP514 ‘SVA Meter Operations for Metering Systems Registered in SMRS’ .","SVG: 81","CPC00615","SVG","Feb 08 Release","Approve"]
[1212,"Improvements to BSCP27 identified during operational use","ELEXON","2007-09-07","There are three areas of BSCP27 in which inconsistencies or minor errors have been identified. ELEXON and the Technical Assurance Agent (TAA) do not actively pursue the rectification of ‘observation’ non-compliances, as these do no affect Settlement. It has been identified that the TAA’s and industry resources and effort are better served in other areas. In addition, it is not clear in the current drafting that BSCP27 section ‘Re-inspections’ does not apply to visits where only observations were recorded by the TAA. Participants clear paperwork non-compliances such as incorrect Meter Technical Details (MTDs) and missing certificates by the provision of the new or missing paperwork to the TAA. Thus there is no need to visit the site. BSCP27 does not state when the TAA should conduct Re-inspections. In practice, at the end of a quarter, the TAA identifies 10% of category 1 non-compliances where the participants has rectified the non-compliances during that quarter and then carries out the Re-inspections during the following quarter. BSCP27 uses the term ‘Complex Metering Systems’, which is not in line with BSCP502 and BSCP514, which uses the term ‘complex sites’.","CP1212 proposes to change the first sentence of BSCP27 section 1.11 ‘Re-Inspections’ to:\n‘Where a category 1 or 2 non-compliance has been identified by the TAA and subsequently reported by the MOA, HHDC, CDCA, or Registrant as rectified, it is possible that the Metering System will be re-inspected by the TAA to confirm compliance, if it has been altered or amended in order to achieve compliance’; bring sections 1.11 and 3.1.4 of BSCP27 in line with current working practice by adding to the end of 1.11 the words: “At the end of a quarter, the TAA selects a sample of 10% (or any other percentage as determined by the Panel) of the category 1 non-compliances that a participant has rectified during that quarter and then carries out an inspection during the following quarter of those Metering Systems that have been altered or amended in order to achieve compliance.” 3) Under 1.9.2 of BSCP27, change ‘Complex Metering System’ to ‘Complex Sites’ to bring it in line with BSCP502 and BSCP514. ","ISG: 81                SVG: 81","CPC00615","ISG/SVG","Feb 08 Release","Approve"]
[1211,"Changes to Codes of Practice 3, 5, 8 and 9 fusing requirements","ELEXON","2007-09-07","Codes of Practice 3, 5, 8 and 9 apply to Metering Systems that are predominantly Low Voltage (LV) Metering Systems. They specify the requirements for Metering System including fusing arrangements but do not specify the type of fuses to be used for LV systems where current transformer operated Meters are used. Where inappropriate fuses are used there is potential for very high levels of fault current at the Meter giving rise to potential hazards.\r\nIn the event that an electrical fault develops at the Metering System where inadequate protection is provided, persons within close proximity of the Metering System may be at risk from the very high levels of fault current.","CP1211 proposes to amend Codes of Practice (CoP) 3, 5, 8 and 9 to require BS 88 type fuses for LV current transformer operated Metering Systems. Such fuses are designed to withstand the very high levels of fault current available from the distribution systems. ","ISG: 89                      SVG: 88","CPC00615","ISG/SVG","−","Rejected"]
[1210,"Housekeeping changes to re-baseline November 2007 Release documents to reflect the P197 and P207 Releases","ELEXON","2007-08-09","It is necessary to re-baseline the relevant November 2007 Release changes onto the latest versions of the relevant documents, to ensure that no approved changes are lost when implementing the November 07 Release changes.","CP1210 proposes to re-baseline the amendments to all of the above documents required for the November 2007 Release on the most up-to-date versions of the relevant documents, as below:\n• BSCP27 version 5.0;\n• BSCP38 version 14.0;\n• BSCP509 version 14.0;\n• BSCP509 Appendix “MDD Entity Forms” version 12.0;\n• BSCP515 version 5.0;\n• BSCP537 version 2.0;\n• SVA Data Catalogue Volume 1 version 26.0;\n• SVA Data Catalogue Volume 2 version 21.0;\n• IDD Part 1 version 18.0; and\n• IDD Part 2 version 19.0 ","ISG: 79                 SVG: 79","−","ISG/SVG","Nov 07 Release","Approve"]
[1209,"Inclusion of MSID Counts on the GSP Group Consumption Totals Report","Scottish Power","2007-08-07","Supplier analysis of electricity volume consumption is presently being hampered by an inability to determine the average consumption in each of the GSP Groups, as the MSID count contributing to the volume reported is not included on the GSP Group Consumption Totals Report. CP1209 proposes to amend the D0276 ‘GSP Group Consumption Totals Report’ , which is issued to Suppliers by the Supplier Volume Allocation Agent (SVAA) to include a count of MSIDs against each Consumption Component Class. Having the ability to calculate average MSID consumptions from the GSP Group Consumption Totals will greatly improve the quality of the analysis Suppliers are able to perform.","Cp1209 amends D0276 ‘GSP Group Consumption Totals Report’ to include a count of MSIDs against each Consumption Component Class. The SVAA would need to produce this additional piece of information and include it in the report issued to Suppliers. There is no generic 'MSID Count' data item in the Data Transfer Catalogue (DTC); the various counts that are currently generated are specific to certain circumstances (e.g. 'SPM Default Unmetered MSID Count', 'Daily DA HH MSID Count') and have definitions that prevent them from being reused in the context of a D0276 flow. As a result, a new data item, e.g. 'CCC MSID Count', will need to be created for use in the flow.\nChanges will be required to the Master Registration Agreement (MRA) DTC and Data Transfer\nNetwork (DTN). The SVA Data Catalogue Volume 2 would require a change to reference the new data item and the fact that it is defined in full in the DTC. There would also be an impact on the SVAA User Requirements Specification (URS). All Suppliers making use of the D0276 would be impacted by the change. ","SVG: 82","CPC00615","SVG","June 08 Release","Approve"]
[1208,"Changes to the Change of Profile Class Process set out in BSCP516","ELEXON","2007-08-03","A number of issues with the change of Profile Class process were identified by an ELEXON Project to\ninvestigate erroneously large Estimated Annual Consumptions (EACs) and Annualised Advances\n(AAs); and by Technical Assurance checks carried out in 2006 on the change of Profile Class process. ","CP1208 seeks to make changes to the Change of Profile Class Process set out in BSCP516, following the outcomes of the CP1177 issue group.","SVG: 82","CPC00615","SVG","June 08 Release","Approve"]
[1207,"D0095 reporting in respect of past NHHDCs","ELEXON","2007-08-03","NHHDCs are appointed on a calendar basis. Therefore whichever Data Collector is appointed on the current date, is the one who has responsibility for a Metering System’s history with regards to\nAnnualised Advances (AAs) and Estimated Annual Consumptions (EACs) i.e.: the new DC assumes retrospective responsibility for data provided by previous NHHDCs within the same\nSupplier Registration. E01, E02 and E06 exceptions report missing or incomplete consumption to the Supplier. At present, the NHHDA software will send E01/E02/E06 exceptions to all NHHDCs that have been appointed at any time within the relevant Supplier registration. Change of agent activity can therefore lead to high numbers of duplicate exceptions being generated. ","CP1207 proposes that the NHHDA CDCD functionality, which generates the D0095 exception report for Suppliers, be modified such that E01, E02 and E06 exceptions are not reported to Suppliers where they relate to past appointed Data Collectors. This will mean that E01, E02 and E06 exceptions will only be reported for current NHHDCs with the same Supplier Registration as the exception.","SVG: 85","CPC00610","SVG","Feb 09 Release","Approve"]
[1206,"D0095 reporting of immaterial Supplier inconsistencies","ELEXON","2007-08-03","The Non Half Hourly Data Aggregation Exception Report (D0095) provides Suppliers with detail of anomalies in the data provided to NHHDAs by NHHDCs and the SMRA. The E08 and E014 exceptions report an inconsistent Supplier. They are generated when the Supplier Meter Registration System (SMRS) and NHHDC view of the Supplier, reported to the NHHDA are different. The E14 exception is reported to the Supplier according to the NHHDC. The E08 exception is reported to the Supplier according to the SMRS. The Market is experiencing large numbers of E14 exceptions, most of which are believed to be immaterial. The volume of immaterial E14 exceptions inhibits Suppliers from addressing the material ones. ","CP1206 proposes to change the functionality of the CDCD to ensure that E14 exceptions are not reported if the exception occurs for the first EAC received from NHHDC upon Change of Supplier. This will suppress the resulting immaterial exceptions, and have the effect that only repeated Supplier inconsistencies are reported","SVG: 85","CPC00610","SVG","Feb 09 Release","Approve"]
[1205,"D0095 reporting of immaterial superfluous consumption","ELEXON","2007-08-03","The Non Half Hourly Data Aggregation Exception Report (D0095) provides Suppliers with detail of anomalies in the data provided to Non Half Hourly Data Aggregators (NHHDAs) by Non Half Hourly Data Collectors (NHHDCs) and the Supplier Meter Registration Agent (SMRA). The E03 and E04 exceptions report superfluous consumption. They are reported when the NHHDA receives an Annualised Advance (AA) (E03) or an Estimate Annual Consumption (EAC) (E04) respectively, for a period for which it is not appointed. These exceptions are reported to the Supplier that is appointed to the Metering System as recorded by the NHHDC. In the 2007 BSC Auditor’s Report, it was reported that the volume of D0095 exceptions at RF as at 31 March 2007 was 4,092,060. 7,016 of these were E03 exceptions and 1,514,997 were E04 exceptions. Most of the E03 and E04 exceptions are likely to be immaterial.","CP1205 proposes to change the functionality of the NHHDA Check Data Collector Data (CDCD) to ensure E03 and E04 exceptions are not reported 1 day either side of the NHHDA appointment. This will eliminate the immaterial exceptions that result from the change of NHHDA. The effect is that only repeated instances of E03 and E04 exceptions are reported.","SVG: 85","CPC00610","SVG","Feb 09 Release","Approve"]
[1204,"New charging code structure for Unmetered Supplies","ELEXON","2007-07-06","The Supplier Volume Allocation Group (SVG) requested that ELEXON investigate potential amendments to the current Unmetered Supply arrangements, so as to recognise newly developing control technologies (known as Central Management Systems (CMS). As part of this work, an external review group was set up which considered a number of solutions. Three options were developed  and have been issued to the Industry for discussion.","CP1204 proposes extending the charging code structure to 13 digits, and involves changes to BSCP520. The proposed extension of the Charging code structure will increase accuracy as the present code may lead to inaccuracies in Settlement because it cannot accurately reflect the operation of new, more dynamic apparatus.","SVG: 79","CPC00609","SVG","June 08 release","Approve"]
[1203,"Replacement of the ‘Accuracy Requirements’ Tables in the Compliance Testing Appendix to BSCP601","ELEXON","2007-06-06","BSCP601 ‘Metering Protocol Approval and Compliance Testing’ sets out the process by which Meter Manufacturers, Meter Operator Agents, Suppliers, Half Hourly Data Collectors (HHDCs) and Half Hourly Meter Equipment users can apply for Compliance Testing and Protocol Approval of Half Hourly metering Equipment.   The appendix to BSCP601 entitle ‘Specification Compliance Testing of Metering Equipment Codes of Practice One, Two, Three and Five’ sets out the tests that a Compliance Testing Agent must perform on an item of Metering Equipment in order to determine whether the accuracy and functionality of that item of Metering Equipment conforms or otherwise to the requirements set out in a particular Code of Practice (CoP).  \n","CP1203 proposes the replacement of the ‘Accuracy Requirements’ tables in the appendix to BSCP601, as they currently specify inappropriate limits of error for compliance testing of Metering Equipment. This change will remove any potential confusion in the accuracy requirements for compliance testing going forward.","ISG: 79                      SVG: 79","CPC00609","ISG/SVG","Feb 08 Release","Approve"]
[1202,"Changes to Meter Protocol Test Specification","ELEXON","2007-07-06","It was brought to the attention of the ISG that the ‘specification for the Approval and Testing of Metering Equipment Protocol Testing’ document (an appendix to BSCP601 ‘Metering Protocol Approval and Compliance Testing’) does not contain any detailed requirements. The ISG requested that ELEXON assess the document and report its findings. Applicants to the BSCP601 processes have no indication of the requirements for protocol approval. ","CP1202 Attachment A details the redlined solution which includes the addition of a sample test schedule and the addition of an explanation of protocol. Further changes have been made to address areas of duplication and redundancy where the Appendix currently deals with issues relating to compliance testing.","ISG: 79                      SVG: 79","CPC00609","ISG/SVG","Feb 08 Release","Approve"]
[1201,"Changes proposed following Operational Review of BSCP15 ‘BM Unit Registration’ and BSCP20 ‘Registration of Metering Systems For Central Volume Allocation’","ELEXON","2007-05-17","At the ISG meeting on 28 November 2006, the ISG agreed that an operational review of BSCP15 and BSCP20 should be carried out (ISG70/07). The review aimed to identify change that could be made to improve operability and eliminate complexity of the processes set out in BSCP15 and BSCP20 and to draft and recommend changes to give effect to any potential changes identified. The walkthroughs of BSCP15 and BSCP 20 occurred in January 2007. ","CP1201 proposes amendments to BSCP15 and BSCP20, following the review which should improve the operability and eliminate complexity in the processes set out in the BSCPs. ","ISG: 81                      SVG: 81","CPC00610","ISG/SVG","Feb 08 Release","Approve"]
[1200,"Removal of requirement for Proving Test Out of Timescale Escalation Report","Scottish and Southern Energy","2007-05-04","BSCP502, ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’, Section 4. 6. 4, ‘Reporting’, states that ‘If the Half Hourly Data Collector (HHDC) receives the Meter Technical Details (MTD), via receipt of the D0268 Half Hourly Meter Technical Details and knows that a proving test should have been performed based on the circumstances defined in Section 4. 6. , but no successful proving test has been initiated by the Meter Operation Agent (MOA) within the timescales in Section 4. 6. 5, the HHDC shall report this to the MOA, the Supplier and BSCCo. ‘ This is accomplished using the P0212 ‘Notification of Failure to Carry Out Proving Test’ flow. This obligation was incorporated to facilitate Supplementary Monitoring carried out by ELEXON when BSCP514 was produced (via CP854 ‘Provision of a new Balancing and Settlement Code Procedure (BSCP) covering Meter Operator Agent processes for Supplier Volume Allocation (SVA) Metering Systems’). At that time there were issues surrounding MOAs initiating proving tests. CP1200 proposes to remove the requirement in BSCP502 and BSCP514 to send a P0212 data flow if no proving test has been initiated and to remove the P0212 from SVA Data Catalogue Volume 1.","The CP involves removing the requirement to send the flow from BSCP502 and BSCP514, along with removing the P0212 flow from the SVA Data Catalogue Volume 1. ","SVG: 77","CPC00604","SVG","Nov 07 Release","Approve"]
[1199,"Changes to BSCP515 ‘Licensed Distribution’ to remove non functional information and add clarity","ELEXON","2007-05-04","acceded to the Code, completed Entry Process testing and become operational in the market. LDSOs have to use BSCP515 to carry out some of the activities required of them to become operational in the market. BSCP515 also contains requirements that relate to LDSOs ongoing activities. LDSO’s have provided feedback to ELEXON in respect of BSCP515, in that they have expressed concern about the accuracy, sequencing, complexity and inconsistent terminology within BSCP515. As a result of the concerns, ELEXON produced a guidance note in April 2006 providing details relating to market entry and the Code requirements to consider when setting up a new LDSO business.","CP1199 proposes that BSCP515 is updated to remove unnecessary sections which simply reference processes set out in other BSCPs and that the remaining sections are clarified where necessary.","SVG: 79","CPC00609","SVG","Feb 08 Release","Approve"]
[1198,"Changes to BSCP14 ‘Processing of Manifest Error Claims’ to comply with the BSC.","ELEXON","2007-05-04","BSCP14 is unclear on the number of Manifest Errors that must be claimed for a sequence of BOAs, and does not adequately define the processing of a Manifest Error claim raised by a Lead Party  or Transmission Company.  ","CP1198 proposes changes to BSCP14 which would ensure that the BSCP has a better definition of a “Manifest Error” as it is written in the Code, thereby preventing any misinterpretation of the range of items to be included in a Manifest Error.","TDC: 104","CPC00607","TDC","Feb 08 Release","Approve"]
[1197,"Clarification of Grid Supply Point (GSP) and GSP Group Aggregation Rules","ELEXON","2007-05-04","ELEXON believes that raising a CP to provide further clarification and an additional worked example within BSCP75 will remove any existing ambiguity and increase the transparency of the aggregation process.","Cp1197 aims to correct a small number of identified 'housekeeping’ errors within the BSCP will promote efficiency.","ISG: 77","CPC00604","ISG","Nov 07 Release","Approve"]
[1196,"Changes to incorporate Central Management Systems in Unmetered Supplies arrangements","ELEXON","2007-05-04","Various manufacturers have developed new technologies which allow certain forms of equipment categorised as UMS in the BSC Arrangements to be controlled in a more dynamic way.   These technologies, known as CMS, provide customers with greater control over the operation of the supply, allowing both the equipment’s switching times and power loads to be controlled down to each half hour period. This level of control offers the potential for customers to make significant energy savings, helping to meet increasingly tight regulations on energy consumption and carbon emissions. \n\n","CP1196 proposes a number of changes that would need to be made incorporated CMS in the UMS arrangements. The changes have been proposed by the CMS Review Group, which was established by Supplier Volume Allocation Group (SVG).","SVG: 78","CPC00604","SVG","Feb 08 Release","Approve"]
[1195,"Amendments to BSCP27 ‘Technical Assurance of Half Hourly Metering Systems for Settlement Purposes’ and BSCP38 ‘Authorisations’ with regard to Category I Authorised Signatories","ELEXON","2007-05-04","There is a requirement for the CVA Registrant's Authorised Signatory (category I) to sign the notification form to the TAA & MOA confirming acceptance of an impending inspection visit (BSCP27/3.5.3). There is no step within BSCP38 for the CRA or ELEXON to provide this data to the TAA, so the TAA is unaware of whom the Authorised Signatories are and therefore is unable to check. However, as a representative of the MOA would always accompany the TAA on site there is no risk to Settlement with regard to trading and registration activities. ","As there is no risk to Settlement, CP1195 proposes to remove category I from BSCP38; and references to an Authorised Signatory from BSCP27.","ISG: 77                            SVG: 77","CPC00604","ISG/SVG","Nov 07 Release","Approve"]
[1194,"Publication of Authorised Person’s data on the BSC website.","ELEXON","2007-05-04","BSCP38 ‘Authorisations’ defines the processes under which Authorised Persons are registered and how these records are amended. The procedure is to ensure that the Balancing and Settlement Code (BSC) Agents and the Balancing and Settlement Company (BSCCo) carry out specific Code activities only at the behest of an Authorised Person. BSCCo noted a concern raised by the Supplier Volume Allocation Group (SVG) and BSC Parties that it was often very difficult for them to perform required Code activities in a timely manner when they were not aware of who within their organisations was authorised to do so. It is proposed that Party and Party Agents wishing to publish its Authorised Persons list on the BSC website can do so, provided they give formal authorisation to ELEXON expressing their consent that ELEXON can disclose such personal data regarding it and its employees to third parties. Formal authorisation would need to be submitted in writing by a Category A Authorised Person to the ELEXON Helpdesk, clearly stating the relevant Party/ Party Agent ID(s) to which the Authorised Persons relate to. ","CP1194 seeks to grant BSC Parties easy access to their companies list of Authorised Persons, enabling them to carry out obligated activities under the Code more efficiently.\nThe changes documented in this Change Proposal will allow BSCCo to publish the details of those Authorised Persons as requested. This would mean that BSC Parties are better equipped to correctly authorise BSCP forms that are sent to BSCCo and BSC Agents in a timely fashion as it will be easier to identify the person required to authorise the form.","ISG: 77                            SVG: 77","CPC00604","ISG/SVG","Nov 07 Release","Approve"]
[1193,"Recommended changes following an operational review of BSCP38 – ‘Authorisations’","ELEXON","2007-05-04","Following concerns from the CRA and BSC Parties undertaking the Authorisation Process, a number of changes of BSCP38 'Authorisations' is requested.","CP1193 proposes various changes following an operational review of BSCP38.","ISG: 77                            SVG: 77","CPC00604","ISG/SVG","Nov 07 Release","Approve"]
[1192,"Changes to the Investigate Inconsistencies processes in BSCP502 and BSCP514 (Half Hourly only)","Npower","2007-05-04","BSCP502 ‘Half Hourly Data Collection For SVA Metering Systems Registered in SMRS’ and BSCP514 ‘SVA Meter Operations For Metering Systems Registered in SMRS’ contains variations on the process for investigating inconsistencies and performing Metering System investigations. The BSC Auditor highlighted this issue during the October 2003 to September 2004 audit period. The processes set out in the BSCPs are inconsistent with each other, with the Serials set out in PSL110 ‘Party Service Line for Meter Operator Agents’ (MOAs) and with current practice. This does not aid the timely resolution of Metering System investigations and faults. The relevant sections in the BSCPs do not make the distinction between investigating inconsistencies in data and performing Metering System investigations and the differences or relationship between the two. These processes should have a consistent approach in the MOA and Data Collector (DC) documents.  ","CP1192 proposes that changes should be made to BSCP502, BSCP514 and the SVA Data Catalogue to ensure that BSCP502 and BSCP514 are consistent in the area of investigating inconsistencies and in particular where this leads to a Metering System Investigation to reflect agreed current practice.","SVG: 81","CPC00607/CPC00615","SVG","June 08 Release","Approve"]
[1191,"Amendment of SVAA Service Line SSL330 to bring it in line with current contract arrangements.","Central Change Coordination","2007-05-04","Changes to the SVAA contract arrangements have created a misalignment between the contract arrangements and the SVAA Service Line SSL330. This has necessitated amendments to SSL330 to bring it in line with the existing contract arrangements. The main areas of misalignment include the ad-hoc reporting service and the acceptance testing service requirements.","CP1191 proposes that the SVAA Service Line SSL330 is updated.","SVG: 77","CPC00604 ","SVG","2007-08-01","Approve"]
[1190,"Recommended Changes following an Operational Review of MDD Processes","Central Change Coordination","2007-05-04","Currently, Market Domain Data (MDD) Change Requests submitted to ELEXON (in accordance with BSCP509 ‘Market Domain Data’) are handled through a resource-intensive and error-prone manual process. This results in unnecessary difficulty and expense for both the parties raising change requests, and for ELEXON. In particular, there were several issues arising from version 116 of the MDD release as described in paper SVG61/004. At the Supplier Volume Allocation Group (SVG) meeting on 02 May 2006, the SVG agreed that an operational review of the Market Domain Data Process should be carried out (Paper SVG63/08). The approach included feedback from a group of industry experts and also from a discussion session at the SVA Forum held on 18 July 2006. The review indicated that a number of changes to BSCP509 are desirable to ensure that the requirements are streamlined, and that all of the forms set out in BSCP509 are efficient and consistent with the information in the MDD database. \n\n","CP1190 highlights the supported changes which have been discussed by the SVG at its meeting on 31 October 2006 (SVG69/02).","SVG: 77","CPC00604 ","SVG","Nov 07 Release","Approve"]
[1189,"Change to allow SVA Line Loss Factors less than one","United Utilities","2007-05-04","BSC Objectives (Condition C3 (3) of the Transmission Licence), particularly Objective c) state “promoting effective competition in the generation and supply of electricity, and (so far as consistent therewith) promoting such competition in the sale and purchase of electricity”. At present, such competition is being adversely affected by an inability to accurately allocate losses to users. The present situation does not allow an accurate representation of the effect users have on network losses.  ","CP1189 would allow a more correct treatment of how additional generation, in particular, would affect network losses and would offer a fairer and more transparent allocation of losses to all users. The proposed amendment would promote effective competition through the accurate interpretation of factors that drive costs; in this case network losses. ","SVG: 77","CPC00604 ","SVG","Nov 07 Release","Approve"]
[1188,"Improvements to the use of the Half Hourly Aggregation Exception Report (D0235)","Npower","2007-03-02","Currently if a SVA metering system is de-energised a Half Hourly Aggregation Exception Report (D0235) is generated if non-zero consumption value is provided to the Half Hourly Data Aggregator (HHDA) by the Half Hourly Data Collector (HHDC). If the Metering System is de-energised by the Half Hourly Meter Operator (HHMOA) at a time later than 00: 00 hrs it is likely that a non-zero value will be recorded by the HHDC on the effective from date of the de-Energisation.   This will cause an exception report (D0235) that the Supplier will never be able to resolve. \n\n","CP1188 proposes that non-zero values recorded on the effective from date of an Energisation status change, from energised to de-energised, should not be reported as an anomaly to the HHDC and Supplier.","SVG: 75     Panel: 127","CPC00600","SVG","Nov 07 Release","Approve"]
[1187,"UNIX Upgrades for NHHDA and EAC/AA","ELEXON","2007-02-02","After discussion by the STAG on 25 January 2007 and an email survey the options are: HPUX, Sun Solaris and IBM AIX. There is Market Participant support for all three of these options to varying degrees and therefore ELEXON requires cost estimates for each individual option to help inform which option will be the final proposed solution. Market participants are requested to provide costs associated with each option to allow the SVG to make an informed decision.","CP1187 proposes a number of potential solutions for the operating system(s) that will replace Tru64 Unix 5.1b as the supporting platform for NHHDA and EAC/AA.","SVG: 75     Panel: 127","CPC00596","SVG/ Panel","Feb 08 Release","Approve"]
[1186,"Changes to the Profile Administrator (PrA) Service Description","Central Change Coordination","2006-12-08","The Profile Administrator Service Improvement Project has a number of objectives which included the updating of the field assets that were in the load research sample premises. This led to Issue 21 which was discussed by the VASMG and the findings were presented and accepted by the Panel. One of the recommendations was that the field assets be replaced by a ‘smart’ metering solution. The new metering solution has been defined and the contract changes signed off with the new equipment being installed in sample customer’s premises. However the PrA Service Description still retains information on both historic data collection and Service Levels relating to that solution. ","CP1186 proposes to update the PrA Service Description to accurately reflect the new metering solution and the new Service Levels that have been agreed and signed off in the PrA Contract.","SVG: 72","CPC00594","SVG","June 07 Release","Approve"]
[1185,"Allowing a Reading to be Deemed where an Actual Reading is Unavailable on a Change of Standard Settlement Configuration","ELEXON","2006-12-08","Modification P176 was raised to change the permissible circumstances where a reading may be deemed and so to rectify the issue.  This Modification introduced into BSCP504 ‘Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ a number of circumstances where deeming is allowable. One circumstance which is not explicitly stated as an allowable deeming circumstance is change of Standard Settlement Configuration (SSC). BSCP504 3.3.7 ‘Reconfigure or Replace SVA Metering System – No Change of Measurement Class’ allows a reading to be deemed in the event that a valid actual reading is unobtainable. BSCP504 3.3.6 ‘Change of Standard Settlement Configuration’ does not include the steps for deeming a Meter reading where a valid actual Meter reading is unavailable. A change of SSC cannot normally be effected without reconfiguring the Metering System (e.g. changing the clock or reconfiguring the registers) or replacing the Meter, and so in reality, section 3.3.6 and 3.3.7 are often both completed where a change of SSC occurs.  ","CP1185 seeks to allow Non Half Hourly Data Collector (NHHDC) to deem a reading following a change of SSC would resolve the audit issue concerning deemed reads being calculated in circumstances other than those specified in the BSC; and is entirely consistent with the circumstances in which deeming is already permitted.","SVG: 75     Panel: 127","CPC00594/CPC00596","SVG","−","Rejected"]
[1184,"Disconnection of Energised Metering Systems","Western Power Distribution","2006-12-08","BSCP515 sets out the process to follow in the event of a disconnection. It requires that before a metering system can be disconnected it must be de-energised. This requirement can be complied with in most cases, but sometimes the LDSO is required to disconnect at short notice, and it is the priority of the LDSO to make the supply safe and is unable to follow the de-energisation process. Currently BSCP515 does not recognise cases where supply needs to be disconnected at short notice resulting in LDSOs failing the BSC audit.","CP1184 proposes to amend BSCP515 to permit LDSOs to disconnect a supply that is in an energised state. This will be done with liaison with the Meter Operator Agent (MOA), either before or after disconnection, so that final readings and removal of the meter can be communicated. Hence when the LDSO disconnects in short notice situations it will not be an audit failure.","SVG: 74","CPC00594","SVG","Nov 07 Release","Approve"]
[1183,"Allowing a date to be deemed for a change in Energisation Status of a Half Hourly Meter","ELEXON","2006-12-08","When a Supplier becomes aware, via the Half Hourly Data Collector (HHDC) or its own data, that the Energisation Status of a Metering System (MS) is incorrect, a request is usually made to the Half Hourly Meter Operator Agent (HHMOA) to send a revised D0139 ‘Confirmation or Rejection of\nEnergisation Status Change’ flow. However, in some cases the HHMOA is unable to give the date of the Energisation Status change (e.g. because the MS was energised/de-energised by the LDSO and the data is unavailable). Without a date for energisation/de-energisation the status of the MS cannot be updated, meaning the information on the Supplier’s system and consequently BSC systems is inaccurate","CP1183 proposes the addition of a footnote to BSCP514 ‘SVA Meter Operations for Metering Systems registered in SMRS’ to state that when an Energisation Status of a MS is incorrect but the date of the Energisation Status Change is unknown the HHMOA can send a Confirmation or Rejection of Energisation Status Change (D0139) flow to the Supplier with a deemed date for Energisation/de-Energisation. This then must then be instructed or agreed by the Supplier","SVG: 74","CPC00596","SVG","Nov 07 Release","Approve"]
[1182,"Creation of a generic Party Service Line","ELEXON","2006-12-08","The Code Subsidiary Document (CSD) review has highlighted that there is a large amount of duplication between the requirements contained in Party Service Lines (PSLs) and the corresponding Balancing and Settlement Code Procedures (BSCPs). ","CP1182 proposes the creation of a generic PSL that will contain participant’s non-functional requirements, which are currently set out in the current PSLs. This will result in Parties and Party Agents only needing to look at one document to find the requirements for a particular aspect of their role.","SVG: 77","CPC00594","SVG","Nov 07 Release","Approve"]
[1181,"Removal of duplication between the SVA Data Catalogue and the DTC","ELEXON","2006-11-14","During a consultation as part of the CSD review, industry participants were asked as to whether unnecessary duplication between the DTC and SVA Data Catalogue should be removed. The majority of respondents agreed that unnecessary duplication should be removed along with some stating they do not look at the SVA Data Catalogue. The Panel also agreed that unnecessary duplication between the SVA Data Catalogue and DTC should be removed. ","CP1181 seeks to remove duplication between the SVA Data Catalogue and the DTC. The proposed solution does not involve deleting the whole of the SVA Data Catalogue. Instead where there is duplication between the SVA Data Catalogue Volume 1 and the DTC, it should be removed and replaced with a cross reference in the DTC. If a duplicated item is deleted from the SVA Data Catalogue Volume 1, it should also be deleted from the SVA Data Catalogue Volume 2 and crossed reference with the relevant item in the DTC.","SVG: 72","CPC00594","SVG","June 07 Release","Approve"]
[1180,"Confirmation of Metering status in the Non Half Hourly Market","ELEXON","2006-10-16","Once Meters have been removed the D0150 flow is not always sent to Suppliers/Agents during CoS/CoA scenarios while there are no Meters on site. This can lead to Suppliers/Agents not getting confirmation of the situation at a site and as consequence SMRS may not be updated with the latest data. ","CP1180 proposes changes to BSCP514 to ensure that up to date information regarding Metering and feeder statuses are delivered to Suppliers.","SVG: 77","CPC593/CPC00603","SVG","Feb 08 Release","Approve"]
[1179,"Instigation of a 'nil' P0028 100kW Demand Report","ELEXON","2006-09-15","BSCP504 3.4.1.8 states that each month when 100kW demand is identified by a Non Half Hourly Data Collector (NHHDC) they must produce and send to the Panel and Supplier a report detailing the occurrence. They do this by sending a P0028 ‘100kW Demand Report’ flow. Currently a number of Suppliers assume that if they do not receive a 100kW demand report, the NHHDCs have not identified any items for the Suppliers to follow up. This could potentially lead to the situation where a report has gone missing in transit and the Supplier assumed that no report has been sent. Hence, 100kW demand may not be identified by the Supplier. ","CP1179 seeks to place a requirement on NHHDCs to send a 100kW Demand Report to Suppliers every month, and where no instances of a 100kW or greater demand occur a ‘nil’ report will be sent. This will prevent the loss of P0028 Demand Reports as the Supplier will expect a report every month, and will be able to contact the NHHDC if a report is not received.","SVG: 70","CPC00590","SVG","June 07 Release","Approve"]
[1178,"Change to SP08 validation rules in PARMS","ELEXON","2006-09-15","Serial SP08 monitors the amount of energy settled using actual data (AAs) as opposed to estimates (EACs) and compares Suppliers’ performance with standards set out in the Code.  The performance data for SP08 is provided by the SVAA via a P0145 flow generated by the Pool Application, which details the percentage of total energy settled on AAs.  PARMS carries out validation checks on all performance data it receives, and in the case of SP08 it rejects files that contain percentage values greater than 100. The issue is that on occasion the percentage of AAs can become greater than 100% due to the inclusion of negative EACs.  The rules for calculating SP08 performance data are set out in Annex S-1 of the Code and make no particular allowance for the impact of negative EACs.  \n","CP1178 proposes the modification of the SP08 values for certain SP08 data to allow percentages greater than 100% to ensure the successful entering of the correct data into PARMS.","SVG: 70","CPC00590","SVG","June 07 Release","Approve"]
[1177,"Changes to the change of Profile Class process as set out in BSCP516 'Allocation of Profile Classes and SSCs for Non-Half Hourly SVA Metering Registered in SMRS'","ELEXON","2006-09-15","A number of issues with the change of Profile Class process have been identified by the ELEXON\nProject to investigate erroneously large Estimated Annual Consumptions (EACs) and Annualised\nAdvances (AAs); and by Technical Assurance checks carried out in 2006 on the change of Profile\nClass process. ","CP1177 proposes changes to BSCP516 in order to address problems of timing, clarity, and incentivisation around the Change of Profile Class Process.","SVG: 72","CPC00593","SVG","−","Rejected"]
[1176,"Additions to the February 2007 Release Housekeeping changes - removal of workflow diagrams from BSCPs ","ELEXON","2006-08-25","At its meeting on the 8 June 2006 (115/08) the BSC Panel agreed to the principles of the new Code\nSubsidiary Document (CSD) architecture. Part of the proposed changes included the removal of all\nworkflow diagrams from Balancing and Settlement Code Procedures (BSCPs). It was agreed that the removal of the diagrams would take place on an ongoing opportune basis rather than as one single piece of work. ","CP1176 proposes to remove workflow diagrams from BSCPs which are already impacted by CPs in the February 2007 Release.","SVG: 67","−","SVG","Feb 07 Release","Approve"]
[1175,"Revision of BSCP 601 - Appendix 'Specification Compliance Testing Codes of Practice One, Two, Three and Five'","ELEXON","2006-08-24","Specified Compliance Testing should remains consistent with the relevant CoPs and that Metering Protocol Approval and Compliance Testing is conducted against an appropriate baseline.","CP1175 proposes changes to BSCP601 – Appendix ‘Specification Compliance Testing of Metering Equipment: Codes of Practice One, Two, Three and Five’.","ISG: 68               SVG: 67","CPC00586","ISG/SVG","Feb 07 Release","Approve"]
[1174,"Changes to BSCP601 and Compliance Test Specification","ELEXON","2006-08-04","Following a review of BSCP601 ‘Metering Protocol Approval and Compliance Testing’ and the processes surrounding it. ELEXON identified four areas surrounding Metering protocol and compliance testing for amendment. \n","CP1174 was updated to version 2. 0 to address the comments raised by respondents to CPC00583 and provide further clarity on the proposed change. ","ISG: 72                SVG: 72","CPC00583/CPC00593","ISG/SVG","June 07 Release","Approve"]
[1173,"Proving Test Out of Timescale Escalation Report","ELEXON","2006-07-04","The requirement to report to BSCCo regarding this is also included in BSCP502 step 3.5.6.1 and in BSCP514, ‘SVA Meter Operations for Metering Systems Registered in SMRS’, step 5.5.6.1 and section 8.3.4, ‘Reporting’. This obligation was incorporated to facilitate Supplementary Monitoring carried out by ELEXON when BSCP514 was produced (via CP854 ‘Provision of a new Balancing and Settlement Code Procedure (BSCP) covering Meter Operator Agent processes for Supplier Volume Allocation (SVA) Metering Systems’). At that time there were issues surrounding MOAs initiating proving tests. Although this issue is not completely resolved, it has now improved to a sufficient degree that BSCCo does not need to monitor the process, so no longer require notification from the HHDC that a proving test has not been initiated.","CP1173 proposes to remove the BSCCo  as a recipient of P0212 data flow, as the processes of carrying out proving tests and monitoring testing have improved to a sufficient extent that BSCCo no longer needs to be involved in the monitoring procedure.","SVG: 70","CPC00590","SVG","June 07 Release","Approve"]
[1172,"Housekeeping CP for the February 2007 BSC Systems Release","ELEXON","2006-06-26","Testing with the test results and any additional observations being provided by the CTA to help inform its Panel’s decision. However, legal advice has indicated that the Panel approval steps currently described in BSCP601 instead relate only to the issuing of compliance certificates by ELEXON following the successful test of Metering Equipment. ","CP1172 details housekeeping changes that will improve clarity and ensure the documents are fully reflective of current operational processes.","SVG: 66","−","SVG","Feb 07 Release","Approve"]
[1171,"Improvements to the Proving Process","ELEXON","2006-06-20","The current Proving process is mapped out in BSCP 514 (MOA) and BSCP 502 (HHDC) code subsidiary documents. The responsibility to ensure that proving is carried out in the correct timescales is shared between the MOA and HHDC agent functions. HH agents have identified issues with the current process that have lead to the failure of parties to successfully complete the Proving Test requirements listed in the code subsidiary documents.","CP1171 aims to ensure the integrity of settlements by improving the proving process between MOA and HHDC.","SVG: 69","CPC00579","SVG","−","Rejected"]
[1170,"Improving the BSC Change Process ","Npower","2006-06-20","SVA Suppliers and their Agents have expressed concerns that the BSC Change Process does not adequately meet their needs. ","CP1170 proposes that BSCP40 is amended to introduce a number of improvements into the Change Process.","SVG: 69","CPC00583","SVG","Feb 07 Release","Approve"]
[1169,"Within Day Dis-application of Energy Contract Volume Notifications","ELEXON","2006-05-26","The BSC Panel has the ability to dis-apply Energy Contract Volume Notifications (ECVNs) in relation to Parties which are in Default. Currently ECVNs can only be removed from Settlement Period One.","CP1169 proposes the introduction of a defined process to dis-apply ECVNs from any Settlement Period.","ISG: 66","CPC00575","ISG","Feb 07 Release","Approve"]
[1168,"Deemed Readings following Change of Measurement Class","ELEXON","2006-05-25","The requirement to report to BSCCo regarding this is also included in BSCP502 step 3.5.6.1 and in\nBSCP514, ‘SVA Meter Operations for Metering Systems Registered in SMRS’, step 5.5.6.1 and\nsection 8.3.4, ‘Reporting’. This obligation was incorporated to facilitate Supplementary Monitoring carried out by ELEXON when BSCP514 was produced (via CP854 ‘Provision of a new Balancing and Settlement Code Procedure (BSCP) covering Meter Operator Agent processes for Supplier Volume Allocation (SVA) Metering Systems’). At that time there were issues surrounding MOAs initiating proving tests. Although this issue is not completely resolved, it has now improved to a sufficient degree that BSCCo does not need to monitor the process, so no longer require notification from the HHDC that a proving test has not been initiated.\n","CP1168 proposes remove the need to send the D0010 flow in relation to deemed Meter readings following a change of measurement class.","SVG: 66","CPC00575","SVG","Feb 07 Release","Approve"]
[1167,"Clarification of Section 1.2 of SVA SSL310 ‘Daily Profile Production’","ELEXON","2006-05-25","The weather stations are selected by the Meteorological Office using two criteria:\n1) That the weather station is located within the GSP Group that it is supplying data for; and\n2) That the weather station is located close to the population centre of the GSP Group that it is\nsupplying data for.\nIn some instances however, there is no appropriate weather station that meets both of the criteria above and it is necessary to locate the weather station outside of the GSP Group that it is supplying data for. ","CP1167 proposes a change to the SSL310 to make it consistent with the Code and current practice, in regard to approval of a backup weather station outside a GSP Group being sought.","SVG: 66","CPC00575","SVG","Feb 07 Release","Approve"]
[1166,"Changes to allow use of inbound communications for CoP5 Metering","ELEXON","2006-05-17","Most of the current communications technology for the HH market is based on meter data being collected by a central system using an ‘outbound’ approach. As a result, many of the relevant equipment definitions and process descriptions in the CoPs and BSCPs are directly associated with a meter interrogation activity, when in fact the key requirements are for the robust storage and transfer of data. ","CP1166 proposes to allow use of inbound communications for CoP5 metering.","SVG: 80","CPC00575/CPC00603/CPC00607","SVG","Feb 08 Release","Approve"]
[1165,"Removal of the Requirement to Report Valid Excessive AA’s to Suppliers on a Daily Basis","ELEXON","2006-05-16","BSCP504 states that within 1 working day of determining whether an excessively large AA is valid, notification should be sent to the relevant Supplier. ","CP1165 proposes that the current requirement should be replaced with an obligation to provide a monthly report of all excessively large AA’s to the Supplier.","SVG: 66","CPC00575","SVG","Feb 07 Release","Approve"]
[1164,"Improvements to BSCP27 identified during operational use with respect to Meter Technical Details and other supplementary information.","ELEXON","2006-04-10","A number of issues relating to Meter Technical Details (MTDs) have been identified during the\noperational use of BSCP27 ‘Technical Assurance of Half Hourly Metering Systems for Settlement\nPurposes’. These issues have been identified by market participants, the Association of Meter\nOperators (AMO), the Technical Assurance Agent (TAA) and ELEXON. \n","CP1164 proposes changes to BSCP27 ‘which have been identified during operational use. The issues which CP1164 addresses are related to Meter Technical Details.\n","ISG: 69","CPC00575","ISG","Feb 07 Release","Approve"]
[1163,"Requesting Meter Technical Details during a change of Meter Operator Agent","ELEXON","2006-04-10","Within BSCP514, with change of MOA, but no change of Supplier, the Supplier instructs the old MOA to send the MTDs to the new MOA.  However, with concurrent change of Supplier and MOA, it is up to the new MOA to request the MTDs from the old MOA. ","CP1163 proposes making the process the same in both cases.  (e.g. put the responsibility on the new MOA to request the MTDs every time).","SVG: 66","CPC00570","SVG","−","Rejected"]
[1162,"Sending revised Meter Technical Details during a change of Meter Operator Agent","ELEXON","2006-04-10","During a change of MOA, the old MOA does not inform the new MOA of any changes to metering details. ","CP1162 proposes that, in addition to sending revised Meter Technical Details (MTDs) to the Supplier, DC and Distributor, the old MOA should send any revised MTDs to the new MOA, until such time he is no longer responsible for them.","SVG: 66","CPC00570","SVG","June 07 Release","Approve"]
[1161,"Housekeeping changes to the Communication Requirements Document ","ELEXON","2006-03-27","The Communication Requirements Document (CRD) (v11.0, issued on 02 November 2005) makes a number of references to ‘PCSec’, a security utility originally used in the transmission of data between Parties and Central Systems. PCSec has now been replaced by XSec, which performs basically the same function but is an improved piece of software. The CRD therefore needs updating to reflect these changes. Upon examining the CRD, a few typographical errors have also been spotted. There is a rogue ‘then’ instead of ‘them’ in the last line of the third paragraph of 4.2.1 and a rogue apostrophe in the second line of 4.12. Section 4.14 should be amended to reflect the fact that Windows NT is no longer supported.\n","CP1161 details housekeeping changes to the Communication Requirements Document.","ISG: 66                    SVG: 66","CPC00575","ISG/SVG","Feb 07 Release","Approve"]
[1160,"Recommended changes following an operational review of the CVA Qualification requirements","ELEXON","2006-03-27","The CVA Qualification testing process applies to Parties and CVA Party Agents. Testing involves sending data to, or receiving data from the NETA Central Systems Agent. ELEXON noted concern from participants undertaking the CVA Qualification processes","CP1160 proposes recommended changes to result in a more streamlined and transparent CVA Qualification process which respond to issues raised by new participants undertaking the process.","ISG: 66                    SVG: 66","CPC00575","ISG/SVG","Feb 07 Release","Approve"]
[1159,"Confirmation of Metering status in the Half Hourly Market","ELEXON","2006-02-03","Once Meters have been removed the D0268 flow is not always sent to Suppliers/Agents during CoS/CoA scenarios while there are no Meters on site. This can lead to Suppliers/Agents not getting confirmation of the situation at a site and as consequence SMRS may not be updated with the latest data. As a result the ISG agreed that an operational review of the CVA Qualification requirements would be beneficial. ","CP1159 proposes changes to BSCP514 to ensure that up to date information regarding Metering and feeder statuses are delivered to Suppliers.","SVG: 66","CPC00553","SVG","Feb 07 Release","Approve"]
[1158,"Inclusion of UMS Operational Data in MDD","ELEXON","2005-12-23","The approval of CP1083 removed the Unmetered Supplies (UMS) Operational Details from BSCP520 and placed hem in a new document, not included in the Baseline Statement. This made updating these details easier and more cost effective as they were no longer subject to BSCP40 Change Management processes. However, this change also served to further reduce visibility of changes to those market participants without representation on the UMSUG. Without such representation, market participants have limited opportunity to comment on the recommendations of the UMSUG until after a decision has been made.\n","CP1158 proposes that UMS Operational Data should be included in the MDD in order to enhance visibility of changes to the UMS operational details and afford greater participation in the impact assessment of these changes.","SVG: 66","CPC00575","SVG","Feb 07 Release","Approve"]
[1157,"Initial Confirmation of D0265 Receipt","ELEXON","2005-12-23","BSPC528 requires LDSO to submit D0265 SVA Line Loss Factor Data Files annually, in the event of an additional Line Loss Factor Class (LLFC) being added to Market Domain Data (MDD), and in the event that a SVA Line Loss Factor (LLF) has been updated for an existing LLFC. In the case of the Annual Update, the LDSO is time bound to submit this file at least 40 working days prior to 1st April. Although the BSC currently stipulates that a communication may be deemed received (“…in the case of e-mail one hour after being sent, in the absence of any undeliverable return receipt received by the sender during that period.” ) this technical receipt would not mitigate the operational impact that a failure to submit a D0265 could result in.\n","CP1157 proposes a change to BSCP528 so that when a D0265 is submitted by the LDSO, the BSCCo provides a confirmation of receipt.","SVG: 62","CPC00553","SVG","Feb 07 Release","Approve"]
[1156,"Remove PAA as a recipient of BSCP507/1","ELEXON","2005-11-17","BSCP507 requires that Suppliers submit an SVA Standing Data Change Form (BSCP507/1) to the SVAA and additionally to the BSCCo Performance Assurance Administrator (PAA) where a change of Data Collector is being notified. The purpose of this information was to allow the PAA to identify the Data Collectors associated with each Supplier in each GSP Group, and was used in the management of the Performance Assurance Reporting and Monitoring System (PARMS). Since the implementation of a revised PARMS under P99 this information has been provided direct by Suppliers in the form of Data Provider Information (P0135) flows, and so the PAA no longer requires the BSCP507/1 form following a change of Data Collector.","CP1156 seeks to remove the requirement for Suppliers to submit a BSCP507/1 form to the PAA following a change of Data Collector.","SVG: 62","CPC00553","SVG","Feb 07 Release","Approve"]
[1155,"UMS-related Data Flows in the SVA Data Catalogue","ELEXON","2005-11-17","A number of the entries for Unmetered Supplies-related manual data flows (‘P-flows’) in the SVA Data Catalogue do not accurately reflect the sending and receipt of the flows as described in BSCP520. These inaccuracies do not have any implications on participant systems; however they can cause confusion as to how the flows are to be used. ","CP1155 proposes changes to the description of flow instances in the SVA Data catalogue.","SVG: 62","CPC00553","SVG","Feb 07 Release","Approve"]
[1154,"Amendment to form BSCP15/4.1 to facilitate registration of standard BM Units","ELEXON","2005-11-04","Section K of the BSC defines the criteria for the configuration of a BM Unit. It then goes on to list a number of configurations which are deemed to comply with the criteria and can be regarded as ‘standard BM Units’. ","There are five standard configurations listed in Section K and it is proposed that the table on page 2 of BSCP15/4.1 form be modified to include a column so that the Lead Party can identify the relevant standard configuration or note that the BM Unit is non-standard when submitting the registration form.","ISG: 60","CPC00540","ISG","June 06 Release","Approve"]
[1153,"Changes to the Meter Advance Reconciliation Processes as detailed in BSCP05","ELEXON","2005-11-04","Currently BSCP05 obliges the CDCA to visit a site every three months to carry out a MAR. In the four years since the introduction of NETA, the CDCA has not identified a single instance where an Outstation has stored erroneous data due to a problem with the pulsing from a Meter. A three monthly MAR therefore appears to be a significant commitment in time and resources for little benefit. ","CP1153 proposes amendments to BSCP05 regarding the MAR procedures, of Meters both with integral outstations that provide a cumulative reading and Meters with integral outstations that do not provide a cumulative reading of the prime Meter register equivalent to the total consumption or production of that Meter.","ISG: 63","CPC00540/CPC00548","ISG","Feb 07 Release","Approve"]
[1152,"Removal of requirement for the CDCA to approve work on CVA metering systems","ELEXON","2005-11-02","At present a MOA wishing to carry out work on a CVA metering system must inform the CDCA 15 working days in advance using form BSCP06/4.1. Should P190 be approved BSCP06 will need substantially modifying and it will no longer be necessary for the CDCA to give approval for work to be carried out as they will not be required to send an agent to site.","CP1152 proposed to remove Form BSCP06/4.1. The process for carrying out work on CVA metering systems in BSCP06 will be updated","ISG: 60","CPC00540/CPC00548","ISG","June 06 Release","Approve"]
[1151,"Late Comment on Clarity of the P183 changes to BSCP504 Step 3.2.6.8","ELEXON","2005-10-25","At a walkthrough of CTP processes concern was expressed that the wording of the BSCP504 changes for Modification Proposal P183 was unclear, and could be read in a manner inconsistent with the agreed solution (step 3.2.6.8 in particular). It is proposed to clarify the wording in the Feb ’06 release.","CP1151 proposed to remove the words “except if this reading is an old\nSupplier Estimated reading” (which will be added in November) from the Action column of step\n3.2.6.8, and from the corresponding box on the workflow diagram in step 2.2.6. This will avoid any\nimplication that BSCP504 does not permit an OSER to be submitted on a D0071 flow.","SVG: 58","CPC00539","SVG","Feb 06 Release","Approve"]
[1150,"MDD Registration Principles","ELEXON","2005-10-06","BSCP509 is unclear as to when the MDD process should commence for a newly registered BSC Party or Party Agent. BSCP509 details the processes involved but not when those processes should commence. This lack of clarity has led to complications in the past.","BSCP509 ‘Changes to Market Domain Data’ should be updated to reflect the changes.","SVG: 58","CPC00532","SVG","June 06 Release","Approve"]
[1149,"NHHDA software does not support reporting to Suppliers of the changes resulting from an SMRS refresh","ELEXON","2005-10-06","BSCP505 describes the requirement for NHHDAs to perform a full annual refresh of SMRS data.  As part of the process the NHHDA should compare the new data (as contained in the SMRS refresh file) with the old data (as stored on the NHHDA database). The current NHHDA software does not readily support this requirement.","There are two version of CP1149. Version 1 of this CP proposed 2 solutions:\n• Option 1 was to remove the requirement from BSCP505 and PSL140.\n• Option 2 was to amend the NHHDA software to include the Supplier Id for each data change\nreported on the Refresh Processing Log, so that the report can be split by Supplier. Version 2 of this CP has therefore been raised to introduce another option (Option 3) and Option 2 from CP1149 is not being progressed. Option 3 (New Option) It is proposed that the current requirement in section 3.2.3.7 of BSCP 505 is amended in line with ELEXON guidance, such that the requirement is for NHHDAs to provide Suppliers with a description of the updates performed on the database as a result of a Full Refresh. ","SVG: 60","CPC00532/CPC00548","SVG","June 06 Release","Approve"]
[1148,"Removing Section 4.6 ‘Standard File Format for Unmetered Supplies Detailed Inventories’ from BSCP520","ELEXON","2005-10-06","The Standard File Format for Unmetered Supplies Detailed Inventories indicates how the file containing the details of each inventory of Unmetered Supplies should be structured appears in both BSCP520 and Section 3 of the new Unmetered Supplies Operational Information document. ","CP1148 proposed solution is to remove Section 4.6 from BSCP520, removing the duplication.","SVG: 60","CPC00532","SVG","June 06 Release","Approve"]
[1147,"Clarification of requirements for de-energised HH Metering Systems","ELEXON","2005-09-12","BSCP502 and PSL130 contain a number of generic requirements that are not always appropriate to Metering Systems that are in a de-energised state, and there is a lack of clear guidance on how such Meters should be treated by Suppliers and Supplier Agents. ","CP1147 proposes to make changes to BSCP502 and PSL130 in order to clarify several issues regarding de-energised Half Hourly Metering Systems.","SVG: 57","CPC00527","SVG","June 06 Release","Approve"]
[1146,"Clarification of timescales for SMRS Refreshes","ELEXON","2005-09-02","DAs are required to conduct a full refresh of SMRS data ‘at least once every year’ (BSCP503/505). This could be interpreted as once every calendar year or once in every rolling 12 months period. However, DAs are entitled to only one free full refresh every year (MRA Schedule 8, clause 22). This means, due to timing issues, if DAs wish to refresh once in every 12 months they have to pay for the refresh.","The intention of CP800 was that every Settlement Date should undergo a Full Refresh prior to being aggregated for Final Reconciliation. In order to achieve this, it is proposed to change steps 3.2.2.1 of BSCP503 and 3.2.3.1 of BSCP505 to require that the Data Aggregator request a Full Refresh at least once in every rolling 13 month period. This will achieve the original intent of CP800 by ensuring that (barring difficulties in applying the refresh that take over a month to resolve) all Metering Systems are subject to Full Refresh prior to Final Reconciliation. ","SVG: 57","CPC00527","SVG","June 06 Release","Approve"]
[1145,"Removal of particular requirements pertaining to register readings in the Half Hourly Market to improve Settlement efficiency (Part 3 of 3).","ELEXON","2005-07-20","BSCP502 states that; 1.HHDC to receive initial/final Meter readings from the MOA on a D0139 flow and 2.HHDC to receive the final Meter register reading from the old HHDC. ","CP1145 proposes to remove these mandatory requirements from BSCP 502 as, it incurs unnecessary cost for Agents and ultimately Suppliers.","SVG: 57","CPC00522","SVG","June 06 Release","Approve"]
[1144,"Removal of particular requirements pertaining to register readings in the Half Hourly Market to improve Settlement efficiency (Part 2 of 3).","ELEXON","2005-07-20","BSCP502 describes various situations where an “initial” or “final” meter reading are required to be obtained and processed by the HHDC Agent under different circumstances. A HHDC cannot add any value to the process in which they receive a D0010 from the HHMO and this indirect routing of information can only add delay/potentially terminate the process.","CP1144 proposed that a change be raised against the DTC to facilitate the sending of a D0010 directly from the MO to both the Supplier and the LDSO, thus enabling the information to be sent direct to the relevant Parties. The requirement for HHDC action within BSCP502 (Sections 3.2.1, 3.3.1, 3.3.2 and 3.3.6) can therefore be removed and BSCP514 amended to describe the action required by the MO. ","SVG: 57","CPC00522","SVG","June 06 Release","Approve"]
[1143,"Removal of particular requirements pertaining to register readings in the Half Hourly Market to improve Settlement efficiency (Part 1 of 3).","ELEXON","2005-07-20","BSCP502 requires that where the HHDC Agent obtains a physical meter reading via the annual site visit or from the MO the HHDC shall compare this manual reading to the reading collected remotely on interrogation at the nearest date and time. ","CP1143 does not believe that this requirement is necessary  as it is already addressed in the MAR/Mini MAR and Proving Test processes.","SVG: 57","CPC00522","SVG","June 06 Release","Approve"]
[1142,"Changes to the Proving Test Process ","ELEXON","2005-07-12","The Proving Test process is susceptible to failure/non-completion due to various generic Supplier Agent non-compliances and also the current procedures used to administer and support the trading arrangements requirements for proving tests. The two main issues are: 1. Metering Equipment Technical Details not being provided to Data Collectors; and 2. Proving tests not being performed on a timely basis.","CP1142 proposed that the D0268 should be used as the trigger to initiate the Proving Test and the use of the D0005 in this “initial” Proving Test request will become redundant. A process requirement for HHMOs to be introduced and included in the Proving Test section of BSCP514. In the instance that a Proving Test is “failed”, the HHMO should initiate a retest by completing and submitting a D0005 to the HHDC – this would be the only instance in the Proving Test Process in which this flow should be used. Amend Section 4.6.5 of BSCP 502 to read: “In the event that timescales are exceeded and the Proving Test is not completed, the process shall proceed to completion and an audit trail will be maintained by Supplier Agents in order to explain the delay. A change to the D0268 should be progressed to add “GPRS” as a communications method to the data\nitem J0386.\n","SVG: 62","CPC00522/CPC00542/CPC00552","SVG","−","Rejected"]
[1141,"Revision to Apportionment form F536/02 in BSCP536","ELEXON","2005-06-30","The current Apportionment Report (F536/02) in BSCP536 needs revision to reflect the design of the report that will be produced as part of P99 PARMS Release 4.","The report should be amended to the design given in Attachment 1 to this CP.","ISG: 54","CPC00514","ISG","Nov 05 Release","Approve"]
[1140,"Removal of ECVNs/MVRNs from ECVAA for a Party in Section H Default","ELEXON","2005-06-27","There is currently no documented process for removing and terminating all ECVNs and MVRNs from ECVAA in the specific case of a Party in Section H Default. ","CP1140 proposes to insert new sections as appropriate into the ECVAA Service Description and ECVAA URS, outlining the procedure to be followed.","ISG: 56","CPC00514/CPC00528","ISG","Feb 06 Release","Approve"]
[1139,"Housekeeping CP for SVA November 05","ELEXON","2005-06-22","ELEXON has identified a number of Code Subsidiary Documents (CSDs) that require minor housekeeping changes in order to correct manifest errors and resolve inconsistencies. The changes are opportune, as all of the documentation to be amended is already impacted by the existing scope of the SVA November 05 Release.","CP1139 proposed a set of proposed housekeeping changes.","SVG: 54","−","SVG","Nov 05 Release","Approve"]
[1138,"The Identification and Labelling of Meter Registers","ELEXON","2005-06-10","The Customer Transfer Programme (CTP) has noted that no industry convention has been established to regulate how the J0010 ‘Meter Register ID’ data item should be populated. At the moment, different Meter Operation Agents (MOAs) use different conventions. As a result, it is not always easy to identify the registers that are displayed on the physical metering asset on the basis of the J0010 data item and vice versa. This results in issues for the Data Collector in accurately allocating a meter reading to a meter register and subsequent processing issues. ","CP1138 aims to improve the accuracy of the allocation of metered energy to meter registers. It also seeks to establish clearer guidelines for the identification of registers on all new meters, thereby enabling Change of Agent (CoA) and Change of Supplier (CoS) processes to function smoothly.","SVG: 56","CPC00510","SVG","Nov 06 Release","Approve"]
[1137,"NHHDA Browse Activity Statuses access","ELEXON","2005-06-03","Part of the operational work of the NHHDA users is to check that the overnight batch processes have run successfully. This is done via the Form “Browse Activity Statuses” in the Activities menu. Currently none of the 7 available roles in NHHDA give access to Browse Activity Statuses without also granting access to Edit Standing Data. ","CP1137 proposes to Amend the default Roles setup in the NHHDA system, by creating a new role which has access to the Activities menus but not Standing Data.","SVG: 57","CPC00522","SVG","−","Rejected"]
[1136,"Extension of  related common MTCs","ELEXON","2005-05-20","There are two categories of Meter Time switch Code, 'Common Codes' and 'LDSO Specific Codes'. Accepted industry practice appears to be that Licensed Distributors should take responsibility for defining in MDD the set of MTCs that their SMRS will accept as valid.\nCurrently, there are no existing common codes for switched MPANs., limiting the use of Common Codes. ","CP1136 seeks to relax the restrictions on creating new common codes, to solve this issue.","SVG: 65","CPC00510","SVG","−","Rejected"]
[1135,"Inclusion of Erroneously Large EAC and AA Reporting Tool into the NHHDA software","ELEXON","2005-05-18","Currently Non Half Hourly Data Aggregators (NHHDAs) are required to run an unsupported reporting utility to provide mandatory reporting to ELEXON regarding Supplier and Non Half Hourly Data Collectors (NHHDC) performance levels. This data is essential as it supports decisions made by the Trading Disputes Committee (TDC) for the authorisation of SVA Post Final (DF) runs to resolve erroneous Estimated Annual Consumption / Annualised Advances (EAC/AAs). The current utility (The ‘Large EAC/AA Reporting Tool’) was originally developed internally at ELEXON, although it has since been maintained by the NHHDA application Service Provider. However, because of its current unsupported status, there is no mechanism in place for ensuring that the utility will continue to perform correctly (and within acceptable timescales) with future releases of the NHHDA software.","CP1135 proposes that the Large EAC and AA Reporting Tool are integrated into the NHHDA software, to ensure that the utility is supported, and continues to function with new versions.","SVG: 57","CPC00510","SVG","Feb 06 Release","Approve"]
[1134,"Clarification of Meter Reading History (D0010/D0152) Interface on Change of Supplier ","ELEXON","2005-05-13","On Change of Supplier (CoS), the old Supplier’s NHHDC is obliged to send meter reading history to the new NHHDC in accordance with step 3.2.6.4 of BSCP504. Discussions with NHHDCs suggest that different agents have different interpretations of this requirement. ","CP1134 proposes to amend the interface definition of BSCP504 to clarify that the NHHDC should always send the latest valid set of meter readings and the calculated EAC value(s).","SVG: 53","CPC00503","SVG","Feb 06 Release","Approve"]
[1133,"Additional Mechanism for New NHHDC to Obtain Meter Reading History on Change of Supplier ","ELEXON","2005-05-13","One of the current weaknesses of the Non Half Hourly Change of Supplier (CoS) process is that the new Non Half Hourly Data Collector (NHHDC) is dependent upon the old NHHDC for meter reading history (i.e. the last valid set of register readings and associated EAC values). ","CP1133 proposes that the new NHHDC should be able to request the meter reading history from the new Supplier in those cases where the old NHHDC has failed to provide it.","SVG: 53","CPC00503","SVG","Nov 05 Release","Approve"]
[1132,"Minor enhancements to the P176 detailed solution","ELEXON","2005-05-12","There are inconsistencies between some of the processes defined under P176 and current practice. It has also become clear that some of the drafting may not be practical and there are a number of issues and minor amendments that should be resolved in parallel with the implementation of P176. These were not addressed under P176 and hence they have been raised as this separate Change Proposal (CP).","CP1132 proposes a number of amendments to the P176 solution.","SVG: 53","CPC00503","SVG","Nov 05 Release","Approve"]
[1131,"Changes to FAA Documentation arising from an internal audit by the Service Provider","ELEXON","2005-05-10","An audit was carried out on the FAA documentation by the FAA service provider and a number of changes have been identified as being necessary.  There are also a number of clarifications that need to be made to the documentation as a result of the implementation of CP1078.","CP1131 proposed a number of amendments to the FAA suite of documentation.","ISG: 53","CPC00503","ISG","Nov 05 Release","Approve"]
[1130,"Inconsistency between BSCP507 and BSCP38 with regards to Authorised Signatures","ELEXON","2005-05-10","BSCP38 states that Category W signatories are responsible for submitting SVA Standing Data changes. BSCP507 Form 507/01 states that BCA Signatories are responsible for submitting all SVA Standing Data changes. Currently, the BSCPs contradict each other.","CP1130 proposed the BSCP507/01 form should be amended so that it shows that a Category W signature must sign off all changes to Standing Data.  It is recommended that current BCA signatories, be automatically added as Category W signatories upon implementation of this Change Proposal. On an ongoing basis BSC Parties will not automatically become category W signatories upon registration as a BCA signatory.","SVG: 53","CPC00503","SVG","Nov 05 Release","Approve"]
[1129,"Clarification of process for Parties to re-initiate BSCP38 process.","ELEXON","2005-05-10","ELEXON has received feedback from Parties that have used this procedure to state that BSCP38 is not clear on the treatment of Parties that have no valid Authorised Persons left in their organisation to sign BSCP documentation, either through staff turnover or due to the company going into administrative receivership.","CP1129 proposed that Statement of clarification is added to BSCP38 indicating that Parties that no longer have any valid or available authorised signatories or companies in administration should send in a completed relevant Declaration of Authorised Persons form accompanied by a letter on Company stationary signed by a registered Company Director or an Administrator for the Company. It is suggested that this clarification should be added to footnote 2","ISG: 53                        SVG: 53","CPC00503","ISG/SVG","Nov 05 Release","Approve"]
[1128,"Changes to BSCP301, ‘Clearing, Invoicing and Payment’","ELEXON","2005-05-10","A number of required changes to BSCP301, ‘Clearing, Invoicing and Payment’ have been identified. The changes are to the following areas: 1: Provision of Letter of Credit (LoC). 2: Timetable. 3: Procedure.  4: Code References                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 ","The implication that a LoC has any flexibility from the prescribed format should be removed as proposed in Appendix A. The reference to the Code for the reduction in Credit Cover criteria should be changed. This statement is currently also contained in the preamble to Section 4.6.3 and should be removed in its entirety from that location. Section 4.6, ‘Manage Credit Cover’, stretches to 38 steps. The mean request should also be submitted within an appropriate timescale and run 10SDs + 3-5WDs prior to the stated Withdrawal Date. Section 4.6.2 should be re-drafted as shown in Appendix B. The Business Process Model (BPM) should be updated to correctly model the processes in BSCP301. BSCP65 will need a change to 4.6.15 and Appendix 3 ‘exit checklist’ to reflect the new timescale.","ISG: 54","CPC00503","ISG","Nov 05 Release","Approve"]
[1127,"Inconsistencies within the SVA Data Catalogue","ELEXON","2005-04-26","Errors exist within the current version of the SVA Data Catalogue.  Inconsistencies have been introduced between BSCP details (‘Data requirement from BSC Procedure’) and Tech Spec details (‘Physical File Specification’) due to previous inaccuracy when updating the document.","CP1127 proposed changes should be made to the SVA Data Catalogue to ensure\naccuracy and consistency with other documents.","SVG: 53","CPC00503","SVG","Feb 06 Release","Approve"]
[1126,"Clarification of the term “Significant Date” in the Non Half Hourly Instruction Processing Specification ","ELEXON","2005-04-26","Section 3 of the NHH Instruction Processing Specification explains Relevant Relationship, Relevant Relationship Change and Significant Date.  Section 3.1.3 includes a number of examples of the Significant Date (using line diagrams representing the dates of Relevant Relationship Changes).  Some of these diagrams are wrong.","CP1126 seeks to address the identified issues and clarify the meaning of “Significant Date”.","SVG: 53","CPC00503","SVG","Feb 06 Release","Approve"]
[1125,"Submission of the D0028 ‘Standing Profile Data Report’ over the Data Transfer Network","ELEXON","2005-04-08","ELEXON Circular EL01284 provided details of an issue at the Supplier Volume Allocation Agent (SVA Agent) whereby D0028 Standing Profile Data Reports were unable to be issued via the Data Transfer Network (DTN) to Suppliers and Non-Half Hourly Data Collectors (NHHDCs) for all post BETTA Go Live Settlement Days. The issue itself arose as a consequence of an increase in field length of one of the data items in the D0028. This Change Proposal proposes to address this issue.","CP1125 addressed three option to face these issues. ","SVG: 52","CPC00499","SVG","Feb 06 Release","Approve"]
[1124,"Use of alternate methods of validation during the Non-Half Hourly Change of Supplier Process","ELEXON","2005-04-08","Currently, during the change of Supplier (CoS) process, the new Non-Half Hourly Data Collector (NHHDC) is reliant on receiving Meter reading history from the old NHHDC to validate the CoS reading.  Where Meter reading history is not received, the Metering System is said to be ‘broken’.  There are currently no provisions in the Code or Code Subsidiary Documents to describe how the new NHHDC should treat a broken Metering System.","CP1124 proposed to amend two validation rules of BSCP504 ‘Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’.","SVG: 52","CPC00499","SVG","Feb 06 Release","Approve"]
[1123,"Use of Early Readings during the Non-Half Hourly Change of Supplier Process","ELEXON","2005-04-08","New Suppliers, when winning a customer should be able to take a Meter reading, if possible, at the time that the Customer agrees to sign up to their service but also during the period between the customer entering into the contract and the start of the meter reading window.  This reading is referred to as the Point of Sale (PoS) or early reading in this CP.","Changes will need to be made to BSCP504 ‘Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ to recognise the PoS reading and to provide guidance on how it should be used. It is proposed that this should be mainly contained in a new appendix to BSCP504, titled ‘Use of Early Readings in the change of Supplier process’. ","SVG: 52","CPC00499","SVG","Feb 06 Release","Approve"]
[1122,"Inclusion of the Backstop Process as part of the Change of Supplier Process into Code Subsidiary Documents ","ELEXON","2005-04-08","The MRA Development Board (MDB) has agreed the inclusion of the Supplier Agreed Read process into MAP08, in order to give Suppliers the ability to agree a Meter Read where the normal processes have failed to produce a D0086 within 30 WD of SSD.  ","CP1122 proposes to reflect the same process in the BSC Code Subsidiary Documents and it is dependent on the outcome of Proposed Modification P183 ‘Additional Mechanisms for Obtaining a Valid Change of Supplier Read’. ","SVG: 52","CPC00499","SVG","Feb 06 Release","Approve"]
[1121,"Defect in NHH Aggregation Rules in NHHDA Logical Design","ELEXON","2005-04-06","There is an error in the NHH aggregation rules specified in the NHHDA Logical Design (function reference N0008). Both Annex S-2 4.4.3 and the NHHDA URS are clear that consumption data should not enter settlement if it was provided by Non Half Hourly Data Collector whose appointment (as recorded on SMRS) has not started at the time the run takes place.","CP1121 proposed that wording of function N0008 in the NHHDA Logical Design should be clarified to resolve this documentation error on an opportune basis. ","SVG: 53","CPC00503","SVG","Feb 06 Release","Approve"]
[1120,"Amendment of the Trading Query Deadline for SVA Half Hourly Trading Queries","ELEXON","2005-03-23","Under the current drafting of BSCP11, ‘Trading Queries and Disputes’, the Query Deadline for SVA Half Hourly (HH) Trading Queries is defined as ‘the 20th Working Day following the carrying out of the First Reconciliation Run or the 20th Working Day following the Timetabled Reconciliation Settlement Run in which the Settlement Error first occurred’. It is proposed that the Trading Query deadline was extended to R2 + 20 WD.","Given the view of the industry working group that many HH SVA Trading Queries can be resolved by Suppliers and their Agents prior to the Second Reconciliation (R2) Run, it is proposed that the Query Deadline for SVA HH Trading Queries should be extended from R1 + 20 WD to R2 + 20WD. ","TDC: 78","CPC00510","TDC","Nov 05 Release","Approve"]
[1119,"Amendment of BSCP11, ‘Trading Queries and Trading Disputes’, to address the treatment of “precautionary” Trading Queries which could potentially be resolved outside the Trading Query process prior to Final Reconciliation.","ELEXON","2005-03-23","It has been identified that Parties have adopted the practice of raising “precautionary” Trading Queries within the R1 plus 20 working day (WD) deadline in order to mitigate against errors remaining uncorrected at Final Reconciliation (RF) which have missed the R1 plus 20 WD deadline.  The Code allows for the pre-RF correction of certain HH SVA errors outside of the Trading Query Process. However, BSCP11 does not cater for circumstances where a Trading Query has been raised within the Query Deadline, but has subsequently been corrected within RF by the Supplier and its Agents.","CP1119 proposed that BSCP11 should be amended to specify that “precautionary” Trading Queries should be identified as such by the Raising Party when first raised. Any Trading Query identified as “precautionary” could sit “on ice” between it’s acknowledgement by ELEXON and the start of investigation and analysis. ","TDC: 78","CPC00510","TDC","Nov 05 Release","Approve"]
[1118,"Clarification of the Trading Query end-date","ELEXON","2005-03-23","BSCP11, ‘Trading Queries and Trading Disputes’, Section 1.4 states that a Trading Query will not be accepted or processed by the Disputes Secretary unless a BSCP11/01 form is submitted, completed with (amongst other things), details of all affected Settlement Periods and Settlement Days claimed. As such, BSCP11 currently requires the Raising Party to supply both a start-date and an end-date for all Trading Queries raised. The current wording of BSCP11 is not consistent with the Code.","CP1118 proposed to clarify that an end-date need only be specified where known. ","TDC: 78","CPC00510","TDC","Nov 05 Release","Approve"]
[1117,"Upgrade of NHHDA and EAC/AA systems to Oracle 10g.","ELEXON","2005-03-14","The current versions of the NHHDA and EAC/AA systems operate under Oracle 9i for the server\napplication and Oracle Forms 6i for the client. Oracle Corporation has announced the end of Error Correction Support (ECS) for Oracle Forms 6i for all platforms as of 31 December 2004. Extended Support (ES) will be provided to all customers until 31 December 2007 if the customer has a current support contract although this will incur an additional cost. ","CP1117 proposes the upgrade of the NHHDA and EAC/AA systems software applications to operate using Oracle 10g client and server.","SVG: 57","CPC00510","SVG","Nov 06 Release","Approve"]
[1116,"Upgrade of SVA System and SVA Agent Applications to Oracle 10g","ELEXON","2005-03-14","The current versions of the SVA System and SVA Agent Applications operate under Oracle 9i for the server application and Oracle Forms 6i for the client. Oracle Corporation has announced the end of Error Correction Support (ECS) for Oracle Forms 6i for all platforms as of 31 December 2004. Extended Support (ES) will be provided to all customers until 31 December 2007 if the customer has a current support contract although this will incur an additional cost. ","CP1116 proposes the upgrade of the SVA System and SVA Agent Applications software applications to operate using Oracle 10g client and server.","SVG: 57","CPC00510","SVG","Nov 06 Release","Approve"]
[1115,"Authorisation View when using the P98 Web Reporting Service","ELEXON","2005-03-18","The web based system for submitting contract notifications was delivered as part of the solution to modification proposal P98. After logging on to the system and before being able to submit a contract notification the user has to select the counterpart to the trade. BGT and Accord Energy have in place a significant number of authorisations with a wide range of counterparts. With a significant number of authorisations in place it is not always easy to locate the required counterpart. BGT would like the ability to sort the counterparts on the basis of the most recently notified trade and then alphabetically. In respect of the second page a search by alphabetical order would be sufficient.","CP1115 believes the proposed solution should provide for an additional page under the ‘ECVNA Authorisation View’ that will allow ECVNA authorisations to be split. ","ISG: 54","CPC00510","ISG","−","Rejected"]
[1114,"Ability to Cut and Paste using the P98 Web Reporting Service","ELEXON","2005-03-18","P98 was delivered as part of the November 2004 release schedule at considerable expense to the industry. British Gas Trading (BGT) believes it is appropriate for market participant to have the ability to submit contract notifications via the ECVAA web based reporting functionality and for this system to be robust.  To improve this process and thereby reduce the risk of making an error when submitting contract notifications BGT believe there should be the ability to copy values from the source data rather than having to input values for all settlement periods."," To improve this process and thereby reduce the risk of making an error when submitting contract notifications BGT believe there should be the ability to copy values from the source data rather than having to input values for all settlement periods.","ISG: 54","CPC00510","ISG","−","Rejected"]
[1113,"Acknowledgement when using the P98 Web Reporting Service","ELEXON","2005-03-18","P98 was delivered as part of the November 2004 release schedule at considerable expense to the industry.  British Gas Trading (BGT) believes it is appropriate for market participant to have the ability to submit contract notifications via the ECVAA web based reporting functionality and for this system to be robust.  Whilst it is possible under the current baseline to submit contract notifications, only a positive acknowledgement is provided by central systems and not a negative acknowledgement.  BGT believes that a screen based acknowledgement system needs to be developed to allow Parties to effectively manage the risk of making contract notifications via the web-based service.","The solution should allow Parties submitting contract notifications via the web based system to copy the values from the source data. If the additional solution is also implemented then users of the website could be presented with the standard profiles and once a value had been entered for one settlement period it would automatically populate the remainder of the settlement periods.","ISG: 54","CPC00510","ISG","−","Rejected"]
[1112,"Changes to BSCP32 following operational review.","ELEXON","2005-03-08","In light of operational experience, BSCCo became aware that BSCP32 ‘Metering Dispensations’ would benefit from an operational review to deliver improvements to the process that would benefit both BSCCo and Parties.","The review group identified a number of solutions that would address the above areas, and which would deliver a clearer and more robust process. A number of house-keeping changes are proposed to BSCP32.","ISG: 55                                SVG: 55","CPC/00503CPC00528","ISG/SVG","Feb 06 Release","Approve"]
[1111,"GSPGCF Relocation","ELEXON","2005-03-08","GSP Group Correction Factor is the only Market Indicator supported by pre P99 PARMS which is not supported by the post P99 PARMS. This CP proposes that GSPGCF Market Indicator is supported by new PARMS. Also, if P157 is approved it is to be implemented on a Calendar Day basis in new PARMS and will not allow any resubmissions that would affect data in old PARMS.  At this point old PARMS will not need to be maintained at all.","CP1111 proposed that new PARMS is amended to support GCF Market Indicator. This will involve new PARMS loading the weekly flow from SVAA and the migration of existing GCF data (since September 1998) from old PARMS. No change to the format of the file from the Supplier Volume Allocation Agent (SVAA) is required or suggested.",{"$nulls":3},"—","Withdrawn"]
[1110,"Amendments to PARMS Response Files","ELEXON","2005-03-02","Following an internal review we have the following recommendations that ELEXON believes would enhance the processes and files supporting Post P99 PARMS reporting. The format of each file type sent out by ELEXON has been considered (TR, CR, DR and ER), and also the email procedure which supports this process. All of the changes proposed affect files sent by ELEXON only. ","CP1110 contains recommendations which, it is believed, would enhance the processes and files supporting Post P99 PARMS reporting.","SVG: 54","CPC00503/CPC00513","SVG","−","Rejected"]
[1109,"Changes to Forms in BSCP38 ‘Authorisations’ to allow multiple Authorisation Applications","ELEXON","2005-02-22","The current layout of the forms in BSCP38 ‘Authorisations’ requires an Authorised Signatory to sign a form for each applicant upon which it is conferring an authorisation. For new starters or on changes of ownership this process is inefficient, and so it is proposed to modify the forms to allow an Authorised Signatory to sign for a number of authorisation applications at one time.\n\n","CP1109 proposed changes to BSCP38/5.1 and to BSCP38/5.3.","SVG: 52","CPC00499","SVG","Nov 05 Release","Approve"]
[1108,"Simplification of Change of BM Unit Ownership (CoBO) Process for CVA BM Units","ELEXON","2005-02-10","Currently Parties wishing to undertake a CoBO for BM Unit(s) registered in CVA are required to achieve this via a de-registration and re-registration through BSCP15. These processes were originally drafted to cover the final de-registration of a BM Unit and the registration of a new connection and therefore contain many steps which would not be applicable for Parties who simply wish to transfer BM Unit(s) which has/have already been registered to another BSC Party.\n\n","CP1108 proposed that a specific process is added to BSCP15 in order to clarify the CoBO processes for CVA BM Units in order to ensure only the necessary steps are followed. ","SVG: 52","CPC00499","SVG","Nov 05 Release","Approve"]
[1107,"Timescale change to the 100kW notification from Non-Half Hourly Data Collectors.","ELEXON","2005-01-28","Step 3. 4. 1. 6 of BSCP504 requires the Non-Half Hourly Data Collector, “upon identification”, to notify its Supplier of any occurrence where 100kW has been exceeded (via the P0028 100kw Demand Report). \n\n","CP1107 proposes to Simplify and streamline this process by defining a given timescale by when each NHHDC should provide such notification to its Supplier.","SVG: 51","CPC00496/CPC00499","SVG","Nov 05 Release","Approve"]
[1106,"Change to BSCP514 bring it in line with a requirement in BSCP504 ","ELEXON","2005-01-28","A number of Data Transfer Catalogue flows relating to prepayment Meters (Non Half Hourly only) that are widely used within the industry are not referenced within the relevant BSCPs. Some of these data flows relate to Settlement. There is therefore inconsistency between current practise and the Code Subsidiary Documents.","CP1106 proposed change to the NHHDA installation process for creating new NHHDA databases and the NHHDA System Management Guide to use the revised default values contained ‘UNIX Upgrade of NHHDA & EAC/AA Project - Circular 02’ (shown in bold). ","SVG: 50","CPC00490","SVG","Nov 05 Release","Approve"]
[1105,"Prepayment Flows relating to Settlement – Changes to Code Subsidiary Documents","ELEXON","2005-01-24","A number of Data Transfer Catalogue flows relating to prepayment Meters (Non Half Hourly only) that are widely used within the industry are not referenced within the relevant BSCPs. Some of these data flows relate to Settlement. There is therefore inconsistency between current practise and the Code Subsidiary Documents.\n\n","CP1105 proposed that BSCP504 (Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS), BSCP514 (SVA Meter Operations for Metering Systems Registered in SMRS) and BSCP515 (Licensed Distribution) are updated to include new appendices stating that for certain circumstances, different flows are used for prepayment meters than for credit meters. ","SVG: 50","CPC00490","SVG","Nov 05 Release","Approve"]
[1104,"BSCP520 is Inconsistent with Current Practice for Registration of Unmetered Supplies in the North Scotland GSP Group","ELEXON","2005-01-17","In England and Wales, Appendix 4. 3 of BSCP520 specifies the Standard Settlement Configurations (SSC) for use with Unmetered Supplies (UMS). However, in the North Scotland GSP Group Suppliers are currently obliged to use different SSC and TPR codes, as defined in section 4. 5 of SAS Market Procedure MP520. Currently BSCP520 doesn’t recognise these codes, so from the BETTA Effective Date onwards Suppliers in North Scotland will be unable to comply with BSCP520.\n\n","CP1104 proposed to amend BSCP520 to reflect the use of SSC codes 0925 – 0928 in North Scotland.","SVG: 50","CPC00488","SVG","Feb 05 Release","Approve"]
[1103,"Changes and clarifications to BSCP 533, 534 and 536 arising from the implementation of Phases 3 and 4 of PARMS.","ELEXON","2005-01-17","BSCPs 533, 534 and 536 require minor amendment or additional clarification as a result of the implementation of the Phase 3 and 4 functionality for Performance Assurance Reporting and Monitoring System (PARMS). These phases deliver the Supplier Charge element of PARMS as well as refinements to the system based on findings arising from Phase 2. ","CP1103 seeks to correct an error in the list of Peer Comparison Serials detailed in BSCP534.","SVG: 52","CPC00490","SVG","Nov 05 Release","Approve"]
[1102,"Sending of the D0052  by Unmetered Supplies Operators","ELEXON","2005-01-17","The UMSO is unable to send data electronically via the Data Transfer Network as it is not a user.  The UMSO therefore has to rely on manual processes to submit its D0052 data, which includes UMS EAC values for use in Settlement.","The UMSO should be able to send the D0052 to the NHHDC via the DTN. It is proposed to allow the Licensed Distribution System Operator (LDSO) to send UMSO associated D-flows over the DTN on behalf of their UMSO (since the UMS is a service provided by each LDSO), however there are two options for the implementation of this requirement.\nOption 1: the UMSO would use their own role code.\nOption 2: the UMSO would use the LDSO role code. ","SVG: 51","CPC00490","SVG","Feb 06 Release","Approve"]
[1101,"Allowing the use of IF Statements - CVA Metering Systems","ELEXON","2004-12-07","Currently the inability to use logical ‘IF’ statements in the aggregation rules for CVA BM Units means that some BM Unit metered volumes are being calculated incorrectly, with a consequential impact on the credit cover calculations for those parties affected.","Section R3.3.1 of the BSC allows the use logical ‘IF’ statements within BSCP75 following agreement from the Panel. This agreement should be granted and BSCP75 should be changed to allow the use of logical ‘IF’ statements within the aggregation rules.","ISG: 50","CPC00503","ISG","−","Rejected"]
[1100,"Removal of generic Metering Dispensations from Codes of Practice 3 and 5.","ELEXON","2004-12-02","The CoPs currently have generic Metering Dispensations published as appendices. When a new generic Metering Dispensation is approved, the CoPs should be amended via BSCP40, i. e. a CP must be raised and progressed. The publishing of Generic Dispensations in CoPs would be carried out as opportune. Since CoPs are rarely updated, there are currently a number of generic dispensations that have not been published in the appropriate CoP.\n","Rather than amend the CoPs every time there is a new generic dispensation, BSCCo should publish these on the Metering Dispensations section of the BSC Website and advise the industry of this. This process should be included in BSCP32 ‘Metering Dispensations’. The CoPs would have a general statement with regard to generic dispensations to say that these are contained on the BSC Website, for completeness. Generic dispensations are approved by the appropriate Panel Committee, so participants should feel comfortable that removing the process by which the Panel Committee approves a CP to include the generic dispensation in a CoP does not remove the Panel Committees obligations to initially approve the generic dispensation. ","ISG: 50                SVG: 51","CPC00490","ISG/SVG","Nov 05 Release","Approve"]
[1099,"Change to the Requirements for Meter Type Compliance and Protocol Approval","ELEXON","2004-11-30","The Pool Requirements of the DTS should cease to be a BSC Configurable Item and should be removed from the BSC Baseline. The file structure of the Pool Transfer Format should be included in the SVA Data Catalogue alongside the Standard Pool Format."," CP1099 seeks to remove the default requirement for NHH Metering Equipment to be subjected to BSCP601 procedures by providing clarification within BSCP601 that its procedures apply only to Metering Equipment intended for use against Codes of Practice 1, 2, 3, 5, 6 and 7.","SVG: 49","CPC00482","SVG","Nov 05 Release","Approve"]
[1098,"Removal of ‘Pool Requirements of the DTS Network’ from Baseline Statement","ELEXON","2004-11-30","The Pool Requirements of the DTS Network document is a Configurable Item and appears on the BSC Baseline Statement, however it is not published on the BSC Website nor has it been updated since the run-up to NETA Go-Live in March 01.","CP1908 proposes the file structure of the Pool Transfer Format should be included in the SVA Dara Catalogue alongside the Standard Pool Format and references to the Pool Requirements of the DTS for this information should be revised accordingly. ","SVG: 50","CPC00490","SVG","Nov 05 Release","Approve"]
[1097,"Changes to validate format of SSC Id and TPR Id","ELEXON","2004-11-04","Each of the Standard Settlement Configurations supported within settlement is identified by a unique Standard Settlement Configuration Id (SSC Id), which is published to SVA participants in Market Domain Data (MDD). Similarly, each of the Time Pattern Regimes is identified by a Time Pattern Regime Id (TPR Id). The SSC Id and TPR Id are defined in the SVA Data Catalogue and Market Domain Data Management (MDDM) software as free-format text fields: CHAR(4) for the SSC Id, and CHAR(5) for the TPR Id.  In fact, however, there is an agreed industry convention (in use ever since the Non Half Hourly (NHH) market was opened to supply competition in 1998) that SSC Id is a four-digit numeric string (with leading zeroes if necessary); and TPR Id is a five-digit numeric string (with leading zeroes if necessary). Under this convention, 01017 would be a permissible TPR Id, but 1017 would not.","In order to address this issue, CP1097 proposed to:\n· Add a note to the SVA Data Catalogue, documenting that the Standard Settlement Configuration Id always consists of four numeric digits (including leading zeroes in some cases);\n· Add a note to the SVA Data Catalogue, documenting that the Time Pattern Regime Id always consists of five numeric digits (including leading zeroes in some cases);\n· Amend the data entry screen that’s used to create new Standard Settlement Configurations within the MDDM application to produce a warning message if the SSC Id doesn’t consist of four numeric digits; and\n· Amend the data entry screen that’s used to create new Time Pattern Regimes within the MDDM application to produce a warning message if the TPR Id doesn’t consist of five numeric digits.\n","SVG: 47","CPC00478","SVG","June 05 Release","Approve"]
[1096,"Confirmation of Energisation and Metering status","ELEXON","2004-11-03","On a change of Supplier or Agent, it is important that the correct Energisation and metering status of the MPANs are advised. Currently there is no formal process for this to happen.  Consequently, the Energisation status is assumed to be energised, when in fact it is de-energised.  The result of these assumptions is that erroneous and default EAC data is being sent through Settlements, and exceptions are being generated.","BSCP514 requires changing to prescribe the requirement to send populated meter flows for both HH and NHH even in the instance where the meter position may be empty at the time. BSCP514 requires a new section to describe the CoS processes for HH and NHH where not linked to a coincident Change of Agent. Within that, process steps should be included to ask whether a meter is or is not installed and whether energised or not. Other items in BSCP514 which would need amending to ensure a consistent approach where there are no meters present are 5.2.1.8, 5.2.3.2, 5.2.4.8, 5.2.5.8, 5.2.6.3, 6.2.1.8, 6.2.3.2, and 6.2.4.8","SVG: 56","CPC00476/CPC00503","SVG","−","Rejected"]
[1095,"Provision of the Complex Site Supplementary Information Form for Complex SVA Metering","ELEXON","2004-11-01","BSCP514 requires the Supplier to co-ordinate the HHMOA to identify Complex Sites and to send a ‘Complex Site Supplementary Information Form’ to the HHDC to enable the correct allocation of the channels to calculate consumption. However, in the event of a change of HHMOA, there is no specific guidance regarding the responsibility for the transfer of this form to the new HHMOA.","Wherever the D0268 is referenced in BSCP514 in the information required section of the interface and timetable, the following sentence is also included ‘If site is complex, refer to Appendix 8.4 Guide to complex Sites’. This should be amended in each case to say ‘If site is complex, send Complex Site Supplementary Information Form. Refer to Appendix 8.4 Guide to complex sites’. This change will clarify that where a site is complex, the complex site supplementary information from should be sent alongside the D0268. Appendix 8.4, paragraph 3 should also be amended to say that if a site is complex, then when a D0268 is sent, the corresponding Complex Site Supplementary Information form shall also be sent.\n","SVG: 48","CPC00478","SVG","Nov 05 Release","Approve"]
[1094,"Change to BSCP503 to include HH flow to Supplier","ELEXON","2004-10-26","In accordance with the BSC Procedure BSCP503, the Half-Hourly Data Aggregator performs specified checks on the data before each Aggregation run and reports anomalies to the relevant Supplier and Data Collector via the D0235 Half Hourly Aggregation Exception Report. This is in order to enable any errors to be corrected. Exceptions are reported at SF, R1, R2, R3 and RF Settlement Runs.","CP1094 proposed that the DAs issue D0235s in accordance with the D0235 calendar including the issue of null reports where there are no exceptions.","SVG: 47","CPC00476","SVG","−","Rejected"]
[1093,"Failure of Suppliers to Submit Valid Standing Data Relationships","ELEXON","2004-10-26","The BSC Auditor has identified that the Supplier, Data Aggregator and Data Collector relationships registered with the SVAA are not always complete and accurate and do not match those registered with Supplier Agents.  The Auditor has shown that consumption data is being provided to the SVAA for relationships not registered in Standing Data, and conversely, consumption is not being received for relationships that are registered in Standing Data.","CP1093 proposed to streamline the current functionality and in doing so provide a better level of control and service to Suppliers.  ","SVG: 51","CPC00482","SVG","Feb 05 Release","Approve"]
[1092,"Untraded Report Obligations",null,"2004-10-11","The Energisation Status Project discovered evidence that Suppliers are partially registering against MSIDs within the SMRA systems but not completing the registration.  If registration is not completed the MSID is classified as UNTRADED.","CP1092 proposed that a new section is added within BSCP501 Suppliers Meter Registration Service whereby SMRAs are enquired to send Suppliers a report of all MSIDs in an untraded state on a monthly basis. \n",null,"CPC00476",null,"—","Withdrawn"]
[1091,"Housekeeping Changes to Settlement Documentation","ELEXON","2005-10-08","ELEXON has identified a number of Code Subsidiary Documents and other Configurable Items that require minor housekeeping changes in order to correct manifest errors, resolve inconsistencies and remove redundant requirements.","CP1091 proposes the replacement of the Poolit copyright statement prevalent in many of the SVA documents. Under GB BSC, all Settlement documentation should be brought under the copyright control of ELEXON Ltd as the GB BSCCo.  ","SVG: 46","CPC00469","SVG","BETTA Go-Live - Apr 2005","Approve"]
[1090,"Provision of Actual Energy values on a Settlement Day basis for PARMS","ELEXON","2005-10-05","The current Supplier Charge rules in Annex S-1 of the BSC treat Supplier serials SP08a, b and c differently in the calculation of their chargeable MWh values.  While the performance of SP08a is required to be monitored and charged on a Settlement Day basis, SP08b and SP08c are only required by the Code to be monitored and charged based upon monthly energy totals. As part of the work on P99 Supplier Charge reversion (as well as discussions on possible future changes under P157 ‘Replacement of current Supplier Charges rules’), it has been identified that the accuracy of the performance percentage calculations for the monthly-based serials SP08b and SP08c may not meet the strict requirements of the Code","Data should continue to be provided at the Settlement Day level in order to accommodate Change of Supplier and Trade Sale events occurring within a reporting period. However, to enable monthly energy values and percentages to be determined as accurately as possible, it is proposed to add, for each serial, an additional data item to the SP08 report containing the absolute value (in MWh) of energy settled on actual data for each Settlement Day. This additional information would remove the first step from the calculation described above and serve reduce the level of error inherent in the determination of the monthly performance percentage","SVG: 45",null,"SVG","Feb 05 Release","Approve"]
[1089,"Inappropriate “dual reporting” of E03/E04 exceptions on the NHHDA Exception Report (D0095)","ELEXON","2004-10-05","The NHHDA Exception Report (D0095) provides Suppliers with details of anomalies in the data provided to Non NHHDA by NHHDC and SMRA. Two of the Exception Types - E03 and E04 - are reported when the NHHDA receives an AA or EAC respectively for a period for which it has not been appointed by the SMRA. Suppliers are currently being impeded in the resolution of correctable instances of superfluous consumption (e.g. data sent to the incorrect NHH Data Aggregator) by the sheer volume of E03/E04 exceptions being reported to them.","Amend the NHHDA Check Data Collector Data (CDCD) functionality such that E03 and E04 are reported to the Supplier according to the NHHDC only. This Supplier should be able to resolve the exception. If the SMRA view of the Supplier is different on resolution of the E03/E04 exception, an E08 and E14 will be reported.\n","SVG: 51","CPC00496","SVG","Feb 06 Release","Approve"]
[1088,"Inclusion of PARMS Response files in BSCP533 Appendix","ELEXON","2004-09-28","Following implementation of P99 various file types were created which are sent to suppliers whose formats are not defined within BSCP533. These files currently include:- Third Party Reports, Completeness Reports and Data Receipt Reports. The format of these reports is not currently defined in any BSCP or Appendix and therefore is outside the jurisdiction of BSCP40.","CP1088 propose that additional appendices be included within BSCP533, or appended to Appendix A, to mandate the format structure within these reports. ","SVG: 46","CPC00466","SVG","June 05 Release","Approve"]
[1087,"Consolidation of PARMS Report Details","ELEXON","2004-09-13","Currently, as each data provider submits a PARMS report, the details are passed in the form\nof a text file to the responsible Supplier / Agent being reported on. To gain an overall picture\nof performance in each serial, Suppliers and Supplier Agents must collate the information from these individual reports. Given the large numbers of data providers reporting on each Supplier / Agent’s performance, this is likely to present a very onerous task. This is particularly true for Suppliers.\n","CP1087 proposes that that in addition to the individual reports currently sent out by PARMS for validation, each Supplier / Agent will receive a report, after the monthly report submission date, with the data from all of its respective data providers, for each Serial.","SVG: 47","CPC00466","SVG","June 05 Release","Approve"]
[1086,"Change HHDC requirements following Failed Proving Test","ELEXON","2004-09-06","BSCP502 requires the HH Data Collector to flag the HH data as ‘E’ in the event of a proving test failure. Further requirements place obligations on both the HHDC and the HHMOA to complete a re-test as soon as possible after the failure and where the timescales provided force the resolution beyond the Initial Volume Allocation Run implies that the HHDC should begin estimation of the data. These requirements are not clear and leave the obligations on the HHDC ambiguous.","CP1086 proposes 4.6.6 ‘Failed Proving Test’ of BSCP502 should be rewritten. References to Codes of Practice should be removed from Section 4.6.6 as the rules should be the same, no matter which Code of Practice the Metering System is related to. The MOA and HHDC shall always complete the re-test as soon as possible after failure of the original proving test and in accordance with BSCP502, section 4.6.5 ‘Proving Test / Re-Test Timescales’.",null,"CPC00476",null,"—","Withdrawn"]
[1085,"Inclusion of ‘underpin’ process in PSL120 ‘Non Half Hourly Data Collection’","ELEXON","2004-09-06","Slow or non-supply of Non Half Hourly Data Collector (NHHDC) data flows can seriously affect the quality of data that the NHHDC agent is able to provide to Suppliers and Settlement. Without the relevant Meter Technical Details and other mandatory flows, the NHHDC is unable to process meter readings. It is proposed that the underpin process be adopted as a method of last resort across the industry.","It is proposed that the underpin process be adopted as an optional method of last resort across the\nindustry. PSL120 would be amended to make provision for this methodology in the Code Subsidiary Documents. It is proposed that a separate guidance note be issued by ELEXON suggesting best practice for escalation and explaining in detail how to use the underpin process. Parties are invited to state as part of their impact assessment whether they believe the introduction of this process on an optional basis is acceptable, or if they believe the use of the underpin process should be mandatory.","SVG: 51","CPC00466/CPC00496","SVG","Nov 05 Release","Approve"]
[1084,"Amendments to delivery of Peer Comparison Reports","ELEXON","2004-09-01","The Panel has directed that ELEXON should improve peer group comparison mechanisms through a CP. This request has been prompted by their consideration of Modification Proposal P157, ‘Replacement of current Supplier Charges rules’.","CP1084 proposed that a new PARMS technique will be introduced to empower the PAB to publish Supplier Performance Assurance Serials and Standards (contained in BSCP 533 and/or 534) (“Peer Comparison Reports”) on the BSC Website. ","SVG: 44","CPC00457","SVG","Feb 05 Release","Approve"]
[1083,"Removal of Unmetered Supplies operational details from BSCP520 ‘Unmetered Supplies’","ELEXON","2004-08-24","Unmetered Supplies charging codes and switching regimes are currently contained in an appendix to BSCP520 which means that these are subject to the full change management process under BSCP40. Since the charging codes and switching regimes are updated regularly, the information contained in BSCP520 is continually out of date.","The documents currently titled ‘Appendices for BSC Procedure BSCP520’ and ‘BSCP520 – Appendix 4.7 – Switch Regime Annual Operating Hours by GSP Group’ should be combined, removed from the baseline statement and renamed as ‘Unmetered Supplies Operational Information’. Links to and associations with BSCP520 should be removed. A new process should be added to sections 2 and 3 (Workflow Diagrams and Interface and Timetable Information) of BSCP520 titled ‘Approval of New Switching Regimes and / or Charging Codes’ to provide the process of production and approval of new switching regimes and charging codes. ","SVG: 47","CPC00461","SVG","June 05 Release","Approve"]
[1082,"Replace reference to ‘EASL’ with ‘Teleswitch Agent’ in the SVA Data Catalogue ","ELEXON","2004-08-24","Data Flow D0277 ‘Teleswitch Contact Interval Data File’ contains references to EASL as the BSC Teleswitch Agent.  However, EASL ceased its activities at the end of 2003 and the Teleswitch Agent Contract was taken over by the Energy Networks Association (ENA).  Therefore references to EASL in the D0277 data flow should be removed.  To prevent this issue occurring again following a re-procurement of the Teleswitch Agent Contract, references to EASL should be replaced with generic references to the Teleswitch Agent.","Replace references to EASL in the D0277 flow in the SVA Catalogue with references to the Teleswitch Agent. For consistency it would be beneficial if the Data Transfer Catalogue is also changed to replace references to EASL. A DTC CP will therefore be raised to address these instances.","SVG: 48","CPC00466","SVG","June 05 Release","Approve"]
[1081,"EAC/AA Changes to Allow Manual Initiation of a Deemed Meter Advance Calculation","ELEXON","2004-08-24","The BSC Auditor’s Statement of Significant Matters for the year ended 30 September 2003 identified that many Non Half Hourly Data Collectors calculate Deemed Meter Advances (DMAs) manually, without using their certified EAC/AA calculation software. There may not be an adequate audit trail, making it impossible to confirm whether the calculation has been correctly performed; and the calculation may not be performed in accordance with the DMA equations in Annex S-2 of the BSC. From discussion with members of the Software Technical Advisory Group (STAG), it appears that manually-calculated DMA values are used in circumstances where a DMA is required, but the Data Collector’s system does not support the automatic initiation of the calculation.","The EAC/AA software should be enhanced to allow the user to initiate a DMA calculation manually (by typing details into a form). This new facility will supplement the current mechanism (in which a DMA calculation is initiated by NHHDC software, rather than directly by the user), and is intended for use in circumstances where the BSC requires a DMA, but the NHHDC system is not able to initiate the calculation.","SVG: 50","CPC00478","SVG","Nov 05 Release","Approve"]
[1080,"Enhancing Supplier and LDSO controls on Unmetered Supplies ","ELEXON","2004-08-23","The BSC Auditor has identified weaknesses in controls over the management of Non Half Hourly Estimated Annual Consumption (EAC) values used for Unmetered Supply (UMS) Metering System IDs (MSIDs) in Settlement.   \nIn the majority of cases the EAC values of UMS MSIDs had not been updated for a considerable period of time.  There is therefore a risk that EAC Values for these UMS MSIDs do not accurately reflect their consumption.","CP1080 proposes to add new process to BSCP 520 in section 3.","SVG: 47","CPC00464","SVG","Feb 05 Release","Approve"]
[1079,"Clarification of NHHDC obligations regarding UMSO-provided EACs","ELEXON","2004-08-23","The aim of this Change Proposal is to clarify the obligations on Non Half Hourly Data Collectors (NHHDCs) regarding Unmetered Supplies (UMS). One of the issues noted by the BSC Auditor for the Audit Period ending September 2003, was that many Estimated Annual Consumption (EAC) values created by the UMS Operator (UMSO) were not being used in Settlement, and when they were applied correctly by the Data Collectors a significant amount of additional energy began to enter Settlement","BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’: Introduce the concept of a UMSO; add a new footnote to 3.2.1.1 and add into section 3.4.1 “NHHDC Collects and Sends consumption / Generation Data”, in 3.4.1.1, as appropriate UMSO to send NHHDC UMS EAC via the D0052. “Where a D0052 Affirmation of Metering System Settlement Details, electronic or otherwise, is received from the UMSO, this value must be sent to the NHHDA on a D0019 Metering System EAC/AA Data for use in Settlement: add into section 3.4.1 “NHHDC Collects and Sends consumption / Generation Data”, in 3.4.1.1, as appropriate UMSO to send NHHDC UMS EAC via the D0052. PSL120 ‘Party Service Line for Non Half Hourly Data Collection: Section 1.4.1.4. The following changes should be made ‘The Non Half Hourly Data Collector shall record, in sufficient time to enable such Estimated Annual Consumption to be included in the Initial Volume Allocation Run for the relevant effective date to which such information relates, the Estimated Annual Consumption for Unmetered Supplies provided be the Unmetered Supplies Operator and any subsequent changes thereto as notified to the Non Half Hourly Data Collector by the Unmetered Supplies Operator. The Non Half Hourly Data Collector shall not replace the value of the Estimated Annual Consumption held for any Unmetered Supplies Equipment unless instructed to by the UMSO.’\n","SVG: 47","CPC00464","SVG","June 05 Release","Approve"]
[1078,"Application of VAT to Trading Charges.","ELEXON","2004-08-19","The Council of the European Union has directed an amendment to the rules on the place of supply of gas and electricity, for the purposes of turnover taxes.  This amendment takes effect from 1 January 2005 and directly affects the manner in which VAT is applied to Trading Charges.  The BSCCo is obligated to comply with all applicable taxation legislation.  This CP will give the BSCCo the tools to do this in an effective manner that mitigates risks and costs to Parties.","CP1078 will give the BSCCo the tools to do this in an effective manner that mitigates risks and costs to Parties. New obligations on Parties to inform BSCCo / the Funds Administration Agent (FAA) of their VAT status in relation to Trading Charges and to provide relevant overseas VAT information for billing and invoicing, are the subject of Modification P170 and do therefore not form part of this CP. This CP will ensure that the FAA systems and processes are capable of invoicing VAT at a rate other than the UK prevalent rate e.g. 0%. It will also ensure that the FAA can produce a monthly report containing relevant information to each Party who has confirmed that they are not liable for UK VAT. In addition this CP will ensure that appropriate forms exist that may be used by Parties to submit relevant information to the FAA.\n","ISG: 44","CPC00454","ISG","Feb 05 Release","Approve"]
[1077,"Review of BSCP 40  Emergency Fix Procedure","ELEXON","2004-08-10","BSCP 40 makes provision for “Emergency Fixes” - urgent changes to Configurable Items to correct serious operational problems with the Balancing and Settlement Arrangements for which there is no known workaround. The Emergency Fix procedure has never been used or reviewed since NETA Go-Live in March 01. A review of the Emergency Fix procedure was recommended by the Working Group as part of the Spring 2004 review of BSCP 40.","The Emergency Fix procedures in Section 3.8 of BSCP 40 should be streamlined to ensure that they mandate only the critical requirements for implementing a change in ‘emergency’ situations.","SVG: 46","CPC00458","SVG","BETTA Go-Live  - Apr 05","Approve"]
[1076,"Incorporation of the content of BSCP76 into BSCP40","ELEXON","2004-08-10","An entire BSCP (i.e. BSCP 76) is devoted to documenting the timing/recipients of communications relating to Modification Proposals and the submission form for a Modification Proposal. BSCP 76 and BSCP 40 both deal with change management and document requirements derived from Section F of the Code “Modification Procedures”.","CP1076 proposes to incorporate the contents of BSCP 76 into BSCP 40, and discontinue BSCP 76. ","SVG: 46","CPC00458","SVG","BETTA Go-Live  - Apr 05","Approve"]
[1075,"clarification of the different types of Stakeholder Input into the change management process","ELEXON","2004-08-10","During the lifecycle of a proposed change, BSCCo requests feedback from stakeholders on a number of occasions - through ‘Initial CP Impact Assessment’, through ‘BRS Impact assessment’ and through ‘Document Review’.  These activities are not clearly defined or distinguished from each other in the BSCP “Change Management”. Instead the generic term “Impact Assessment” is used interchangeably to describe the three distinct activities.","The nature and requirements of these three distinct activities should be clearly defined and differentiated from each other in BSCP 40. The following definitions are proposed:\n· “Initial CP Impact Assessment”:– stakeholder assessment of a CP in terms of the suitability of\nthe solution, the lead time required and an opinion as to whether or not the change should be\nmade.\n· “BRS Impact Assessment”:– stakeholder assessment of a release BRS in terms of the impact\non the recipients systems and processes, the cost and lead time of making the change.\n· “Document Review:” – stakeholder review of a document with red-lines to represent approved\nchanges (this takes place after the BRS has been approved if and only if full red-lined changes\nwere not made available in that BRS).\n","SVG: 46","CPC00458","SVG","BETTA Go-Live  - Apr 05","Approve"]
[1074,"Providing Greater structure and Certainty to the progression of Change Proposals","ELEXON","2004-08-10","At present, BSCP 40 “Change Management” does not require:                                                                                                                                                                                                     (1) Change Proposals (CPs) to be issued for industry impact assessment in a structured manner (i.e. in regular batches or according to a specified timetable); or \n(2) Decisions on CPs to be targeted for specific ISG/SVG meetings. \nAs a consequence, market participants do not have a clear understanding of when to expect to receive requests for impact assessments of CPs or of when to expect that a decision (i.e. approve/reject) will be taken with respect to the CP.","The following enhancements are proposed to BSCP 40 to add greater structure, certainty and\ntransparency to the progression of CPs:\n(1) Batching of CPs for Impact Assessment.\n(2) Specify Impact Assessment Timescale.\n(3) Indicative Decision Date.\n(4) Communication of Decisions.\n(5) Publication of Indicative CP Timetable.\n","SVG: 46","CPC00458","SVG","BETTA Go-Live  - Apr 05","Approve"]
[1073,"Introduction of a Housekeeping Process into BSCP40","ELEXON","2004-08-10","At present, there is only a single level of change management in BSCP 40. All proposed changes have to go through all the procedures of BSCP 40, regardless of the nature of the change. As a consequence, even ‘housekeeping’ type changes (e.g. typographical errors and erroneous cross-referencing) have to undergo the full change management procedure.","The following process should be introduced for housekeeping changes: the concept of a ‘Housekeeping Change Proposal (CP)’ should be introduced into and defined in BSCP 40; and specify in BSCP 40 that ‘Housekeeping CPs’ would not need to undergo impact assessment. The following definitions of ‘Housekeeping CP’ and ‘Housekeeping Change’ should be added to BSCP 40: Housekeeping CP: - a Change Proposal relating to a Code Subsidiary Document or an associated product which, if approved, would result in a House Keeping Change to one or more Configurable Items in the Baseline Statement. Housekeeping Change: - correction of manifest errors, minor errors and inconsistencies, including typographical errors (e.g. punctuation errors, spelling mistakes, incorrect font, incorrect capitalisation) and incorrect cross-referencing, and the removal of redundant text.\n  ","SVG: 46","CPC00458","SVG","BETTA Go-Live  - Apr 05","Approve"]
[1072,"Optimum Process for Inclusion and Distribution of Data Estimation Method in D0022 Flow","ELEXON","2004-08-10","Issue One: the Auditor has raised a compliance issue that HHDCs are expected to notify the Supplier and LDSO of the method of estimation used in the D0022 ‘Estimated Half Hourly Data Report’ as specified in BSCP502 section 4.2.3. Issue Two: an inconsistency exists in that BSCP502 section 4.2, paragraph 3, suggests the HHDC should notify the Supplier, LDSO and HHDA of the data estimation method via the Estimated Data Report, however within the main body of BSCP502, the Estimated Data Report is only sent to the Supplier and LDS O (sections 3.4.1.9 and 3.4.2.5). A further inconsistency exists with PSL130 (1.5.7.3) as this states the report goes to Supplier and LDSO only. The D0022 can currently only be received by the LDSO and Supplier.\nIssue Three: BSCP502 is unclear as to whether Agents are required to report both ‘A’ and ‘E’ flag data (section 4.2.3 as described above). This could be interpreted as either all estimation methods used (i.e. both ‘A’ and ‘E’ flag data) or just estimated data (i.e. ‘E’ flag data only).  ","CP1072 describes three closely-related issues, all relating to the requirement on HHDC (in Appendix 4.2 of BSCP502) to inform Suppliers and other participants of the method used for data estimation. Please note this CP has been raised by ELEXON on behalf of the Supplier Agent Forum.","SVG: 49","CPC00461","SVG","Nov 05 Release","Approve"]
[1071,"Amendment of SVAA and PARMS decimal place issue","ELEXON","2004-08-10","A discrepancy has been identified between the number of decimal places in certain PARMS data items provided by the SVAA for use in the Supplier Charges calculation and the requirements specified within the BSC.  In Annex S-1, section 3 (Charges), the Code states that percentage performance data used for calculating Chargeable MWh values for Serial SP08 should be rounded to 2 decimal places.  However, since 1998 this data has only ever been provided by SVAA to 1 decimal place.  As a result, while the actual calculations have been performed correctly, the discrepancy has led to some errors in the values charged and redistributed to Suppliers.","Modify the SVAA Pool Application and P99 PARMS software to generate and receive percentage data for Serial SP08 to 2 decimal places. Regenerate and reload SP08 reports for reporting periods from May 2004 onwards (the P99 Implementation Date) as necessary in order to ensure that all SCs calculated under P99 are compliant with the Code. ","SVG: 45",null,"SVG","−","Rejected"]
[1070,"Changes to CSDs for correct usage of D0002 Flow","ELEXON","2004-08-10","CP1063 has been drafted which proposed changes to the Metering System investigation process in BSCP502. CP1063 does not consider the usage of the D0002 data flow outside the Metering System Investigation Process, however it has been suggested that the use of the D0002 should be to confined in Code Subsidiary Documents to the Metering Fault Investigation Process.","There are 3 possible solutions. Respondents to the Impact Assessment will be requested to indicate their preferred solution:\nSolution 1: Make the use of the D0002 data flow in the Code Subsidiary Documents\nexclusive to the Metering System Investigation Process;                                                              Solution 2: Add an event indicator to the D0002;                                                                        Solution 3: Make no changes beyond those proposed by CP1063. \n","SVG: 51","CPC00466","SVG","−","Rejected"]
[1069,"Qualifying the Right of BSC Agents to Raise Change Proposals","E.ON","2004-07-19","BSCP 40 provides BSC Agents an unrestricted right to raise CPs. However, it is working practice that CPs raised by BSC Agents are only progressed at the discretion of BSCCo, with whom they are contracted to provide services required under the Code.","The solution proposes that BSCP 40 is amended such that BSC Agent raised CPs are only progressed at the discretion of BSCCo.\n","SVG: 46","CPC00453","SVG","BETTA Go-Live  - Apr 05","Approve"]
[1068,"Change to the process where the HHDC reports that no Proving Test has been initiated","ELEXON","2004-07-13","The process to be followed when the HHDC is aware that a proving test should have been carried out, but no proving test has been initiated is set out in BSCP502 and BSCP514. However, the Supplier is responsible for ensuring that its Agents comply with the BSC and BSC Procedures, therefore the Supplier should be responsible for liaising with the MOA regarding the failure to initiate a proving test to agree and confirm timescales for the proving test to be completed. The current obligation on BSCCo to carry out this activity undermines the effectiveness of the Supplier Hub and the Supplier’s ability to manage its Agents.","Make changes to BSCP502, 3.5.6.2 and appendix 4.6.4 and BSCP514, 5.5.6.2 and appendix 8.3.4 so that the Supplier is responsible for liaising with the MOA to agree and confirm the timescales in which to complete a proving test.\n","SVG: 47","CPC00461","SVG","Nov 05 Release","Approve"]
[1067,"Amendments to BSCP601 following operational review.","ELEXON","2004-07-13","A review of BSCP601 was conducted by a review group who convened three times in consideration of how improvements could be made to the document and the processes it details.  It was agreed that any processes to be established should not be retrospective.  ","Cp1067 addresses a number of defects which were identified in the current provisions of BSCP601.","SVG: 46","CPC00463","SVG","Feb 05 Release","Approve"]
[1066,"Changes to SVAA Service Lines as part of the SVAO Re-procurement","ELEXON","2004-07-13","In order to meet its obligations under the BSC, ELEXON manages contracts with service providers for the development, maintenance and operation of Supplier Volume Allocation Hardware and Software systems. Re-procurement of the development and maintenance of these systems was completed in December 2003 with the award of a 3-year contract for the Supplier Volume Allocation Software Service (SVASS). However, the contract for the operation of the SVAA systems expires in March 2005, necessitating a re-procurement of this service, which shall be known as Supplier Volume Allocation Operations (SVAO).","SSLs 300, 310, 330, and 360 should be altered as shown in the redlined attachments to accurately reflect the current requirements of the SVAO service. In addition to other minor changes to SSL370 ‘Miscellaneous Services’, the Software Maintenance Service section in should be removed. These requirements are to be transferred to the SVASS contract. SSL340 ‘Implementation Support’ is no longer relevant to the SVAO service and so should be removed\nfrom the baseline.\n\n","SVG: 44","CPC00452","SVG","BETTA Go-Live  - Apr 05","Approve"]
[1065,"Amendments to Code of Practice 8 ","ELEXON","2004-07-09","Section 2(1) of Schedule 7 of the Electricity Act 1989 (hereafter referred to as “the Schedule”) provides that no meter shall be used for ascertaining the quantity of electricity supplied by an electricity supplier to a customer unless the meter is both of an approved pattern and is certified.  These requirements are more commonly referred to as ‘type testing’ and ‘certification’ respectively.","Sections 4.2.3 and 5.2.3 of CoP8 should both be modified through the insertion of the following sentence: ‘Where a Meter is exempt, in accordance with Section 2 of Schedule 7 of the Electricity Act 1989, from certification in accordance with that Act , it shall undergo initial verification to a standard equivalent to that which would have been required by the Electricity Act had the Meter not been so exempt ’.","SVG: 47","CPC00461","SVG","Nov 05 Release","Approve"]
[1064,"Flows to be sent on a Non-Half Hourly change of Energisation Status","ELEXON","2004-06-28","It has been identified that during the drafting of BSCP514 the instances of sending the D0010 alongside the D0139 in the Energisation and de-Energisation processes in the NHH market were inadvertently removed.  When consequential changes for BSCP514 were applied to BSCP504, the requirement was also removed from BSCP504.  The sending of the D0010 in parallel to the D0139 in the NHH market should not have been removed and should therefore be reinstated.","The following changes are required to BSCP504 and BSCP514:\nBSCP504, 3.3.3.1 ‘Energise a SVA Metering system’ and 3.3.4.1 ‘De-energise a SVA Metering\nSystem’ – Add the D0010 ‘Meter Readings’ to the Information required box.\nBSCP514, 6.3.1.4 ‘Energise a SVA Metering system’ and 6.3.2.4 ‘De-energise a SVA Metering\nSystem’ – Add the D0010 ‘Meter Readings’ to the Information required box.\nThese changes will mean that the D0010 ‘Meter Readings’ can be sent alongside the D0139 ‘Confirmation or Rejection of Energisation Status Change’ in the NHH market.\n\n","SVG: 44","CPC00452","SVG","Feb 05 Release","Approve"]
[1063,"Changes to the Investigate Inconsistencies processes in BSCP502, BSCP504 and BSCP514","ELEXON","2004-06-21","BSCP502, BSCP504 and BSCP514, all have variations on the process for investigating inconsistencies. ","CP1063 proposes that changes are made to make the above BSCPs consistent in regard to the process for investigating inconsistencies.","SVG: 51","CPC00449/CPC00496/CPC00510/CPC00553","SVG","−","Rejected"]
[1062,"Clarification of the use of Defined Terms within BSCP 27","ELEXON","2004-06-21","In the final version of the new BSCP 27 the Defined Term \"Compliance\" and related words have been utilised liberally, when in some cases their usage suggests no reference to the Definition in paragraph 1.20.2.","To carry out a review of the usage of these terms in BSCP 27 to determine which instances are Defined Terms within the BSC and which are not, and amend accordingly; also, to review and if necessary amend the definitions of \"Compliance\" and \"Non-Compliance\". ","SVG: 51","CPC00465/CPC00496","SVG","Nov 05 Release","Approve"]
[1061,"Rationalisation of Interface Documents","ELEXON","2004-06-17","The Balancing and Settlement Code (the ‘Code’) currently specifies the requirements for documenting interfaces between Parties and central systems. ELEXON has reviewed the existing set of documents which discharge these obligations and identified several opportunities for improved efficiency in this area.","The Code requirements for documenting interfaces between Parties and central systems would be unchanged. The NDFC would continue to contain all files for communication between BSC Agents and Parties defined as a consequence of NETA by any of the central service providers other than the SVAA. Information within the NDFC that is available in the Logica IDD Part 1 would be removed and replaced with an incorporative cross reference. For those communications which are not within the scope of the Logica IDD Part 1 no changes would be made (i.e. detailed flow information would remain). The Reporting Catalogue would be retained as a stand alone document. However information within the Reporting Catalogue available in the Logica IDD Part 1 would be removed and replaced with an incorporative cross reference. As a consequence of the inclusion of incorporative cross references in the NDFC and the Reporting Catalogue, relevant sections of the IDD would effectively become part of the NDFC/Reporting Catalogue (NB: only the particular sections of the IDD that are directly referred to would gain this status i.e. the detailed flow information). As a result of being included in a Code Subsidiary Document, the relevant sections of the IDD would be required to comply with Section 3.1 of the Code. The impact of this is minimal as the IDD is currently a configurable item and subject to the same change management procedure as a Code Subsidiary Document. ","SVG: 48","CPC00449","SVG","Jun 05 Release","Approve"]
[1060,"Providing the Registrant with visibility of their Line Loss Factors (LLF) prior to approval    ","ELEXON","2004-06-08","BSCP28 details the process by which CVA LLF are approved and communicated between LDSO, CDCA, BSCCo and the BSC Panel. The procedure makes no reference to the registrant of a metering system receiving notification of the LLF that will be allocated to that metering system for the forthcoming year. We believe this to be a defect within the current procedure as the LLF is a variable that must be known and factored into the volumes for a contract notification. If the LLF is not notified to the Registrant and specifically if there is a change in the parameter from the previous year this could impact on the imbalance position of the Registrant. Visibility of the LLF at an early stage will also allow Registrants where appropriate to challenge the LDSO on the factor being provided for use in Settlements.","British Gas Trading (BGT) believes the proposed solution needs to incorporate an amendment to BSCP28 to the F28/01 form and the Interface & Timetable information. BSCP28 details the process for submission and approval of LLF. The F28/01 form needs to include a section for the Registrant to sign and return to the LDSO confirming that the Registrant has seen the value. This information would then be provided to the ISG along with the proposed value for the BM Unit. The Interface and Timetable information would also need to be amended to reflect the additional steps in the process. ","ISG: 50","CPC00446/CPC00470","ISG","Jun 05 Release","Approve"]
[1059,"Upgrade of NHHDA and EAC/AA under Oracle Forms 9i","ELEXON","2004-06-08","The current versions of NHHDA and EAC/AA operate under Oracle 9i for the server application and Oracle Forms 6i for the client. Oracle Corporation has announced the end of Error Correction Support (ECS) for Oracle Forms 6i for all platforms as of 31 December 2004.  Extended Support (ES) will be provided to all customers until 31 December 2007 if the customer has a current support contract although this will incur an additional cost.  A migration path has been announced which requires the upgrade from Forms 6i to Forms 9i where Forms 9i is fully supported under ECS","Cp1059 proposed to update the NHHDA and EAC/AA software applications to operate using Oracle Forms 9i.\n",{"$nulls":3},"—","Withdrawn"]
[1058,"Update to Profile Administrator Service Description to describe correctly the process for splitting Base and Switched Load","ELEXON","2004-06-07","Paragraphs 4.4.3 to 4.4.8 of the Profile Administrator Service Description (PrA SD) describe the process by which the Profile Administrator splits the stratum-weighted demand values for Profile Classes 2 and 4 into base and switched load. However, these paragraphs do not correctly describe the handling of E7 customers with switching times other than 00:30 - 07:30. Paragraph 4.4.4 of the Service Description implies that the data for individual customers should be manipulated to shift their switched load into the standard 00:30 - 07:30 window. In fact the Profile Administrator has never done this, and it’s unclear how it could be done","When the PrA SD was originally written, it was intended to describe the existing PrA processes. It’s therefore proposed to bring the Service Description in line with the existing PrA practice.\nMaking this change will further complicate the already complex algebra in sections 4.4.3 to 4.4.8 of the PrA SD. It is therefore proposed to move this part of the Service Description into an Appendix.","SVG: 48","CPC00466","SVG","Nov 05 Release","Approve"]
[1057,"Request for Additional Market Indicator Data","ELEXON","2004-05-24","ELEXON receives a number of reports from SVAA detailing the energy volumes submitted into Settlement. Recent work in relation to Trading Disputes, market analysis and Modification P157 ‘Replacement of Current Supplier Charges Rules’ has shown that there is a lack of visibility within ELEXON of the HH/NHH split by BM Unit by Settlement Period; the current set of reports only provide data on a Settlement Day basis and are not sufficient for detailed analysis. Other work has also highlighted this lack of visibility.","SVAA to produce two new weekly flows to complement the current P0049 Energy Settlement Mix Market Indicator flow.\nFlow A: to contain fields for BM Unit, Settlement Date, Settlement Run Type, GSP Group, Supplier ID, Settlement Period, Correctable energy (post correction), and Uncorrectable energy. \nFlow B: to contain fields for BM Unit, Settlement Date, Settlement Run Type, GSP Group, Supplier ID, CCC, MSID Count (for HH MSIDs) and Uncorrected energy. ","SVG: 44","−","SVG","Jun 05 Release","Approve"]
[1056,"Inclusion of an additional Authorisation Category for Entry Processes","ELEXON","2004-05-24","BSCP511 describes the processes by which Parties and Party Agents undergo Entry Process testing prior to operation in the SVA market. As the testing is often lengthy and involves a significant amount of resources on the part of applicants, BSCP511 and BSCP512 both require Entry Process requests to be signed by a Main Board Director of the applicant company. It has been identified that, on occasions, applicants requiring testing have had difficulty in obtaining the necessary director-level authorisation, causing delays in the Entry Process timetable and potentially leaving the applicant in a state of non-compliance. Furthermore, in order to validate Entry Process requests, the Entry Process Co-ordinator is required to look up and maintain a suitable list of director-level personnel for each applicant company.","CP1056 is suggested that a new Authorisation Category be created in BSCP38 ‘Authorisations’ for use in Entry Processes, both by new participants entering the market or by existing participants requesting additional testing.\n","ISG: 42","CPC00438 ","ISG","Feb 05 Release","Approve"]
[1055,"Withdrawal of BSCP506 ‘Calculation and Population of Initial EACs for Non-Half Hourly Metering Systems Registered in SMRS’","ELEXON","2004-05-13","The purpose of BSCP506 was to calculate and populate the MSID specific EAC values, GSP Group Profile Class Average EAC and GSP Group Profile Class average EAC and associated Average Fraction of Yearly Consumption Values for NHH SVA Metering Systems within a GSP Group for the start up of the 1998 Trading Arrangements. This BSCP is no longer in operational use. It is not required for the BETTA since initial EACs are already in use in Scotland for the two new Scottish GSP Groups.","Withdraw BSCP506 ‘Calculation and Population of Initial EACs for Non-Half Hourly Metering Systems Registered in SMRS’ BSCP506 is referenced in BSCP504 ‘Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ in section 1.1: ‘For the purposes of initial EAC population within a GSP Group, the EACs used shall be based on BSCP506 - Calculation and Population of Initial EACs for Non-Half Hourly SVA Metering Systems Registered in SMRS.’ This sentence should be removed from BSCP504 as it is no longer relevant. BSCP506 is also referenced in BSCP535 ‘Technical Assurance’, section 1.6 ‘Associated BSC Procedures’. The reference to BSCP506 should be removed from here.\n","SVG: 44","CPC00439","SVG","Feb 05 Release","Approve"]
[1054,"Inaccurate Interface Timetables in BSCP06 3.1 and 3.2","ELEXON","2004-04-21","The interface timetables in sections 3.1 and 3.2 of BSCP06 (Notification and Sealing of Metering Equipment for Central Volume Allocation) are not accurate in relation to the use of the BSCP06/4.1 form. Appendix 4.1 explains that the BSCP06/4.1 ‘Notification of Work On Central Volume Allocation Metering Equipment’ form is used by MOAs and/or Registrants to notify the CDCA of any intended work on a Metering System, and to advise the CDCA once the work has been completed.  The form is also used by the CDCA to give agreement to MOAs and Registrants to carry out the work, and to confirm that seals have been reapplied following completion of work. However, the corresponding sections of the interface timetables do not describe the use of the different parts of the BSCP06/4.1 form in detail; as a result, there is confusion amongst participants about when to complete and send the form.","Amend sections 3.1 and 3.2 of BSCP06 to state which parts of the BSCP06/4.1 form are to be used in each step, and in particular highlight the requirement for MOAs and/or Registrants to confirm completion of work to the CDCA and thus ensure seals are re-applied as soon as possible (see attachment). In addition, following approval of this CP and pending its implementation, it is recommended that ELEXON issue a guidance note clarifying the sealing process and the use of the BSCP06/4.1 form. ","ISG: 44                 SVG: 40","CPC00438 ","ISG/SVG","Feb 05 Release","Approve"]
[1053,"Upgrade of the SVAA software application for forms 9i",null,"2004-04-20","The current version of SVAA operates under Oracle 9i for the server application and Oracle Forms 6i for the client. Oracle Corporation has announced the end of Error Correction Support (ECS) for Oracle Forms 6i for all platforms as of 31 December 2004.  Extended Support (ES) will be provided to all customers until 31 December 2007 if the customer has a current support contract although this will incur an additional cost. A migration path has been announced which requires the upgrade from Forms 6i to Forms 9i where Forms 9i is fully supported under ECS.","Upgrade the SVAA software application to operate using Oracle Forms 9i. ",{"$nulls":3},"—","Withdrawn"]
[1052,"Upgrade of NHHDA and EAC/AA software applications to operate under UNIX 5.1B","ELEXON","2004-04-20","The current versions of NHHDA and EAC/AA both operate under UNIX 5.1A, which is a prior version to the latest supported, UNIX 5.1B. Participants who receive NHHDA and EAC/AA have generally migrated to UNIX 5.1B but need to retain a UNIX 5.1A environment to accommodate NHHDA and EAC/AA. SVAA has been upgraded to operate under UNIX 5.1B.  Currently support and development is required to be supplied for two different operating system versions to accommodate SVAA as well as NHHDA and EAC/AA.","Upgrade NHHDA and EAC/AA software applications to operate using UNIX 5.1B.","SVG: 40","CPC00428","SVG","Nov 04 Release","Approve"]
[1051,"Review of Metering Code of Practice 2","ELEXON","2004-04-14","Metering CoP2 version 1.05 was originally implemented as part of the “1998 Programme” and subsequently “Re-badged” for the implementation of the Balancing and Settlement Code at “NETA Go Live”. During this period a number of reviews had been carried out which resulted in a draft version being created, but not implemented. Subsequently, metering technology has moved forward, leaving both the operational and draft versions behind and out of date, for example passwords / D268's / TAA policing etc.","A review is required to consolidate the operational version 1.05 and the draft version, after which a further review is required (by a Working Group) to bring CoP2 up to date with current metering technology and working practises.","ISG: 55                             ","CPC00439/CPC00503/CPC00528","ISG","Feb 06 Release","Approve"]
[1050,"CDCA MAR Discrepancy Values",null,"2004-04-08","BSCP06 states \"the nominal tolerance value for acceptable MAR shall be not greater than ±0.1%, and subject to review by the BSCCo.\"  There appears to be an inconsistency in the industry documentation between the levels at which discrepancies should be investigated.  Currently, in line with the Service Description, the CDCA is obliged to investigate any discrepancies greater than +/-0.05%. Based on the CDCA’s experience of investigating MAR failures, it is our opinion that the tolerance that is currently used (0.05%) is too tight, and results in wasted effort in investigating failures where obvious discrepancies cannot be identified, and where, in conjunction with the Registrant and/or MOA, these can be or are rarely resolved. This effort could be better focussed on resolving the significant issues.","It has been agreed NETA Central Service Provider and BSCCo that the tolerance limit should be set to +/-0.1% for CVA, as this would then align with SVA and also the current requirements in Scotland. ",{"$nulls":3},"—","Withdrawn"]
[1049,"BSCP to enable the obligations on a LDSO and TSO","ELEXON","2004-04-08","Section K of the Code places registration obligations on Licensed Distribution System Operators (LDSOs) and the Transmission System Operator as pertains to System Connection Points. Currently there is no formal process through which all these obligations can be achieved.","It is proposed that a new BSCP, BSCP25 be drafted in order to enable these obligations to be accomplished in a consistent, timely and formal way and to encompass all the CVA registration obligations of System Operators in one document. Obligations as in Sections K and R of the Code:                                                                                                                                                                                                                                                                                                       • Transmission System Boundary Point registration and de-registration                                                                                                                                                                            • Grid Supply Point (GSP) registration and de-registration                                                                                                                                                                                                • GSP Group registration \n• Distribution System Connection Point registration and de-registration","ISG: 44","CPC00442","ISG","Feb 05 Release","Approve"]
[1048,"Requirement to request Metering System history via the D0170 upon a Change of HHDC","ELEXON","2004-04-05","There is a requirement for HHDCs to perform validation techniques and data comparisons using physical and final meter reads under BSCP502 section 4.0. Upon a change of HHDC, the requirement to request meter history, via the D0170, is not mandatory.\nIf historical data is not requested the incoming HHDC will not be able to make adequate comparisons of data and perform MARs on Metering Systems where this is a requirement.",null,"SVG: 43","CPC00430","SVG","Feb 05 Release","Approve"]
[1047,"Warning message to highlight when no GSP Groups are selected for a Non Half-Hourly Data Aggregation run.","ELEXON","2004-03-16","This issue occurs when an aggregation run is performed and the System Parameter is not set to ‘Aggregate for all GSP Groups’.  If no GSP Groups are selected, the status on the Schedule Run Aggregation screen is erroneously defined as successful (s) on the screen.   An error log is also produced for this run with the message ‘No GSP groups retrieved for run nnnn’ and no Supplier Purchase Matrix (SPM) is produced. This issue also occurs when the System Parameter is set to ‘Aggregate for all GSP Groups’ and the User does not enter a GSP Group for a Dispute Aggregation run.  This issue does not occur for all other run types for which the System Parameter is set to ‘Aggregate for all GSP Groups’.","It is proposed that when the System Parameter is not set to ‘Aggregate for all GSP Groups’, that an early warning message is displayed to highlight that no GSP Group has been named. This message could be displayed either at the time of data entry or when the data aggregation run is set to a status of released. It is also proposed that when the System Parameter is set to ‘Aggregate for all GSP Groups’ and no GSP Groups are selected for a Dispute Aggregation Run, that an SPM is produced for all GSP Groups held.\n","SVG: 47","CPC00438 ","SVG","June 05 Release","Approve"]
[1046,"Inconsistency between the BSC and BSCP535","ELEXON","2004-03-10","There is an inconsistency, which has been identified during the February 2004 Panel meeting (Panel 72) between the Balancing and Settlement Code (BSC) and BSCP535 ‘Technical Assurance’. Currently the BSC states in section J1.4.2(e) that the Performance Assurance Board (PAB) is responsible for “the carrying out of those functions duties and responsibilities accorded to it in... BSCP535”. However, in BSCP535 the majority of functions have been assigned to BSCCo, in particular the with regards to  publication of the results of Technical Assurance (TA) checks conducted on a Supplier Agent to the Supplier Agent’s Associated Suppliers. BSCP535 currently implies but does not explicitly state that the PAB can delegate its authority to publish the results of a TA check to associated Suppliers to BSCCo.","BSCP535 should have the following Sections amended to read as: Section 1.2 ‘main users of the Procedure’ should have included as a main user of the Procedure the phrase Delegated Authority; Section 1.3.2 ‘Technical Assurance Checks’ should be re-worded from “The TAA conducts the check and records the results on the Check Results form (F535/06). The TAA then provides the Market Participant in question with a copy of the results.” To ”PAB shall conduct the check and\nrecord the results on the Check Results form (F535/06). PAB may delegate such function as it sees fit including without limitation the notification and/or publication of such results”; Section 1.4 ‘Responsibilities’ should be re-worded from “BSCCo will be responsible for carrying out the role of the Technical Assurance Agent as defined in this BSC Procedure”. To “The PAB as part of determining the annual Technical Assurance (TA) Scope of Work will delegate the performance of each check and each of the functions associated with the performance of each check to a Delegated Authority”; Section 1.9 ‘Definitions’ should be amended to have an entry for Delegated Authority to read “Delegated Authority – a function carried out by a body approved by PAB”; Section 4.4. BSCP535 will also need to be amended to change all references to the Technical Assurance Agent and TAA to the phrase “Delegated Authority” or PAB as appropriate.","SVG: 43","CPC00420","SVG","Feb 05 Release","Approve"]
[1045,"Data requirement for sending Meter System history on request via the D0170 ‘Request for Metering System Related Details’ upon a Change of Half Hour Data Collector (HHDC)","ELEXON","2004-03-08","BSCP502 states that if required, a new HHDC Agent may request from the old HHDC Agent up to 14 months of historic Half Hourly Metered Data, where available, including the final Meter reading and the last physical Meter register reading taken on site, for estimation purposes.  The old HHDC Agent is required to send this data within five working days of the request using D0036 and D0010 dataflows.","Amend the wording of the relevant sections of BSCP502 so that the D0170 request is always for 14 months of data, and that 14 months of data will be sent unless it is not available (i.e. the Metering System is less than 14 months old or the old HHDC does not have this much data in their system. This should be done by amending the ‘ACTION’ columns of 3.2.4.7, 3.2.4.8, 3.2.7.7 and 3.2.7.8.","SVG: 43","CPC00430","SVG","Feb 05 Release","Approve"]
[1044,"Clarification of data requirements in the transfer of Metering System Related Details during a Change of Half Hourly Data Collector (HHDC) process","ELEXON","2004-03-08","During the change of HHDC process, when requested, the old HHDC will transfer Half Hourly Metered Data and send the last physical Meter reading and the final Meter reading to the new HHDC. With regard to the Meter readings provided on Metering Systems with electronic cumulative reading available during the remote collection process, there some ambiguity as to whether these should form part of the Meter history sent.","BSCP502 requires a footnote added to section 3.2.4.8 and 3.2.7.8 (references taken from version 9.0 of BSCP502) that details the requirement to only send the final Meter reading, which may constitute the last cumulative total reading or manual reading made by the HHDC and the last physical Meter register reading made. It should also state clearly that previous cumulative total reads are not required as part of this data transfer.","SVG: 45","CPC00430/CPC00453","SVG","Feb 05 Release","Approve"]
[1043,"Reporting Meter Advance Reconciliation (MAR) overdue status by Half Hour Data Collectors (HHDCs) in their monthly reporting","ELEXON","2004-03-08","BSCP502 section 4.7.1 requires a D0008 dataflow to be produced by the HHDC Agent and sent to the Supplier (and LDSO if requested) on a monthly basis. This will include:                                                                                                                                                • MAR confirmation;                                                                                                                                                                                                                                                     • MAR failure; and                                                                                                                                                                                                                                                        • MAR overdue, for all Metering Systems for which a Meter Advance Reconciliation (‘MAR’) has been, or should have been, carried out during the preceding month. Currently, the flags for mandatory field J0041 ‘MAR Status’ data item in the D0008 are:                                                                                                                                                      • A = Automatically passed                                                                                                                                                                                                                                          • F = Attempted but failed for some reason                                                                                                                                                                                                                     • M = Manually passed. \nThe Overdue status code was removed from the J0041 data item in version 3.1 as a result of CR1187 in July 1997.","There are two solutions proposed:\n1. Re-introduce the Overdue MAR status as a valid code for reporting in the J0041 data item for use in the D0008 data flow. (i.e. Add ‘O = Overdue’ to the Valid Set of the J0041)\n2. Create a new manual ‘P’ flow that allows reporting of all three statuses to be sent to Supplier and LDSO. This new data flow may also be sent to BSCCo for additional measure of performance at market level. The structure of the new P flow would mirror that of the D0008 data flow (including ‘O=Overdue’ as part of the valid set). Solution 1 will require a change to the SVA Data Catalogue and the Data Transfer Catalogue (DTC).\nSolution 2 would only require a change to the SVA Data Catalogue. Views will be sought as part of the Impact Assessment of this change to the preferred solution and a DTC Change Proposal will be raised if necessary.\n","SVG: 39","CPC00426","SVG","Feb 05 Release","Approve"]
[1042,"Clarification on the Meter Advance Reconciliation tolerance calculation","ELEXON","2004-03-08","BSCP502 section 4.7 requires that the HHDC Agent performs the Meter Advance Reconciliation to ensure that the Half Hourly data taken into Settlements sums to the meter advance read on site from the prime registers for the same interval “within a tolerance of 0.1%”. It has been observed previously during discussions with two of the HHDC Agents that they have applied a different interpretation of the tolerance indicated in BSCP502. The current wording of BSCP502 is sufficiently ambiguous to allow either interpretation.","The intention of the tolerance check is to get most accurate picture of the variation between the sum of HH period energy volumes and the Meter Advance energy volume over the same time interval. In keeping with this, use of the Meter Advance as the denominator in the required equation is the most accurate method and was always the intended way of calculating the discrepancy for performing a tolerance check. Therefore, an equation should be added at the end of section 4.7.1 i) of BSCP502 to describe how the discrepancy should be calculated when performing tolerance checks.","SVG: 39","CPC00426","SVG","Feb 05 Release","Approve"]
[1041,"Additional Changes to BSCP509 ‘Changes to Market Domain Data’ following implementation of the Operational Review","ELEXON","2004-03-01","CP923 ‘Operational Review of BSCP509 ‘Changes to Market Domain Data'’ was implemented on 27 November 2003. Following the implementation of CP923, the Supplier Volume Allocation Agent (SVAA) has identified two issues with BSCP509.","Make the following changes to BSCP509: the word ‘publication’ should be replaced by ‘Go-Live Date’ and amend the workflow diagram in section 2.4 to show that the MDD circular sent in step 3.4.5 is also sent to the SVAA.","SVG: 39","CPC00429","SVG","Feb 05 Release","Approve"]
[1040,"Improvements to BSCP31","ELEXON","2004-02-16","A number of inconsistencies and ambiguities are present within Balancing and Settlement Code Procedure (BSCP) 31, ‘Registration of Trading Units’.","Proposed Issue 1 resolution: Modify BSCP31/4.5 to include:\n· A field for Effective from date for the Trading Unit\n· A field for Effective from date for the GSP Group (where appropriate)\n· A sentence stating that ‘Pursuant to Section K of the Balancing and Settlement Code, ‘Classification and Registration of Metering Systems and BM Units’, the Lead Party of each BM Unit shall forthwith notify the BSCCo if there is a change in the circumstances of that BM Unit that may affect its registration within a Trading Unit’.\nProposed Issue 2 resolution: The ‘To’ box for Reference 3.1.11 should be modified to include ‘BSCCo’.                                                                                                                                          Proposed Issue 3 resolution: Modify the sub-section of 4.1 that details requirements for Exempt Export BM Units such that ‘Trading Unit Identifier’ is modified to ‘Trading Unit Name'.","ISG: 44","CPC00422","ISG","Feb 05 Release","Approve"]
[1039,"Use of D0052 flow on change of Supplier and change of NHHDC","ELEXON","2004-02-02","On change of Supplier or Non Half Hourly Data Collector (NHHDC), an ‘Affirmation of Metering System Settlement Details’ (D0052) flow can be requested by the NHHDC (BSCP504 3.2.6.2 footnote 30 and BSCP 3.2.3.8 footnote 24 respectively). This is intended primarily for the situation where the new NHHDC has not received historical EAC/AA data from the old NHHDC. Some Suppliers are understood to send a D0052 automatically on every change of Supplier or change of DC. This can cause a number of problems for the NHHDC.","CP1039 proposes to amend BSCP504. ","SVG: 44","CPC00417","SVG","June 05 Release","Approve"]
[1038,"Optional Data Items in D0052 Flow","ELEXON","2004-02-02","All data items on the ‘Affirmation of Metering System Settlement Details (D0052) flow are mandatory. This can result in D0052 flows being rejected due to inconsistencies in items other than those which the Supplier is intending to change. For example, on change of Standard Settlement Configuration (SSC) or Profile Class, a D0052 may be rejected because of validation of the Effective From Settlement Date of the GSP Group or the Measurement Class. In particular, Suppliers may experience difficulties in populating the Effective From Settlement Date {MSGGDC} (J0093). Although the ‘Confirmation of the Registration of a Metering Point (D0217) flow includes a Metering System’s GSP Group, it does not include the effective date of when the Metering System was registered in the GSP Group. This presents Suppliers with difficulties in populating the D0052 flow and may cause the flow to be rejected.","Amend the definition of the D0052 flow such that data items are optional unless required in the business context in which the D0052 is being sent.","SVG: 44","CPC00417","SVG","−","Rejected"]
[1037,"Timing and Validation of D0052 flow","ELEXON","2004-02-02","BSCP504 3.2.1.3 footnote 17 states that “if any discrepancies identified between the MTD provided by the MOA and the SVA MS data received from the Supplier, the NHHDC shall inform the Supplier. The Supplier will ensure that any such anomalies are resolved”. There is no equivalent requirement for other processes, where a both a D0150 and D0052 are sent, such as change of Standard Settlement Configuration (SSC).","A requirement to cross-validate the SSC on the D0052 and D0150 flows will be added to all relevant processes within BSCP504. \n","SVG: 44","CPC00417CPC00442","SVG","June 05 Release","Approve"]
[1036,"Rejection Flow for D0052","ELEXON","2004-02-02","Some Suppliers and NHHDCs are operating workarounds (such as the use of email and fax) to notify failed D0052 flows, but these workarounds can be inefficient and manually intensive. Other Suppliers are unaware how many D0052 flows are being rejected and are unable to take corrective action, where required.","Introduce an obligation on NHHDCs to notify Suppliers of rejected D0052s and:-\nOption 1 – introduce a new rejection flow for this purpose, or:\nOption 2 – use the existing ‘Request for Metering System Related Details (D0170)’ flow to request a revised D0052.","SVG: 44","CPC00417CPC00442","SVG","June 05 Release","Approve"]
[1035,"Consumption not 'E' flagged following proving test failure","ELEXON","2004-02-02","BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’, section 4.6.6 ‘Failed Proving Test’ requires that if a proving test has failed, collected Metered Data will be flagged as ‘E’ (estimated) until a successful proving test is completed.  Meanwhile, BSCP502 section 4.6.7 ‘Non-Completion of Proving Test’ allows Half Hourly Data Collectors (HHDCs) to treat data from a Metering System for which a proving test is outstanding as ‘A’ (Actual) flagged for the submission of data into Settlement.  In situations where proving tests are delayed this can lead to a large amount of unproven data being entered into Settlement, which then becomes indistinguishable from proven data that is also ‘A’ flagged.","Option 1: Section 4.6.7 of BSCP502 should be amended to specify that Metered Data should be ‘E’ flagged until a successful proving test has been carried out. option 2: Section 4.6.7 of BSCP502 should be amended to specify that Metered Data should be ‘E’ flagged until a\nsuccessful proving test has been carried out ",null,"CPC00426",null,"—","Withdrawn"]
[1034,"Timing of D0170 data request flows","ELEXON","2004-02-02","BSCP502 v6.0 states in sections 3.2.4 and 3.2.7 that if required, a new HHDC Agent may request from the old HHDC Agent (on a D0170 ‘Request for Metering System Related details’ flow) up to 14 months of historic Half Hourly Metered Data, where available, including the final Meter reading and the last physical Meter register reading taken on site, for estimation purposes.  The old HHDC Agent is required send this data within five working days of the request, using D0036 and D0010 flows.","In order to ensure that the final Meter reading is available for use by the new HHDC, BSCP502 sections 3.2.4 and 3.2.7 should specify in the ‘WHEN’ column of each procedure (in version 6.0 steps 3.2.4.8 and 3.2.7.8), that the new HHDC does not send the D0170 prior to the HHDC Effective From Date on their D0155 ‘Notification of Meter Operator or Data Collector Appointment and Terms’ flow received from their associated Supplier. ","SVG: 43","CPC00430","SVG","Feb 05 Release","Approve"]
[1033,"Discrepancy between D0269 and D0270 flows","ELEXON","2004-02-02","The D0269 flow is the ‘Market Domain Data Complete Set’, whereas the D00270 is the ‘Market Domain Data Incremental Set’. Participants in receipt of MDD should be able to load a D0270 flow on top of a D0269 flow and still have the complete set of MDD. Because the D0270 only contains the incremental updates rather than the entire data set, the processing time of loading a D0270 rather than a D0269 is improved.  There is a discrepancy between the D0269 and D0270 files, specifically in the MTC TPR Countfield. In the D0269 file the field is populated however in the D0270 file the field remains unpopulated. The fact that the flows are slightly different means that loading a D0270 flow on top of a D0269 flow will not have exactly the same effect as loading a new D0269.","The MDDM system should be enhanced to populate the ‘MTC TPR Count’ field on the D0270 as it is on the D0269. ","SVG: 45","CPC00429/CPC00457","SVG","June 05 Release","Approve"]
[1032,"Review, revision and clarification of BSCP11 “Volume Allocation and Settlement Run Queries”","ELEXON","2004-01-20","Section W of the Code sets out the arrangements for the resolution of Trading Queries and Trading Disputes for the operation of the Trading Disputes Committee (TDC).  BSCP11 describes the processes and work undertaken by ELEXON to progress Trading Queries through a query resolution process and for the duration of their life as Trading Disputes. During the assessment of Modification P131, and the walkthrough of BSCP11 during the implementation of P107, it was identified that processes and timetables within BSCP11 were, in some cases, unclear.  In addition, it did not always accurately represent working practice. Therefore, it would be useful to review and update the document as many of the changes are outside the scope of P131.","CP1032 proposed a review of the processes contained in BSCP11.","TDC: ","−","TDC","Nov 04 Release","Approve"]
[1031,"Entry Process Testing  -  Clarification for Party Agents","ELEXON","2004-01-05","Currently there is no way for customers to know which Suppliers have satisfied these criteria.","This CP proposes that the BSC should be interpreted to take into consideration the Party Agents’ business operation and commercial arrangements when carrying out Entry Process Testing and only those aspects appropriate to the Agents’ activities should be tested. It should be noted that a safeguard already exists whereby ELEXON can monitor Agents’ compliance through the Supplier Hub process. Should Agents with exemptions wish to extend the scope of their activities, then further application for Entry Process Testing will be necessary. ","SVG: 40","−","SVG","−","Rejected"]
[1030,"Publishing of the details of Suppliers who meet criteria","ELEXON","2004-01-05","The 30WD minimum period for change of ownership of BM Units and associated Metering Systems can be reduced if the criteria are met.","It is proposed that a list containing details of those Suppliers who meet the first three of the above criteria be published on the BSC Website. The proposed solution is that Suppliers who believe themselves to meet these criteria would complete a new form within BSCP15, in order to apply for inclusion within the list. Within 5 Working Days following receipt of this form, BSCCo would be required to validate the Supplier’s fulfilment of the criteria, inform the Supplier of the outcome, and (if appropriate) publish the details of the Supplier on the BSC Website. It would therefore remain the responsibility of the Supplier to inform BSCCo of any change in their ability to meet the criteria.","ISG: 37","CPC00402","ISG","June 04 Release","Approve"]
[1029,"Enhancement to BPM to allow references","ELEXON","2003-12-22","In the Business Process Model (BPM), references for processes are added to the description. This hasn’t been done consistently, so there are approximately a quarter of the processes without references. By including the references in the description there is no easy way of searching for the references, and it isn’t possible to start with a reference and find which areas of the BPM model those processes within that reference.","The BPM should be upgraded to version 9, in order to allow user defined associations, to\nallow associations to a new object type – reference(s). The object type reference should be created within the BPM, and a reference created for each section of the BSC and each Code Subsidiary Document. Where applicable, each process, organisation and event should then be associated to one or more references. When the model is published, the publication set should be amended in order to publish the references. ","SVG: 36","−","SVG","Feb 04 Release","Approve"]
[1028,"Withdrawal of Supplier Hubs","ELEXON","2003-12-22","At present there is no process for an SVA Supplier to terminate a previously approved Supplier hub. Whilst termination of these hubs is largely an administrative matter, with the prospect of Supplier Agents withdrawing from Accredited status or merging this is likely to become an increasing issue over time.","BSCP 512 should be modified to accommodate a withdrawal process.\n",{"$nulls":3},"—","Withdrawn"]
[1027,"Revision to registration period for Metering Systems","ELEXON","2003-12-03","A discrepancy exists between the minimum period of notice required for a change of supplier for a SVA registered site (1-2 days) and the minimum period of notice required for a change of supplier for a CVA registered site (30WD)","It is proposed that the minimum period for change of supplier be reduced from 30WD to 5WD.","ISG: 37","CPC00402CPC00420","ISG","2004-03-01","Approve"]
[1026,"Procedures to support transfer of Metering System ownership between Distribution Businesses","ELEXON","2003-11-26","Prior to the implementation of Modification P62 there were already a number of existing Metering Systems. Implementation of P62 requires Metering Systems to be migrated to a different SMRS and in all cases the creation of a new Metering System Identifier (MPAN) and the termination of the old one. However, the transfer of Metering Systems between Distribution businesses was excluded from P62.","Possible solutions:\n1) Creation of a new BSCP to define the process(es) for migrating Metering Systems on existing embedded and directly connected distribution networks that are not part of the “Host” distribution network to P62 compliant arrangements. \n2) (preferred) Adopt “Option 1a” as the approach for registering Metering Systems on new or out of area networks. ",{"$nulls":3},"—","Withdrawn"]
[1025,"Clarification and correction of existing process within BSCP514","ELEXON","2003-11-24","Under the scope of CP955-Further definition of Timescales in BSCP514 'SVA Meter Operation for Metering Systems Registered in SMRS', an industry expert group was convened to consider potential timescale changes to BSCP514. This expert group identified several issues, relating to BSCP514, which were outside the scope of CP955 and required minor changes to clarify or correct existing processes within the BSCP.","CP1025 proposes minor changes to clarify or correct existing process within BSCP514.","SVG: 37","CPC00395","SVG","June 04 Release","Approve"]
[1024,"Amendment to BSCP11 Volume Allocation And Settlement Run Queries","ELEXON","2003-11-12","In the 'Action' column of section 4.1.11 of the document the term 'republish' is used.  This term is MDD specific and is therefore inappropriate for DPP.  The correct term is for DPP is 're-run'.","In the ‘Action’ column, replace “republish and distribute” with “re-run and distribute”. ","TDC: ","CPC00395","TDC","June 04 Release","Approve"]
[1023,"Inconsistent use of terminology in the TAA SD","ELEXON","2003-11-10","There are a number of instances of inconsistent terminology relating to Market Participants in the TAA Service Description.","A review of the TAA Service Description should be carried out with a view to updating the document to use meaningful and consistent terminology throughout. A quality check on the formatting of the document should also be undertaken, to ensure any problems with the document layout are also corrected. ",{"$nulls":3},"—","Withdrawn"]
[1022,"SSC changed without recalculation of EAC by NHHDC","ELEXON","2003-10-05","Whilst NHHDA prevents the change of an SSC during an AA, there is no corresponding requirement for NHHDA to check for and to reject, a change of SSC instruction without a corresponding revision of its EAC. The NHHDA application only records the SSC that applied during an AA period and the SSC that was applicable on the EAC’s EFSD. It does not record any further SSC changes against that EAC. Whenever NHHDA checks to see if an SSC is being used, it will check all the SSCs held for all AA periods and the SSCs that was applicable on all the EAC’s EFSD. It will not therefore include SSCs that have been assigned without a corresponding revised EAC being sent by the NHHDC since these will not been recorded by NHHDA. This means, for example, that a TPR can be added to a SSC that falls solely within this category.","There are a number of possible solutions:\na) We could add an obligation on the NHHDCs in PSL120, to recalculate a EAC and send it to the NHHDA, whenever the SSC is changed. \nb) The NHHDA application could be modified to assume that where a Metering System’s SSC was changed without a corresponding EAC being sent by the NHHDC, that the EAC for the previous SSC also applied to the new SSC. \n",null,"CPC00420",null,"—","Withdrawn"]
[1021,"Allocation of Metering Systems to the \"Economy 7 Profile Classes\"","ELEXON","2003-10-27","A number of Suppliers have raised issues with the application of the rules for allocating Metering Systems to the 'Economy 7 Profile Classes', as defined in BSC Procedure 'Allocation of Profile Classes & SSCs For Non-Half Hourly SVA Metering Systems Registered in SMRS' (BSCP516).","CP1021 proposes to allow the Supplier, where not aware via the customer or Meter Operator Agent of whether a Metering System has switched load capability, to allocate new connections to the relevant Unrestricted Profile Class (i.e. Profile Class 1 or 3). Existing Metering Systems will remain allocated to their existing Profile Class until such time as the Supplier becomes aware of a change to the switched load capability (except where there is a change from domestic to non-domestic or vice versa, or the addition/removal of maximum demand metering). It also proposes clarifications to the relevant BSCP516 definitions. ","SVG: 41","CPC00385","SVG","Nov 04 Release","Approve"]
[1020,"Clarification of Pre Payment Meter reading obligations","ELEXON","2003-10-27","BSCP504(v5) 3.4.1 states the Supplier should send pre payment reads to NHHDC at least every 3 months. Readings are received more frequently. BSCP504 3.2.6.11 states if a meter read is obtained in the SSD-5 and SSD+5 window, the new NHHDC should create a D0010 and a D0086.  If not a CoS read taken. When a read for a pre payment meter is obtained outside the cycle, and there is a CoS within the timescale, this meter read could also be used as a CoS reading.","It is proposed that changes be made to BSCP504 (v5) and PSL120 “Non Half Hourly Data Collection” (v8). ","SVG: 40","CPC00385/CPC00410/CPC00434","SVG",null,"Approve"]
[1019,"Clarification of Pre-Payment Meter reading Obligations – De-energised","ELEXON","2003-10-27","BSCP 504(v5) 3.4.1.1 footnote 75 provides for reading de-energised meters where no remote communications exist, but not for where remote communications do exist. If readings are not obtained from de-energised meters in time for Final Reconciliation, any consumption will be excluded from Settlements. "," This CP seeks to clarify NHHDC obligations to read de-energised meters that have remote communications","SVG: ","CPC00385CPC00410","SVG",null,"Approve"]
[1018,"Correction of formatting in BSCP76","ELEXON","2003-10-24","During the drafting of changes to BSCP76 for P113 a number of formatting inconsistencies were identified between BSCP76 and the standard BSCP conventions. As the inconsistencies had existed since Go-Live, were of a minor nature, and were outside the scope of the P113 changes, it was agreed to raise a CP to correct these at an opportune date in order to make BSCP76 consistent.","CP1018 proposes amendments to BSCP76.",{"$nulls":3},"—","Withdrawn"]
[1017,"SAA and SVAA Settlement Calendars","ELEXON","2003-10-21","The SAA and the SVAA are both required to develop appropriate Calendars detailing their relevant settlement activities, based on information from the FAA Payment Calendar and taking into account each other’s specific requirements. Up until 2002 ELEXON produced the SVAA Calendar on behalf of the SVA Agent. When the SVAA took over production of its Calendar for 2003 ELEXON experienced difficulties in reconciling the key dates within the two Calendars.","There are a number of potential solutions available: 1. Create a ‘Super Calendar’;  2. Adjust the FAA Payment Date BSCP01 allows the FAA Payment Date to be set at either 20 or 21WD from the Settlement Date; 3. Relax SF Run Date Requirement to SD+16WD Currently the SF Run Date is required to be set at +15WD from the Settlement Date or -5WD from the Payment Date; 4. Modify terminology in SAA Calendar Some of the current confusion can be remedied by modifying the ‘SVAA’ and ‘Notification Date’ items in the SAA Calendar to be consistent with that of the SVAA. However on its own this will not change the process by which the Calendars are produced and so inconsistencies may still occur. Option 1 would be the most effective long-term solution but would also have the greatest impact, especially on the SAA, and so one of the alternatives may be preferred.",{"$nulls":3},"—","Withdrawn"]
[1016,"Monthly D0095 reports from NHHDA software for P99 PARMS Reporting","ELEXON","2003-10-21","One of the monitoring requirements under P99 is for the monitoring of D0095 ‘NHHDA Exception Reports’. Modification Proposal P99 assumed that copies of all D0095s could be extracted onto CD-ROM and sent to ELEXON. This solution does not seem to be the most efficient method for either NHHDAs as Data Providers or ELEXON as recipients of the data.","ELEXON Circular EL0789, issued on 25 March 2003, proposes a timetable to be used by NHHDAs in order to create a steady and consistent flow of information to Suppliers (Attachment 1). To enable ELEXON/PAB to carry out high-level monitoring of these exceptions and the efforts made to resolve them, it is proposed that each time a D0095 is generated, the information from the Exception Header (EXH) record is stored for inclusion in a separate summary report. ","SVG: 38","CPC00400","SVG","Feb 05 Release","Approve"]
[1015,"BSCP15 Review","ELEXON","2003-10-21","In light of operational experience it is now thought an appropriate time to make amendments to BSCP15 and include house-keeping amendments identified since last issue.",null,"ISG: 44","CPC00388","ISG","Feb 05 Release","Approve"]
[1014,"NHHDA E03/E04 Exceptions","ELEXON","2003-10-21","At present, the CDCD functionality in the NHHDA software will produce an E03 exception if an Annualised Advance (AA) is received from either a non-appointed NHHDC or whilst the NHHDA concerned is not appointed to the Metering System. The same is true if an EAC is received, although in this case and E04 exception will be produced instead.","CP1014 proposes either:\na) modify the NHHDA software to only report E03 and E04 exceptions to PRS Suppliers if they differ to that known by the NHHDC and they overlap the period of the AA (in the case of E03), or the start date of the EAC (in the case of E04).\nb) Recognise that this will happen and document the situation to inform the NHHDA users and Suppliers. Test script 28 will have to be modified to reflect this functionality",{"$nulls":3},"—","Withdrawn"]
[1013,"Should a NHHDA E14, or E08, CDCD exception be raised","ELEXON","2003-10-21","Should a NHHDA E14, or E08, CDCD exception be raised when either the PRS Supplier, DC Supplier, details are unknown.","CP1013 proposes either:\na) Modify the NHHDA software to treat the case of no known corresponding PRS Supplier details as an ‘unknown’ Supplier and therefore always different to that known by the NHHDC, i.e. generate an E14 exception for this case.\nb) Modify the NHHDA software to treat the case of no known corresponding Data Collector’s Supplier details as an ‘unknown’ Supplier and therefore always different to that known by PRS, i.e. generate an E08 exception whilst appointed for this case.\nc) Recognise that this will happen and document the situation to clearly inform NHHDA users and Suppliers, i.e. that the E08 and E14 exceptions will only be reported if both the PRS and NHHDC Supplier details are present and different.",{"$nulls":3},"—","Withdrawn"]
[1012,"Multiple NHHDA CDCD exceptions being reported to DC's","ELEXON","2003-10-21","Modify the CDCD software, to exclude past appointed Data Collectors for E01/E02/E06 exceptions. This means that the CDCD software will only create E01/E02/E06 exceptions for all current, and future appointed, Data Collectors within the same Supplier Registration as the exception.","Modify the CDCD software, to exclude past appointed Data Collectors for E01/E02/E06 exceptions. This means that the CDCD software will only create E01/E02/E06 exceptions for all current, and future appointed, Data Collectors within the same Supplier Registration as the exception.",{"$nulls":3},"—","Withdrawn"]
[1011,"Correction of Price Derivation Codes","ELEXON","2003-10-02","The BMRA URS and the SAA URS both include an appendix detailing price derivation code definitions. Both of these documents contain an error. This could lead to confusion amongst participants.","The condition detail should be amended to read:\nQAPB + UESVA is zero (UESVA is the NIV untagged Sell Priced Volume Adjustment (energy))\nThe other condition details for Code I are correct. There is no impact on any software or other documentation.\n","ISG: 33","−","ISG","June 04 Release","Approve"]
[1010,"Incorrect footnote reference in section 3.3.10.2 of BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’","ELEXON","2003-10-02","Incorrect footnote reference in BSCP504 3.3.10.2 (Changes to SVA Metering System Standing Data). There is a cross-reference in this clause to footnote 69, which is incorrect. There are also two typos in footnote 68 which should be corrected at the same time.","Change reference in last clause of section 3.3.10.2 from footnote 69 to footnote 68, and correct typos in footnote 68.\n","SVG: 36","CPC00381","SVG","June 04 Release","Approve"]
[1009,"ECVAA Processing of Authorisation Requests","ELEXON","2003-09-30","The BSC section P states that ECVNAAs and MVRNAAs are effective from ‘(a) the effective date specified in such authorisation, and (b) the day following that on which the ECVAA gives notice of confirmation thereof pursuant to this Section P’, whichever is later.  However the ECVAA Service Description and URS state only that ‘the effective from Settlement Day must not be less than one calendar day after the day of receipt of the application’.","Paragraphs 6.1e and 7.1f of the ECVAA Service Description reference the ‘one calendar day’ validation rule and should be removed in order to prevent applications being rejected. A new paragraph is required in sections 6 and 7 requiring the ECVAA to ‘amend the Effective From Settlement Dates of any Authorisation where the Effective From date is not in the future, to be the day following the day of receipt of the application.’\nThe functional requirements F003 and F004 in the ECVAA URS should be altered to reflect the wording in the Service Description.","ISG: 35","CPC00436","ISG","June 04 Release","Approve"]
[1008,"Removal of obligation to raise ARs in BSCP40","ELEXON","2003-09-19","An Amendment Record (AR) is a record produced by ELEXON following the approval of a CP that provides exact details of how a Configurable Item will be amended as a result of that CP.  This is an internal ELEXON process. The obligation to raise ARs is contained within BSCP40 Section 2.2, though there are references to it elsewhere in the BSCP. Working practice within ELEXON has identified that the raising of these ARs is a superfluous exercise and that they are not necessary.","Remove the obligation to raise ARs, and all references to them, from BSCP40. ","SVG: 33","−","SVG","June 04 Release","Approve"]
[1007,"Revisions to Entry Process Requirements post P62","ELEXON","2003-09-18","P62 was a major and fundamental change to the trading arrangements that required significant changes to SVA systems and processes. Additional simplified Entry Process Testing was introduced to protect the integrity of Settlement. In order for existing Agents and Suppliers to become P62 compliant a new ‘TA Change Compliance’ Script was introduced for P62 using a new ‘assessment’ based approach. This Script was specifically created to test the integrity of Settlement in a P62 scenario whilst minimising the impact of additional entry process testing on existing market participants. It is expected that this additional entry process testing should normally be completed in a 3-5 day visit. All existing Suppliers and Supplier Agents are already obliged to be able to fully support the changes that were introduced by P62 on 1st August 2003","Whilst still providing assurance against the potential risk to Settlement it is proposed that\nBSCP512 is amended such that:\n• All Suppliers and Agents within Supplier hubs are required to have successfully completed P62\ncompliance testing and approval by 01/08/2004: and\n• Following PAB approval for a new LDSO to enter the market, or for an existing LDSO to operate in multiple GSP Groups, that any new Supplier hub formed utilising these LDSO’s are fully P62 compliant. ","−","CPC00363","SVG","Implemented"]
[1006,"Revised NHHDA archiving system parameters default val","ELEXON","2003-09-09","Opportunity was taken during the ‘NHHDA & EAC/AA 7.3.0 Project’ to assess the suitability of the recommended NHHDA system parameters concerned with database and file archiving. After consultation with users of the NHHDA software, ‘UNIX Upgrade of NHHDA & EAC/AA Project - Circular 02’ was published giving revised recommended default values and the rationale for the proposed changes. The NHHDA installation process for a new database, and the NHHDA System Management Guide, have not been updated to reflect the revised default values contained in ‘UNIX Upgrade of NHHDA & EAC/AA Project - Circular 02’. The revised default values will not affect existing NHHDA users as once installed these parameters are maintained via the NHHDA application’s client screens","Change the NHHDA installation process for creating new NHHDA databases and the NHHDA System Management Guide to use the revised default values contained ‘UNIX Upgrade of NHHDA & EAC/AA Project - Circular 02’ (shown in bold). ","SVG: 37","CPC00374","SVG","2005-04-01","Approve"]
[1005,"SVA Data Catalogue Volume 2: ‘MTC Common Code Indicator’ Data Item Valid Set Description Correction","ELEXON","2003-09-09","The ‘MTC Common Code Indicator’s’ Valid Set refers to the ‘false state’ as the “PES Specific Code”. This description should be amended to post P62 terminology and to bring it into alignment with the Data Transfer Catalogue (DTC) text for this data item.P62 (‘Changes to Facilitate Competitive Supply on the Networks of New Licensed Distributors’) was implemented on the 1st August 2003.","SVA Data Catalogue Volume 2 ‘MTC Common Code Indicator’\nExisting:\nF False - PES Specific Code\nProposed:\nF False - Distribution Business Specific Code.","SVG: 34","CPC00371","SVG","June 04 Release","Approve"]
[1004,"SVA Data Catalogues: Minor Corrections to the ‘Related Documents’ sections","ELEXON","2003-09-09","The document cross reference sections in the SVA Data Catalogue Volumes 1 & 2 both incorrectly refer to BSCP 501’s title as the “PES Registration Service” whereas its correct title is “Supplier Meter Registration Service”. The BSCP documents have a NETA reference numbers (i.e. ???CMC). These should be removed as they are no longer valid. The SVA Data Catalogue Volume 2 refers to the BSCPs as “Agreed Procedure”. This expression is no longer appropriate and should be removed.  ","SVA Data Catalogue Volume 1 Section vi ‘Related Documents’ change:\nExisting:\nReference 4 ‘BSCP501 PES Registration Service 006CMC’\nProposed:\nReference 4 ‘BSCP501 Supplier Meter Registration Service’\nSVA Data Catalogue Volume 2 Section vi ‘Related Documents’ change\nExisting:\nReference 9 ‘BSCP501 : Agreed Procedure : PES Registration Service. 006CMC’\nProposed:\nReference 9 ‘BSCP501 : Supplier Meter Registration Service’\nIn addition, all references to ‘???CMC’ and the term ‘Agreed Procedures’ will be removed from the ‘Related Documents’ section of SVA Data Catalogue Volume 1 & 2","SVG: 34","CPC00371","SVG","June 04 Release","Approve"]
[1003,"SVA Data Catalogue: Correction of the “Host LDSO Name” Data Item Description","ELEXON","2003-09-09","The description of the data item “Host LDSO Name” in the SVA Data Catalogue Volume 2 refers to a PES Supply Licence relating to distribution activities in England and/or Wales at Code Effective Date. However with the introduction of P62 and the introduction of new distribution businesses into the market, this description is no longer appropriate.","There are two possible solutions:\n1) Remove “Host LDSO Name” from the SVA Data Catalogue Volume 2 and change the references to it in the P0170 “HH Unmetered Supply Certificate” and P0207 “NHH Unmetered Supply Certificate”\ndata flows in SVA Data Catalogue Volume 1 to use “LDSO ID” instead.\n2) Keep the Host LDSO Name data item but remove the text in its note section and amend its\ndescription.","SVG: 34","CPC00371","SVG","June 04 Release","Approve"]
[1002,"Change to BSCP40 to allow Energywatch to raise CPs","ELEXON","2003-09-08","Energywatch are currently not listed in BSCP40 as authorised to submit Change Proposals.  They are therefore unable to raise CPs, which is inconsistent with the approach defined in the Code in relation to raising Modification Proposals. The omission of Energywatch from BSCP40 is a historic continuation from AP40 during the Pool, the rationale for which no longer applies  There is no reason why Energywatch should not be able to raise CPs or to participate in the change process. ","BSCP40 should be changed to allow Energywatch to submit CPs and also to participate in the change process.  Energywatch would be required to nominate a Change Administrator in the same way as BSC Parties.","SVG: 33",null,"SVG","June 04 Release","Approve"]
[1001,"Improvements to Non Half Hourly Data Aggregation (NHHDA) Software application in order to facilitate reporting and improve usability","ELEXON","2003-09-03","The NHHDA software application is currently in need of enhancement to improve reporting functionality in order to support the monitoring of Supplier / Agent Performance. Secondary benefits of the proposed changes include improved usability and functionality of the NHHDA system. This includes the redesign of some aspects of the ‘front end’ of the application as well as some ‘functionality based’ code changes.","CP1001 proposes improvements  to Non Half Hourly Data Aggregation (NHHDA) Software application in order to facilitate reporting and improve usability. ","SVG: 36","CPC00374/CPC00387","SVG","June 04 Release","Approve"]
[1000,"Removal of BSCP20/4.5 and amendment of BSCP02/4.4.","ELEXON","2003-08-19","BSCP02 (Proving Test Requirements for Central Volume Allocation Metering Systems) and BSCP20 (Registration of Metering Systems for Central Volume Allocation) both contain a form titled ‘Confirmation of Installation of Metering Equipment (Including Extension or Modification to Metering Systems)’.\nThe purpose of the forms are as follows:\n• BSCP02/4.4: ‘is the official certificate provided by the MOA, on behalf of the Registrant, that the Metering System has been installed and commissioned in accordance with the Meter Technical Details forwarded to the CDCA’.\n• BSCP20/4.5, ‘is completed by the MOA and submitted to the CDCA to confirm that Metering System has been satisfactorily installed, is Code of Practice (CoP) compliant, has undergone a CoP 4 commissioning test and is fully operational’.\nBSCP20/4.5 and BSCP02/4.4 serve the same purpose. There are only two differences between the two forms. BSCP20/4.5 requests Boundary Point/Systems Connections Point/Circuit Name; and also has a field for the MOA to sign.","BSCP20/4.5 should be removed and replaced with a note advising of the removal and reference to\nBSCP02/4.4. BSCP02/4.4 should include two additional fields:\n· the Boundary Point/Systems Connections Point/Circuit Name field; and,\n· a field for an MOA authorised signatory to sign.\nThe summary of the forms in both BSCPs should have the same wording.","−",null,"ISG","−","Rejected"]
[999,"Upgrade of the SVA software application to operate under UNIX 5.1B","ELEXON","2003-08-21","The current version of SVA, v7.0.0, operates under UNIX 5.1 which is a prior version to the latest supported version, UNIX 5.1B. The proposed upgrade of the operational server requires that UNIX 5.1B is used and consequently the current version of SVA will not operate on the proposed hardware platform.","The SVA software application will be upgraded to operate using UNIX 5.1B. ","SVG: 32","−","SVG","June 04 Release","Approve"]
[998,"Merge BSCP026 and BSCP526 to create new TA BSCP","ELEXON","2003-08-05","BSCP026 and BSCP526 will be merged into one BSCP and the changes described above will be incorporated into the new BSCP. A ‘red-lined’ copy of a new BSCP will follow highlighting the changes necessary.","BSCP026 and BSCP526 will be merged into one BSCP and the changes described above will be incorporated into the new BSCP. ","SVG: 33","CPC00355","SVG","June 04 Release","Approve"]
[997,"Inconsistencies between the CRA, URS and BSCPs","ELEXON","2003-08-04","There are several processes in different BSCPs that are not mentioned or do not match the CRA URS. Thus changes are suggested to the CRA URS to resolve this and eliminate inconsistencies and hence reduce confusion amongst participants.","1) a)b)c) New function and flow should be added to support de-registration activity.\n[Although the CRA URS (v.5) does not explicitly mention de-registration of BM Unit, Trading Unit or Metering System, one of their attributes is an Effective To Date which when entered will trigger de-registration. Deregistration is effected by setting this and the CRA view it as an attribute of the BM Unit that can bring about de-registration but do not detail it as a separate process]\n2) Two new flows are required. One by which registrants can object to a change in registrant and one by which MOAs can object to being made the MOA for a Metering System.\n3) New function and flow required to inform LDSO of embedded BM Unit registration alterations","ISG: 39","−","ISG","−","Rejected"]
[996,"Amendment to BSCP06","ELEXON","2003-08-01","The proposal will amended BSCP06 by removing the obligation on the CDCA to carry out the sealing of CVA Metering Equipment. The changes will allow the MOA to initially seal, remove and replace seals and also remove the need for the CDCA to attend site where the MOA is required to conduct work on CVA Metering Systems.","Changes to BSCP06 will allow the MOA to remove and replace CVA Metering Equipment seals as necessary and will ensure that the MOA carries out sealing as opposed to the CDCA. An obligation to retrieve meter data before and after any works are carried out will remain for work that will affect the meter’s data, the provision of this data will be provided by the MOA or CDCA as determined by the MOA. ","−",null,"ISG","−","Rejected"]
[995,"Replacement for Workaround W018","ELEXON","2003-07-28","Currently the process allows manual corrections to be done to the SAA or BMRA databases after they have been agreed by NGT with the Trading Party. ELEXON and NETA Central Services are then advised of the proposed corrections. The changes are then reviewed and authorised by ELEXON, and inputted by NETA Central Services into the relevant database.","The proposed solution is to incorporate the current process into a new BSCP. Changes to the current workaround will be minor, but will include making ELEXON a witness to the discussion between the Trading Party and NGT","−","CPC00369","ISG","−","Rejected"]
[994,"Improvements to the BMRS Help Screens","ELEXON","2003-07-29","A number of issues have been raised concerning the current BMRS Help Screens. The usefulness of these help screens is impaired by the fact that they are very difficult to use and the content is not necessarily always up to date. The issues can be split into two distinct categories: ease of use and content.","It is proposed that the existing single screen be split into 4 separate sections, as outlined below;\neach of which will be opened in a separate window. Each of these windows should also have an\noption to display in a printer-friendly format.\n","ISG: 33","−","ISG","June 04 Release","Approve"]
[993,"Removal of business and working day definitions","ELEXON","2003-07-25","A number of Balancing and Settlement Code Procedures (BSCPs) contain definitions of Business Day and Working Day. The Code also defines the terms Business Day and Working Day. The definitions of Business Day and Working Day within BSCPs differ between BSCPs and the Code, although the intended meaning in all documents is the same. The BSCPs state that where there is an inconsistency between the provisions of the BSCP and the Code, the provisions of the Code shall prevail. ","CP0993 proposed that in order to prevent further inconsistencies occurring within the BSCPs should the definition of Business Day or Working Day be amended in the Code, the definitions of Business Day and Working Day should be removed from the BSCPs.","SVG: 33","CPC00355","SVG","June 04 Release","Approve"]
[992,"Provision of Site Technical Details by the Distribution Business to the Meter Operator Agent on a Change of Measurement Class","ELEXON","2003-07-24","Upon the receipt by LDSO of the D0170 from the MOA the LDSO is required to provide the MOA with site technical Details via the D0215. This applies equally to both Half Hourly (HH) and Non-Half Hourly (NHH) markets. This requirement is detailed for the Distribution Business in BSCP515 in relation to new connections but is not detailed in relation to a Change of Measurement Class, for which Site Technical Details are also required.","Add into BSCP515 sections 2 ‘Workflow Diagrams’ and 3 ‘Interface and Timetable Information’ a new process for a ‘Change of Measurement Class (SVA only) from NHH to HH Metering System and vice versa’ with steps for the MOA to request site technical details and an obligation on the LDSO to provide these details. ","SVG: 33","CPC00348","SVG","June 04 Release","Approve"]
[991,"MDD Error - MTC LLFC SSC Combinations Screen","Cap Gemini","2003-07-24","The drop-down list within the Maintain Valid MTC LLFC SSC Combinations screen produces a display of valid LLFC/SSC Combinations for selection and standard operational procedures involve the system operator selecting a valid combination using this drop down list. Under test conditions it has been demonstrated that it is possible to input an invalid LLFC/SSC combination by circumventing the standard operational procedures. It is possible to enter an MS Specific LLFC of 'A' where the SSC Type is 'E' and an MS Specific LLFC of 'C' where the SSC Type is 'I', both of which are invalid combinations.","CP0991 proposed to change the MDD application the next time that it is develop.",null,"−","SVG","2003-08-01","Approve"]
[990,"Rectification of EAC/AA Calculator Issues","ELEXON","2003-07-23","When a PERQ/PDRQ file is sent but a line of data is missing the entire file fails rather than that one MPAN affected. In the case of severe fatal errors the whole PERQ/PDRQ file will  be rejected . However on finding a MPAN, within a PERQ/PDRQ file, where the data is incorrect an error will be raised in the control file and the next MPAN in the file will be processed","In the case of severe fatal errors the whole PERQ/PDRQ file will be rejected . However on finding a MPAN, within a PERQ/PDRQ file, where the data is incorrect an error will be raised in the control file and the next MPAN in the file will be processed. The whole PERQ/PDRQ file will not be rejected. This file error handling functionality would then be in line with the NHHDA application.\n","SVG: 33","CPC00348","SVG","June 04 Release","Approve"]
[989,"Revision to BSCP14 to bring it in line with the BSC.","National Grid","2003-07-23","Section Q was modified in line with the implementation of P73. This stipulated that a Bid/Offer Acceptance (BOA) number should be included in addition to the other required data when submitting a Manifest Error Claim. Referring to Section Q the specification of BOA detail when the BOA number is not available can not be done on the standard Transmission Company Manifest Error Claim Form (BSCP14 Form F14/02).","The text in section 1.6 and 4.11 of BSCP14 should be modified to reflect the changes made to the BSC section Q 7.2.2. Add an additional table alongside ‘Claim Details:’ in the Transmission Company Manifest Error Claim Form (Form F14/02) and also in the Notification of Receipt of Manifest Error Claim Form by the DA (Form F14/03). The additional table should be titled Bid-Offer Acceptance Volume (complete only if BOA No. unavailable). The table will have four columns headed: From MW, From Time, To MW and To Time and at least four rows for specifying BOA points.\n","ISG: 33","CPC00361","ISG","June 04 Release","Approve"]
[988,"Performing Data Estimations Post SF Run","ELEXON","2003-07-22","Neither the Code nor BSCP03 address the issue of a cut off date for submitting data estimations. BSCP03 implies that data estimation can only be carried out up to SF (BSCP03/3.1). A new section, 3.2 should be written in, titled Data Estimations Post SF Run, with similar wording as 3.1. A cut-off date of 30 days prior to RF should be included and direction for the registrant to raise a Trading Query through BSCP11 after this date.","BSCP03 should be modified as follows:\n3.1 should be titled as Data Estimations for SF Run.\nA new section, 3.2 should be written in, titled Data Estimations Post SF Run, with similar wording as 3.1. A cut-off date of 30 days prior to RF should be included and direction for the registrant to raise a Trading Query through BSCP11 after this date.","ISG: 33","CPC00354/CPC00360","ISG","June 04 Release","Approve"]
[987,"ECVAA URS - Amend Timescales","ELEXON","2003-07-22","Through operational experience, it has become apparent that the timescales referred to in ECVAA URS are impractical in relation to historic dates. The timescales defined in the URS needs to be reviewed in light of operational practice. These timescales do not allow for a one day notification period for terminations in the case of historic dates. Currently, the URS requires that these forms to be rejected.","Amend the URS to allow the Agent to apply the earliest available EFD, rather than applying the principles from the URS and rejecting forms with ‘historic’ dates. For example, if the BSCP71 Forms state an EFD of 14 May 2003 and the matching Form was received on 14 May 2003, IMServ would enter the earliest available EFD, in this case, 15 May 2003. ",null,"−","ISG","−","Rejected"]
[986,"Amendments to BSCP38","ELEXON","2003-07-21","There is currently some lack of clarity in BSCP38.   This has resulted in inconsistencies in the process and instances where parties have submitted incorrect forms due to misleading instructions in the BSCP.","CP0986 suggested a number of amendments to BSCP38 to improve the clarity of the document","SVG: 36","CPC00376","SVG","June 04 Release","Approve"]
[985,"Obligation on LDSO","ELEXON","2003-07-18","BSCP515 ‘Licensed Distribution’ has been created under the implementation of Modification Proposal P62 ‘Changes to Facilitate Competitive Supply on the Network of New Licensed Distributors’. ","CP0985 proposed to add a process to BSCP515 to oblige the LDSO to maintain a register of Exemptable Generating Plants.",null,"−","SVG","−","Rejected"]
[984,"Addition of Processes in BSCP515 to update the National Measurement Transformer Error Statement","ELEXON","2003-07-15","Section L 2.5.3 (a) of the BSC requires the provision of measurement transformer test certificates detailing measurement errors to be maintained and produced in the event of a Technical Assurance Audit. The requirement for the provision of these certificates from LDSOs has often proved difficult to fulfil. Test data has therefore been collected to produce generic certificates; however these are specific to the LDSO area and equipment type. The data and therefore generic certificates produced have been approved by either the Pool TS2 or the SVG. Generic CT and VT test certificates provide the TAA with confidence in the equipment used for Settlement purposes where a generic certificate exists for the equipment in question.","The proposed solution includes the addition of two new processes contained within BSCP515 ‘Licensed Distribution’, for the addition of measurement transformers to the error statement and the removal of measurement transformers from the error statement as they become redundant or inaccurate. New appendices to BSCP515 are also proposed to further explain the processes and to give a standard form for submitting data for the addition of measurement transformers to the error statement. ","SVG: 34","−","SVG","June 04 Release","Approve"]
[983,"Inclusion of new approved meter types BSCP601","Scottish and Southern Energy","2003-07-14","Recently two new meter types were approved for use in PRS - CM32 and the POREG. However because these have not yet been listed in BSCP601 Meter Operators are unable to advise Data Collectors that they have in fact installed these meter types.","One way this could be facilitated is when ELEXON issue the certificate of compliance they could also issue an ELEXON Circular notifying market participants of the change to the list of meter types in the appropriate appendix to BSCP 601. This would mean that parties would be advised of the update in a timely manner and without the need for a Supplier to sponsor a change.","SVG: 39","CPC00343","SVG","June 04 Release","Approve"]
[982,"Inconsistency within BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS","ELEXON","2003-07-11","BSCP502, steps 3.2.4.8 and 3.2.7.8 state ‘Request up to 14 months history data, where available, including the final Meter register reading by the old HHDC and the last physical Meter register reading taken on site, for estimation purposes’ within the Interface and Timetable section. The corresponding text boxes within the workflow diagram section (processes 2.2.4 and 2.2.7) state ‘Request up to 3 months history data’. Steps 3.2.4.8 and 3.2.7.8 were amended as part of the SVA May Documentation Batch Release under CP873 ‘Changes to the Half Hourly Data Estimation Requirements within Code Subsidiary Documents’. The workflow diagram text boxes were not updated at the same time.","CP0982 proposed to make a change to BSCP502 to bring the text boxes in workflow diagrams 2.2.4 and 2.2.7 in line with the corresponding Interface and Timetable steps 3.2.4.8 and 3.2.7.8 i.e. change the text boxes to read ‘Request up to 14 months history data, where available, including the final Meter register reading taken by the old HHDC and the last physical Meter register reading taken on site’. ","SVG: 32","CPC00343","SVG","Feb 04 Release","Approve"]
[981,"Consistency change with MRA relating to timescale for Supplier registration in Supplier Meter Registration Service","ELEXON","2003-07-11","Apply consistency changes to BSCP501 ‘Supplier Meter Registration Agents’, to reflect the requirements contained within the Master Registration Agreement (MRA), relating to the timescale by when a Supplier can register its application for a Metering System in Supplier Meter Registration Service (SMRS). This change will affect the change of supplier processes and the new connection processes within BSCP501.","CP0981 proposed to revise the text in the ‘When’ box of 3.4.1, 3.7.1 to\n“On change of Supplier between SSD-28CD and SSD-1WD or where SMRA allows a registration\napplication on SSD” and to add a new footnote associated with the new text added to the ‘When’ box as described above: ‘Providing that the registration is received by 1800 on SSD’.","SVG: 33","CPC00355","SVG","June 04 Release","Approve"]
[980,"Use of Sub-kWh Values in Meter Register Readings","ELEXON","2003-07-07","The SVA Data Catalogue, the DATA Transfer Catalogue and the EAC/AA calculator all allow Meter Register readings and Meter Advance values to be measured in units of 100Wh.  This is inconsistent with the obligations defined in BSCP504 section 4.7 (Manual Adjustment of Meter Readings.)","CP0980 proposed to amend the EAC/AA calculator such that it will discard fractions of kWh during its input parameter validation. ",null,null,"SVG","−","Rejected"]
[979,"Addition of the Pilot Metercom","ELEXON","2003-07-07","The Pilot Systems Metercom, an independent Data Collection Systems underwent Protocol Approval Testing with the npower Data Collector System on 13 May 2003, in accordance with BSCP601 ‘Metering Protocol Approval and Compliance Testing’. The report of this testing is to be presented to the Supplier Volume Allocation Group (SVG) for approval shortly. BSCP601 states that within 10 Working Days of the approval of the Protocol by SVG, Appendix 3.3 of BSCP601 ‘Protocol Approval List’ should be updated include the new approved protocol. The progression of this Change Proposal (CP) is subject to the approval of the Pilot Metercom by SVG.","CP0987 proposed to add the Pilot Systems Metercom for use with the Npower Data Collection System to appendix 3.3 of BSCP601.","SVG: 30","−","SVG","2003-08-01","Approve"]
[978,"Security access meter passwords","ELEXON","2003-07-04","Electronic meters for use in the SVA market complying with CoP 5 and 3 have four levels of security providing differing levels of access to the meter. When initially supplied by the manufacturer, meters have common passwords for each level or manufacturers default passwords. Most meters have been installed with some password levels left with common passwords installed. This is due in part, to pre-NETA arrangements when the HHDC had these common passwords embedded in the data collection software (MV90) which allowed the HHDC to access meters at level 2 without the need for knowledge of each password. Since the introduction of the DTN, HHDCs require the level 2 password to be transmitted via the D0268 flow. This is consistent with the requirements of HHDCs that choose not to use MV90.","BSCP 514 ‘SVA Meter Operations for Metering Systems Registered in SMRS’ due for implementation 28 August 2003, should be amended to ensure that common passwords are not used for any password level and that all passwords should be unique within each Meter Operator Agents control. ",null,"CPC00342/CPC00343/CPC00382/CPC00413","SVG","−","Rejected"]
[977,"Upgrade of NHHDA and EAC/AA software applications to Oracle 9i","N/A","2003-07-02","The Oracle version (8.1.7.4.) that is compatible with the current versions of the NHHDA and EAC/AA software applications (7.5.0 and 7.4.0 respectively) will be de-supported at the end of 2003.","To rebuild the NHHDA and EAC/AA software applications so that they are able to operate using Oracle 9i. ","SVG: 33","CPC00352","SVG","June 04 Release","Approve"]
[976,"BMRS System Updates","British Gas Trading","2003-07-02","The BMRS publishes the National and Zonal Indicated Demand (INDDEM), the National and Zonal Indicated Generation (INDGEN), the National Indicated Margin (MELNGC) and the National and Zonal Indicated Imbalance (IMBALNGC) 5 times a day. British Gas Trading (BGT) would like the frequency of reporting these parameters to be increased.","CP0976 proposes that INDDEM, INDGEN, MELNGC and IMBALNGC be updated on a [half-hourly] basis. Section Q 6.1.8 of the BSC specifies the data items that the Transmission Company must provide to the BMRA. ","ISG: 32","CPC00338/CPC00339","ISG","Feb 04 Release","Approve"]
[975,"Removal of 'Permit Notification Rejection Flag' references","ELEXON","2003-07-02","Following the implementation of CP703 ‘Credit Default Process’ on 24 June 2003, the ‘Permit Notification Rejection Flag’ has been renamed to ‘Credit Default Authorisation Flag’ in the Energy Contract Volume Aggregation Agent (ECVAA) Systems. The corresponding changes were not made to the Central Registration Agent (CRA) Systems and so the documentation still refers to the ‘Permit Notification Rejection Flag’.","CP0975 proposed two solutions:\nOption 1: remove all references to the ‘Permit Notification Rejection Flag’ from the CRA documentation. The contractual derogation that was put in place in the June 03 Release to not exercise the redundant functionality will also need to be removed. Include an obligation in the Central Service Agent and ELEXON LWIs to ensure that requests for a change in status of the ‘Credit Default Authorisation flag’ are not processed.\nOption 2: remove all references to the ‘Permit Notification Rejection Flag’ from the CRA documentation (including IDD) and remove the contractual derogation as detailed above. Remove the functionality from the CRA software to ensure that the CRA is unable to set the status of the ‘Credit Default Authorisation flag’.","ISG: 31","−","ISG","Feb 04 Release","Approve"]
[974,"Full review of BSCP65","ELEXON","2003-06-23","A full review of BSCP65 needs to be carried out to ensure that the processes are clarified and are brought in line with Section A of the Code. Inconsistencies have been identified as part of the BSC review (in particular with regard to Withdrawal from the BSC).","CP0974 provided a full review of BSCP65.","ISG: 40","CPC00386/CPC00436","ISG","Nov 04 Release","Approve"]
[973,"Extension of Parameters of Party Name field","ELEXON","2003-06-23","Section A of the Code refers to Party Registration data as including its full name and contact details. Central Systems currently only allows for a maximum of 30 characters to be entered in the Party Name field. As a result some Party names have been truncated. Concerns have been raised that the Party Name entered should correspond with the name provided on the BSCP65 registration forms and on the ELEXON website.","Extend the parameters of the Party Name field on Central Systems to allow for 60 Characters to be entered. ","ISG: 36","−","ISG","−","Rejected"]
[972,"Review of BSCP71","ELEXON","2003-06-23","Through operational experience it has become clear that the timescales referred to in BSCP71 are inaccurate. The timescales currently indicated in the BSCP need to be reviewed in light of operational practices. Further adjustments are required to some of the forms and interface timetables.","Parties can submit forms to ECVAA on days other than just Working Days, this needs to be reflected in the BSCP. The BSCP also states the Effective to Date cannot be less than 1 calendar day after the receipt of the termination request by ECVAA and also that the counterparties are notified 1 day before the termination. However, in reality it seems that authorisations can have the same Effective to date as the day that they are submitted and therefore counterparties would not be notified a day before the termination. BSCP71 indicates that any of the counterparties to an ECVNA/MVRNA authorisation can terminate the authorisation where as BSCP38 suggests that you have to be a Party to terminate an authorisation. ","−",null,"ISG","−","Rejected"]
[971,"Removal of BSCP07","ELEXON","2003-06-18","BSCP07 is a procedure, which was largely copied over from AP 07, which was used to instruct and communicate a number of manual data changes under the Pooling and Settlement Agreement (P&SA) arrangements. Changes to Meter Technical Details can already be instructed through BSCP20.","CP0971 proposed to remove BSCP 07 form operational use.","SVG: 33","CPC00338/CPC00339","SVG","June 04 Release","Approve"]
[970,"Amendment to BSCP31 to remove reference to the P&SA","Mandi Francis, Trading Arrangements Design","2003-06-18","BSCP 31 ‘Registration of Trading Units’, V4.0 (13 August 2002), section 4.1 ‘Trading Unit Registration Information’ states that evidence provided can include: “Evidence that the BM Unit configuration was granted trading site status under the Pooling and Settlement Agreement.” This requirement for evidence is now redundant and can be removed.","Cp0970 proposed to remove the final bullet point of 4.1(a) ‘Information Required’ to remove the reference to “Evidence that the BM Unit configuration was granted trading site status under the Pooling and Settlement Agreement.”\n","ISG: 44","−","ISG","Feb 05 Release","Approve"]
[969,"Change to the SVA Data Catalogue to state that all relevant fields within data flows should be completed.","ELEXON","2003-06-11","The Data Transfer Catalogue (DTC) contains, in Annex A (A21) the phrase ‘Participants are advised to populate ALL data items and groups where the data is available and the business reason for sending the flow indicates that the data is relevant to the recipient if it is provided’. There is no corresponding statement in the SVA Data Catalogue.","CP0969 proposed to add into the SVA Data Catalogue a phrase similar to that contained in A21 of the DTC. ","SVG: 31","CPC00332","SVG","Feb 04 Release","Approve"]
[968,"Addition of an 'Event Indicator' to the D0155","ELEXON","2003-06-10","Under the New Connection and Change of Measurement Class processes, a D0155 ‘Notification of Meter Operator or Data Collector Appointment and Terms’ is sent to Supplier Agents. These agents generally do not know the circumstances under which they have been sent this data flow. In these cases, the Supplier Agents need to know why they have been sent the D0155 data flow so they can identify what other data flows to expect, in what timescales and what other obligations they have to carry out. ","CP0968 proposed to include a reason code on the D0155 ‘Notification of Meter Operator or Data Collector Appointment and Terms’ data flow to notify the recipient of this data flow why the data flow has been sent. This change corresponds with MRA DTC CP3212.","SVG: 30",null,"SVG","−","Rejected"]
[967,"Addition of an 'Event Indicator' to the D0149 and D0150","ELEXON","2003-06-10","ELEXON have developed BSCP514 for Meter Operator Activities. This BSCP specifies that, on change of Non-Half Hourly (NHH) Meter Operator Agent (MOA), Meter Technical Details (MTD) are issued to other parties (via the D0149 and D0150). Walkthroughs were held as part of the development of the BSCP and the walkthrough group believed that this obligation should exist, so that following the Change of MOA, all parties have the same starting information. Impact Assessment of the BSCP has highlighted that parties need to know why they have been sent the MTD, so that they can identify whether or not they expect to receive a D0010 ‘Meter Readings’.  ","CP0967 proposed to include a reason code on the D0149 ‘Notification of Mapping Details’ and D0150 ‘Non Half Hourly Meter Technical Details’ data flows to notify the recipient of these data flows why the data flow has been sent. This change corresponds with MRA DTC CP3211.","SVG: 30",null,"SVG","−","Rejected"]
[966,"D0235 Exception reporting - BSCP503, section 4.3","ELEXON","2003-06-06","BSCP503 section 4.3 states that when consumption data is received but not expected: Check for SVA Metering Systems which have consumption values stored against them but for which the HHDA is not appointed to aggregate on this Settlement Day. Record such data anomalies for reporting purposes and ignore these consumption values from this point on for this aggregation process. Report full details of any such anomalies to the HHDC supplying the data. However, it is the responsibility of Suppliers to comply with the BSC and thereby to manage and co-ordinate their agents to achieve compliance. It is also the responsibility of the Suppliers to investigate and record anomalies and any action taken to prevent it occurring in the future. The problem therefore surrounds the Supplier not being informed of the exception, as the anomalies are only reported to the HHDC supplying the data.","CP0966 proposed to amend BSCP503 section 4.3 to include a report of the exception and anomaly details to the Supplier and the HHDC supplying the data. ",null,"CPC00425","SVG","−","Rejected"]
[965,"Superfluous reporting of D0095 exceptions combined with an E01 exception following a CoS","Centrica Business Services","2003-06-05","An E01 exception is reported whenever an appointed NHHDA does not receive an EAC or AA from an appointed NHHDC. Where an E01 is produced for a new Supplier following a Change of Supplier process it also results in additional exceptions where the NHHDC and NHHDA agents are the same for both the old and new Suppliers. Because the NHHDC does not process end dates for Registration Details, Profile Class/Standard Settlement Configuration, Measurement Class, GSP Group, and Energisation Status, the NHHDA as well as producing an E01 will also generate an exception against the aforementioned data where it mismatches with SMRS. The most frequent and misleading of these is the E08 (Supplier incorrect), but could also include E09, E10, E11, E12 & E13.","Whenever an E01 is generated following a Change of Supplier the NHHDA (same for both Suppliers) should ignore any data provided by the old NHHDC (same for both Suppliers) on behalf of the old Supplier, thus preventing the production of superfluous E08 exceptions in particular, but also E09, E10, E11, E12 & E13s. ","SVG: 51","CPC00352","SVG","Feb 04 Release","Approve"]
[964,"Inclusion of BSCP06 form for CDCA-I038 flows","ELEXON","2003-06-04","There is currently no preformat for CDCA-I038 and historically IMServ have designed and used a form to record the fault data as part of their normal operating procedures. This CP proposes to incorporate this form into BSCP06 in order to formalise the Metering Equipment Report.","CP0964 proposed to incorporate this form into BSCP06 in order to formalise the Metering Equipment Report.","ISG: 33","CPC00351","ISG","June 04 Release","Approve"]
[963,"Provision of Facility in ECVAA for Defaulting BSC Party","ELEXON","2003-06-04","Currently there is a manual process for removal of all ECVNs and MVRNs for a defaulting Party. This is unsatisfactory both in terms of provision of an adequate audit trail and the possibility of manual error. It is proposed to replace this with a “front-end” solution, which would provide the operator with on-screen prompts to confirm notifications being terminated. The system would update immediately, ensuring a proper audit trail.","CP0963 provides a facility for the removal a defaulting BSC Party effective from\nSettlement Period 1 on Settlement Day D. ","−","CPC00349","ISG","−","Rejected"]
[962,"Amend Registration Reports to include BM Unit Info","ELEXON","2003-06-03","CP0962 refers to amendments to the Registration Report (CRA - I014) and to the Operations Registration Report (CRA - I020). The intent of the CRA – I014 report has been to confirm those registration amendments made directly by BSC Parties (i.e. BSC Party request direct to the CRA) to their BM Units. Therefore there are data items, registered or amended by BSCCo, or derived by the Central Registration Agent (CRA) that are not reported in the report. Thus BSC Parties are not aware of changes to such data for their BM Units.\n","CP0962 proposed to add the listed data items into the relevant part of the report, as follows:\nRegistration of, or amendment to, any of the following data items will be reported on the CRA – I014, Sub flow 5 (BM Unit registration) on initial registration and then as and when changed:\n- BM Unit Credit Assessment Export Capability (BMCAEC);\n- BM Unit Credit Assessment Import Capability (BMCAIC);\n- Transmission Loss Factor (TLF); and\n- Credit Assessment Load Factor (CALF).\n","−","CPC00323","ISG",null,"Approve"]
[961,"New validation rules for the MDD application","ELEXON","2003-05-28","During the Market Domain Data (MDD) software witness testing for Modification P62 ‘Changes to Facilitate Competitive Supply on the Networks of New Licensed Distributors’, it was found that certain data combinations could be entered (and subsequently accepted by the database) which should not be allowed.  Examples are: Line Loss Factor Class (LLFC) records can be created for a Market Participant after the Market Participant Effective To Settlement Date; It is possible to enter a Market Participant Role 'R' (Distributor) without a distribution id; and It is possible to enter a distribution id for Market Roles other than ‘R’ (other than Distributor). These were not ‘P62-specific’ problems, i.e. validation rules to stop these data combinations should already exist in the MDD software.","CP0961 proposed that ELEXON liases with the SVA Agent to determine a suitable list (including all of the above) of extra validation rules for the MDD software. These rules would then be implemented either in its own release, or as part of another formal build. ","SVG: 36",null,"SVG","June 04 Release","Approve"]
[960,"NHHDC Validation on Reading Dates","SAIC Ltd on behalf of ScottishPower and Manweb","2003-05-22","Currently, BSCP504 (Appendix 4.2) states that NHHDCs should perform validation to check that the date of the current reading is after the date of the last valid reading. If this check is rigorously undertaken, then it will result in readings being rejected in legitimate circumstances. An example of such a circumstance is when a CoS reading is agreed retrospectively it is a legitimate scenario that valid readings may have been processed after the CoS date.","It is not reasonable to enforce this validation in all scenarios and it should therefore be made\nan optional validation step under BSCP504. If necessary, clarification on when such\nvalidation is not necessary could be included in BSCP504.\n","−",null,"SVG","−","Rejected"]
[959,"UKPX MIDP 2 Hour Blocks","UKPX","2003-05-21","UKPX wish to trade 2 hour blocks and feel the data should be included in the MID values.","UKPX to change it’s MIDS and send to ELEXON for review.","−",null,"ISG",null,"Approve"]
[958,"Enhancements to BSCP28","ELEXON","2003-05-14","To increase the requisite amount of information submitted by Public Service Distribution Operations (PDSO) when submitting BSCP28 Form F28/01 ‘Approval of Central Volume Allocated (CVA) Line Loss Factors (LLFs)’.","The proposed solution is to create a Part E of the F28/01 Form that would accompany Parts A and C (currently used by the PDSO), for every submission. Only one Part E would be required by a PDSO for the submission of the LLFs for multiple MSIDs.","−","CPC00359","ISG",null,"Approve"]
[957,"Information Relating to the Changing Energisation Status","ELEXON","2003-05-07","Currently, when the LDSO energises a Metering System as part of normal business, he sends the D0139 to the MOA and the Supplier. The MOA then sends the D0139 onto the HHDC. The Association of Meter Operators, during the development of BSCP514 ‘SVA Meter Operations for Metering Systems Registered in SMRS’ suggested that the MOA should always be responsible for informing both the HHDC and the Supplier of any changes to the Metering System. The MOA is responsible for Metering Data and should be the focal point for the interface with the Supplier and HHDC. Therefore the process should be amended so that the LDSO sends the D0139 to the MOA and then the MOA sends the D0139 onto the Supplier and the HHDC. This is consistent with the process for when the LDSO de-energises a Metering System as part of Urgent Metering Services and is supported by the DTC.","Make the changes to BSCP514 ‘SVA Meter Operation for Metering Systems Registered in SMRS’ as shown in attachment 1. (BSCP514, in its current form is effective on 28 August 2003). Corresponding Flow Diagrams within BSCP514 will also have to be updated. Remove endnote 3 from BSCP514. (This states that if the Metering System is being de-energised by the LDSO as part of an Urgent Metering Service, the LDSO only sends the D0139 to the MOA.) This will no longer be relevant as the process for energisation under Urgent Metering Services will be the same as the normal business process.\n",null,"CPC00314",null,"—","Withdrawn"]
[956,"Resolution of Inconsistency Over Presentation of NGC weekly forecasts","ELEXON",null,"NGC weekly (2-52 week) forecasts are received from NGC with the data identified by week number. This week number is converted into a week starting date for storage in the BMRA database. The week starting date is included with the week number for transmission in the relevant TIBCO message, and is also used to recalculate the week number for presentation on the Low Grade web site. It has recently emerged that whereas NGC use a convention in which the week starts on a Monday, the BMRA uses Sunday as the start of the week. As a result, the week starting dates being sent out in the TIBCO messages are incorrect (one day earlier than they should be). This is already leading to confusion over the week starting dates in the forecast data being sent out by TIBCO, as the BMRA expects the week starting date for week 1 of 2004 to be 4 January 2004 – whereas NGC’s week starting date for that week is 29 December 03 (because of the rules by which NGC decide whether there should be a week 53). The problem will become more widely visible, and potentially more acute, in December 03 when NGC begin sending forecast data for their week 53 of 2004 – which the BMRA will present as Week 1 of 2005. This may cause a number of problems, and it is not actually certain that the BMRA will be able to load the data for NGC’s Week 1 of 2005 when it arrives. It is suspected that the loader will fail because it will recognise the latter set of data as a duplicate.","Initial investigation has indicated that it will not be necessary to change any code in the BMRS, as the relevant functionality is parameter driven. However, it is felt that a CP is the appropriate way to deal with this issue, as it will be visible to participants when the TIBCO messages change from a Sunday start date to a Monday start date. It is also evident that the effects of making the change will need to be formally tested, in the same way as if a code change had been required. Additionally, in order to ensure that there is no ambiguity in the future, it is proposed that the IDD be amended to clarify the convention used and to make absolutely clear that for both the BMRA and for NGC, the week (for forecasting purposes) starts on Monday"]
[955,"Further definition of Timescales in BSCP514 ‘SVA Meter Operation for Metering Systems Registered in SMRS","ELEXON","2003-05-02","Currently, timescales for the majority of Supplier related processes to occur are unspecific in Supplier Volume Allocation (SVA) related Balancing and Settlement Code Procedures (BSCPs) since in the past the industry did not believe that this was necessary. During the production of BSCP514, in consultation with industry members, the industry members agreed that the timescales contained within BSCP514 should be better defined. However, this could not be completed under the scope of CP854 ‘Provision of a New Balancing and Settlement Code Procedure (BSCP) covering Meter Operator Agent Processes for Supplier Volume Allocation (SVA) Metering Systems’ since there was no mention in CP854 of specifying timescales in any more detail in BSCP514 than in other SVA related BSCPs.","Specify detailed timescales, where relevant, in terms of the maximum number of working days required to complete steps undertaken by Suppliers, Data Collectors, Meter Operator Agents and Distributors in BSCP514.\nIndustry views will be sought to define the precise timescales and wherever possible the MRASCo products will be used to determine timescales. ","SVG: 40","CPC00321/CPC00399/CPC00419","SVG","Nov 04 Release","Approve"]
[954,"Inconsistency Over Presentation of NGC weekly forecasts","N/A","2003-04-29","NGC weekly (2-52 week) forecasts are received from NGC with the data identified by week number. It has recently emerged that whereas NGC use a convention in which the week starts on a Monday, the BMRA uses Sunday as the start of the week. As a result, the week starting dates being sent out in the TIBCO messages are incorrect (one day earlier than they should be).",{"$nulls":3},"SVG","−","Rejected"]
[953,"Control over affirmation of metering system details (D0052)","Powergen","2003-04-24","D0052 is critical flow for ensuring correct settlements, “new connections” & changes to standing data, e.g. “annual recalculation of PC” as required under (BSCP 516). Currently there is no reject flow sent to the originator if the NHHDC agent cannot load the data. The manual return process i.e. e-mails or fax is problematic for both parties to segment & return to its original source.","Proposed new flow that will be initiated by the NHHDC & returned to Supplier via the DTN, thus ensuring its return to source for correction. There will need to be error codes defined corresponding to the data items within the original flow that can lead the Supplier to the data item requiring correction.",null,null,"SVG","−","Rejected"]
[952,"Clarification of Pre-Payment Meter reading Obligations","ELEXON","2003-04-23","BSCP504 3.4.1 footnote 76 states that the Supplier (or pre payment system) should send pre payment reads to the NHHDC no less than every 3 months. Pre payment readings are usually received much more frequently than this, possibly more than once a day. NHHDC Change of Supplier activities are contained in BSCP504 3.2.6.  3.2.6.10 states that if a valid meter read is obtained within the SSD-5 and SSD+5 window the New NHHDC should create a D0010 (meter read) and D0086 (Change of Supplier Read). If no valid read is obtained by SSD+8, a CoS read should be deemed using the METD and any historical data from the old NHHDC if there has also been a CoDC. D0086 reads that are deemed are usually less accurate than those created using a read obtained within the + or - 5 days.","CP0952 proposed to amend BSCP504.","−",null,"SVG","−","Rejected"]
[951,"Changes and Clarification to HHDA defaulting rules","ELEXON","2003-04-17","Modify a number of Code Subsidiary documents (BSCP503, BSCP508, PSL150 and the SVA Data Catalogue) to: apply a default consumption value of zero for Half Hourly export meters. Ensure that losses are added to the default. Clarify the derivation of the default value from the EAC of Last Resort","1. PSL150 ‘Half Hourly Data Aggregation’\nModify clause 5.1.14 so that it applies the principles outlined in clause 1.5.7.2 of PSL 130 ‘Half Hourly Data Collection’ to import sites only.\n2. PSL150 ‘Half Hourly Data Aggregation’\nAdd clause to 5.1 so that it applies the default value of zero on export sites where consumption is expected but not received. (i.e. When a D0235 – 998 exception is produced)\n3. BSCP 503 ‘Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’\nAdd a clarification to 4.3 c) stating that the value to be submitted to Settlements should be calculated in accordance with point 4 below.\n4. BSCP 503 ‘Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’\nChange “derive Estimated consumption” to “derive default consumption” so that it is clear that this is not an  estimate of the metering systems consumption.\n5. BSCP 503 ‘Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’\nAdd a clarification stating that the default consumption value used by the HHDA should be calculated by equally dividing the default EAC of last resort (currently 1500 MWh) equally over the year i.e. 1500/17520 irrespective of leap years. Rounded to the nearest kWh.\n6. BSCP 503 ‘Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’\nAdd a clarification to 4.3 c) stating that LLFs should be applied to any default submitted to settlements.","SVG: 32","CPC00321","SVG","Feb 04 Release","Approve"]
[950,"Removal of Redundant Flows From MDD","ELEXON","2003-04-09","The Market Domain Data Application (MDDA) currently produces a number of MDD flows from each publish which are now considered redundant. There are three versions of the D0278 flow one includes data for England and Wales only, one for Scotland only, and one for all three. In addition to this there are three respective versions of the D0227 flow. The D0278 was introduced with Teleswitch and has made the D0227 flow redundant. The D0227, although still created, is not distributed to any Market Participants or used by SVAA. A fourth version of the D0227 flow, known as the SSC extract file, is still required and is distributed to Market Participants. ","CP0950 seeks to delete the redundant versions of the D0227 flow from the MDD application in order to improve the efficiency of the MDD publications and remove files that are no longer required from the MDD system.","SVG: 30","CPC00319","SVG","Nov 03 Release","Approve"]
[949,"PAF Review - Updates to BSCP535 (Tech Assurance)","ELEXON","2003-04-01","Updates necessary to BSCP535 to implement the changes recommended by the Review of Technical Assurance for Suppliers and Supplier Agents as part of Phase 2 of the Review of the PAF. BSCP535 will be re-written to reflect a new approach to Technical Assurance (TA) that will focus on visits directed by a Scope document, targeted visits and post Certification visits.","CP0949 provided the updates necessary to BSCP535.",null,"CPC00312","SVG","2003-08-01","Approve"]
[948,"Upgrade to Oracle 8.1.7.4 for EAC/AA software","N/A","2003-04-01","CP891 proposed a change to the ELEXON-owned Non Half Hourly Data Aggregator (NHHDA) software, whereby it would be upgraded from Oracle version 8.1.7.1 to Oracle version 8.1.7.4. As most NHHDAs also perform the Non Half Hourly Data Collector (NHHDC) role, and hence run the Estimated Annual Advance/Annualised Advance (EAC/AA) software, it is necessary to upgrade the EAC/AA software to also run on Oracle version 8.1.7.4. This is in line with previous upgrades, to retain consistency between the Oracle versions that the two software systems utilise.","Logica to recompile and test the EAC/AA software to support Oracle 8.1.7.4.",null,null,"SVG",null,"Approve"]
[947,"Removal of References to Sending D0281 to NGC (BSCP508 & SVA Data Catalogue)","ELEXON","2003-03-31","References to the sending of D0281 from SVAA to NGC in BSCP508 and the SVA Data Catalogue should be removed, since NGC have requested that these reports are no longer delivered. This issue was highlighted as part of the SVA Agent’s review of BSCP508 v7.1 for Modification P91 ‘Extension to Data Provided to the Transmission Company in the TUoS Report’.  However, as the proposed change does not form part of P91 it is necessary for a CP to be raised to address the issue and thereby enable SVAA to sign on to the P91 changes to BSCP508. SVAA will continue to send the D0281 to Suppliers.","Remove references to D0281 from BSCP508 Sections 3.2.15 and 3.3.15 and the SVA Data Catalogue.","SVG: 37","CPC00385","SVG","June 04 Release","Approve"]
[946,"Inconsistency in the reporting of Metering Technical Detail","ELEXON","2003-03-26","There is an inconsistency between the CDCA URS and BSCP20 with respect to the reporting of Meter Technical Details (MTDs). The CDCA_I051 flow (Report Meter Technical Details) is a report sent to Meter Operator Agents, Registrants, Distribution System Operators (if relevant) and the Transmission Company as confirmation of the process of loading the MTDs as supplied by the MOA into the Central Data Collection System (CDCS).  However, BSCP20 only states that the Transmission Company should be notified.","Modify sections 3.1.11, 3.5.2 and 3.8.21 of BSCP20 to include Registrant, MOA and where relevant, the DSO in the “to” column.",null,"CPC00311",null,null,"Approve"]
[945,"Addition of \"Final Initial Settlement Run\" into BSCP01","Seeboard Energy Ltd","2003-03-26","All settlement tasks that are identified in Market Domain Data, expect Final Initial Settlement Run, are detailed as part of section 4.2 in BSCP 01. This details number of working days when these tasks are repeated for each settlement day.  ","CP0945 is proposing to add details for SF in order to provide a complete picture.","ISG: 33                 SVG: 33","−","SVG","June 04 Release","Approve"]
[944,"Interconnector Administrator Data Flows","National Grid","2003-03-20","The Interconnector Administrator (IA) is required under the BSC to submit a file of Deemed Metered Volumes within 2 working days of the Settlement Day for the Interconnector concerned. This requires the IA to have the necessary Interconnector BM Unit Registration details. Currently there is no provision within the IDD and therefore the IA currently relies upon the party registering the BM Units to provide the necessary information.","Provision of a separate data flow from the CRA to the IA.","ISG: 33","CPC00333","ISG","June 04 Release","Approve"]
[943,"Amendment to BSCP20","National Grid","2003-03-20","Currently there is no conclusive way of mapping the location on the circuit board of the metering by using the channel numbers in BSCP20/4.3b and BSCP20/4.3c. It is important to identify which circuit each outstation-channel is metering to be able to interpret CDCA reported metered data.","It is important to identify which circuit each outstation-channel is metering to be able to interpret CDCA reported metered data. It is necessary to define the circuit associated with each meter register id under 4.3b in a separate column (wide enough to include a reasonable description of what was being metered). This will then be mapped to the associated outstation-channel under 4.3c, to enable our systems to decode what is being metered.","ISG: 39","CPC00329","ISG","−","Rejected"]
[942,"Minor Corrections to BSCP507 and BSCP508","N/A","2003-03-19","Following the implementation of the SVA Documentation Batch Release in February 2003, errors in BSCP507 and BSCP508 have been identified by the SVA Agent in their commercial review and require correction at the next available opportunity.","In addition to correcting minor errors, the raising of this CP allows the SVA Agent to give formal agreement to BSCP507 v4.0 and BSCP508 v8.0, and thus also agreement to the changes included in the SVA Documentation Batch Release.","SVG: 27","−","SVG","Implemented","Approve"]
[941,"Add GSP Group information to the Supplier Agent appointment data flows and define new appointment rejection code value","ELEXON","2003-03-18","Modify the ‘Notification of Data Aggregator Appointment and Terms’ D0153 data flow and ‘Notification of Meter Operator or Data Collector Appointment and Terms’ D0155 data flow to include the GSP Group ID of the Metering System concerned. Add new ‘Rejection of Agent Appointment Code’ valid value to allow Supplier Agents to clearly inform Suppliers, in the ‘Rejection of Agent Appointment’ D0261 data flow, that their appointment was rejected due to the Agent detecting an invalid Supplier hub (i.e. Supplier Agent/Supplier/GSP Group/Distributor combination). This would be used when the Supplier Agent has yet to successfully complete the necessary BSC Entry Processes for that particular Supplier hub, or does not support the Metering System’s Supplier hub.","1) Modify the D0155 and D0153 data flows in the SVA Data Catalogue, to include the Metering System’s ‘GSP Group ID’ as illustrated in Annex A for the proposed changes to the DTC.\n2) Modify the SVA Data Catalogue to include the ‘Rejection of Agent Appointment’ D0261 data flow and the ‘Rejection of Agent Appointment Code’ data item.\n3) Introduce a new ‘Rejection of Agent Appointment Code’ valid value in the SVA Data Catalogue, to allow Supplier Agents to reject their proposed appointments if they detect an invalid Supplier hub. This is illustrated in Annex A for the proposed changes to the DTC.\n4) Modify the relevant CSDs to include an obligation on all Supplier Agents to:\n• accept or reject their appointment request from the Suppliers\n• check that they have successfully completed the necessary BSC Entry Processes when\nthey first receive an appointment request from the Supplier, and if they have not then\nto reject the appointment request.","SVG: 30","CPC00300/CPC00305","SVG","Feb 04 Release","Approve"]
[940,"Clarifications in BSCP02 and BSCP20","ELEXON","2003-03-18","CP821 ‘Improvements to Central Volume Allocation Proving Test Requirements’ which will be implemented in June 2003 introduces a new BSCP (BSCP02 ‘Proving Test Requirements for Central Volume Allocation Metering Systems’) and delivers associated amendments to BSCP20 ‘Registration of Metering Systems for Central Volume Allocation’. Following review of the two BSCPs, several areas have been identified where clarifications would be useful.","CP0940 proposed a number of clarifications to BSCP02.","ISG: 28","−","ISG","Nov 03Release","Approve"]
[939,"Clarification of NHHDC obligation to pass on EAC/AA data","ELEXON","2003-03-18","Raised from SIR R2106. BSCP504 3.3.11.5 requires that the NHHDC should send an AA and or EAC to the NHHDA and Supplier via a Metering System EAC/AA (D0019) dataflow.  Footnote 73 to BSCP504 3.3.11.5 states that \"the NHHDC will send the data (AA and or EAC) only to their respective Supplier / NHHDA\". This requirement would benefit from further differentiation between what should be sent to the old and new Suppliers respectively by the NHHDC (or, where concurrent with a change of NHHDC, by the old and new NHHDCs respectively).","Clarify that :-\n• the NHHDC (the old NHHDC on concurrent change of Supplier and NHHDC) should send the AA only to the old Supplier only; and\n• the NHHDC (the new NHHDC on concurrent change of Supplier and NHHDC) should send the associated EAC only to the new Supplier only.\nWhere the AA and EAC are those calculated from the Change of Supplier reading.","SVG: 28","CPC00300/CPC00339","SVG","Nov 03Release","Approve"]
[938,"Incorrect footnote reference in BSCP504 3.3.10.2","ELEXON","2003-03-17","The last clause of section 3.3.10.2 (Changes to SVA Metering System Standing Data) of BSCP504 relates to change of Profile Class where no reading has been obtained, and states that: \"If no meter reading required, confirm the effective date of the Profile Class change\". This is to be effected by a D0010 \"Meter Readings\" flow from the NHH Data Collector to the Supplier. There is a cross-reference in the \"To\" column to Footnote 34. This footnote states that \"The Supplier may choose to raise a dispute, where in the Supplier's view there is a difference of more than 250kWh from the original CoS reading\". The footnote is (correctly) referenced by section 3.2.6.12 - \"No later than 12 months after SDD, if the new Supplier wants to dispute the CoS reading prior to the Final Reconciliation Volume Allocation Run 34 \".","Change existing reference to footnote 34 to footnote:- \"The NHHDC will indicate there has been a change of Profile Class by sending a D0010 Meter Readings to the Supplier. In particular the following fields will be completed by the NHHDC : ‘Additional Information’ field - the NHHDC will confirm that the flow is a Profile Class change flow; if meter reading obtained, additionally the ‘Reading Type’ field will be completed - the NHHDC will select the ‘s’ - for ‘Special’ value. This combination of data will enable the Supplier to identify  that this is a change of Profile Class flow\".",null,"CPC00300",null,"—","Withdrawn"]
[937,"Operational Change to the Pool Application.","ELEXON","2003-03-03","Raised from Emergency Fix CP689.  This is a Software maintenance change to increase array size within code and makes no change to business functionality. Following successful implementation of the Unix 5.1 upgrade and before applying a change freeze for the Oracle 9i upgrade, we wish to implement an Operational Change to the Pool Application. ","This change is to provide a long-term solution to an intermittent problem with array overflow, causing program failure during the creation of report PA002REP (Pool NHH Demand Report). A long-term fix for this issue has been coded and tested in Pool Application Version 2.10.  We wish to implement this version at the earliest convenient opportunity, in practice on Thursday, 6th March 2003, following the daily production runs. This change will not have any impact on Market Participants.",null,null,"SVG",null,"Approve"]
[936,"Resolution of inconsistencies between MO & DC data","ELEXON","2003-02-27","Add a requirement to BSCP504 detailing the action to be taken by the new NHHDC, in the event of an inconsistency between the data provided by the Meter Operator and that by the old NHHDC on change of NHHDC. In the absence of sufficient additional information about whether the data from the Meter Operator or old NHHDC is correct, the new NHHDC should default the Standard Settlement Configuration (SSC) and associated register details, Measurement Class and Energisation Status, as appropriate, to those notified by the Meter Operator.","Add a requirement to BSCP504 detailing the action to be taken by the new NHHDC, in the event of an inconsistency between the data provided by the Meter Operator and that by the old NHHDC on change of NHHDC. In the absence of sufficient additional information about whether the data from the Meter Operator or old NHHDC is correct, the new NHHDC should default the Standard Settlement Configuration (SSC) and associated register details, Measurement Class and Energisation Status, as appropriate, to those notified by the Meter Operator",null,"CPC00300",null,"—","Withdrawn"]
[935,"Operational Review of BSCP42 (Business Continuity)","ELEXON","2003-02-18","In light of operational experience, it is now thought an appropriate time to carry out a wholesale review of the business continuity procedures to identify, where appropriate, more efficient and effective ways of working. The review will also look to bring some areas in line with working practice.","Carry out an operational review of the whole process, detailed in BSCP42 (Business Continuity). The end result will be a re-written and re-issued BSCP42.","ISG: 29","CPC00301","ISG","Nov 03 Release","Approve"]
[934,"Change to listing of failed instructions in the NHHDA system","N/A","2003-02-14","SIR1499\nIn the NHHDA system, filed instructions are currently listed in MPAN order. When new MPANS are received they are not necessarily higher than the ones already dealt with and as a result all failed instructions have to be checked from the beginning to ensure that all instructions are dealt with.","CP934 proposed to change the listing of failed instructions in the NHHDA system.",null,null,"SVG","−","Rejected"]
[933,"NHHDA and EAC/AA Systems – Management of System Security","ELEXON","2003-02-14","SIR1500\nUnder current practice there is no control over the management of NHHDA/EAC/AA system security other than by the database administrator. This is not acceptable under IT audit controls.","Ability for NHHDA to create new accounts, allocate roles to them, delete accounts, amend passwords, reset passwords, amend and reset user roles using Oracle forms via the front end. Existing passwords to be automatically renewed after 90 calendar days with a system generated random password of three alpha characters and three numeric notified to the user when the next log on. All of this functionality would be under the control of the System Manager.","SVG: 49","CPC00403","SVG","Feb 05 Release","Approve"]
[932,"Invalid Supplier Hubs","N/A","2003-02-14","SIR1840\nThere is no mechanism within the Stage 2 Trading Arrangements to ensure that the Supplier Agent appointments for metering systems correspond to a valid Supplier Hub. This issue was raised as part of the MDD Review and as a result MDD Review Recommendation 1.3.4 was raised.","See the description of the issue. ",null,null,"SVG","−","Rejected"]
[931,"Distinction between Data Retrieval and Data Processing within Data Collector Role","N/A","2003-02-14","SIR1927\nIt has been proposed that the Industry should recognise the existence of a last resort service for data retrieval (DR); this service is to be procured by the PESs. Such a service is a specific example of a generalised Data Retriever Service. Where this or any other Data Retriever is operational the outstanding parts of the current Data Collector role is known as a Data Processor.  Where a Data Retriever Service is subcontracted to more than one Data Collector it would be of benefit to Participants, and applicants, to eliminate redundant work in the Certification and Entry Process procedures.","See the description of the issue. ",null,null,"SVG","−","Rejected"]
[930,"DC  TO DA Market  Indicator (P0056001)","ELEXON","2003-02-14","SIR2111\nThe requirement for Market Indicator information serial P0056001 is not applicable to the HHDC - HHDA interface.  The serial presumes that the interface is an \"instruction\" flow using the Pool design logic of instruction processing.   This is true in the NHHDC - NHHDA interface, but in the HHDC - HHDA interface the data flow (D0036) is NOT an instruction processed flow. It is therefore not possible to provide meaningful data under this serial. The SIR is raised as a consequence of TS2/14/395 discussed at the TS2 meeting on 1 September 1999.","Amend BSCP533 Appendix 4.5 to change the reference from “DC to DA instructions” to read “NHHDC to NHHDA instructions”.","SVG: 40","−","SVG","−","Closed"]
[929,"Remove Performance Reports from ISRA software and products","ELEXON","2003-02-13","The ISRA software includes functionality to create a number of 'Pool Performance Reports': These reports are not produced or sent by ISRA, having been replaced by the PARMS and PARMS systems. This functionality has not been maintained for TA2000 (e.g. SIR R0295), and therefore cannot be guaranteed. However the ISRA documentation implies that the functionality is available and working.","Remove all reference to ISRA Performance Reports from all ISRA documentation. ","SVG: 32","−","SVG","Feb 04 Release","Approve"]
[928,"Remote NHH Data Collection.","N/A","2003-02-13","SIR2446\nThe existing legal framework for NHH data collection allows for remote meter reading but, unlike the legal framework for HH data collection, does not specify the frequency of Meter Advance Reconciliation where data is not collected from the primary register of the Metering System.  Additionally, the obligation for a NHH Data Collector to visit site to ensure that Annualised Advances are obtained (to carry out a Meter Advance Reconciliation) applies to all NHH metering systems, including those where remote meter reading is obtained from the primary register.","See the description of the issue. ",null,null,"SVG","−","Rejected"]
[927,"Governance of Change of Supplier disputes","N/A","2003-02-13","SIR2512\nBSCP501 \"PRS\" (via Appendix 4.2 - Erroneous Registrations) provides two avenues for resolving CoS disputes which means that the Supplier can use the MRA disputes process or seek redress through legal proceedings (sic).  However BSCP502 and SL130 \"HHDC\" makes no reference to disputes whereas BSCP504 and SL120 \"NHHDC\" have specific dispute obligations (2/3.2.6 of AP504 and 1.3.3 of SL120).","See the description of the issue. ",null,null,"SVG","−","Rejected"]
[926,"Provision of Current & Voltage Transformer Certificates","N/A","2003-02-13","SIR2596\nIf Current Transformer (CT) & Voltage Transformer (VT) test certificates are not made available to Meter Operators by PES Distribution businesses (or others), the Meter Operators are unable to calibrate their meters to allow for CT and VT errors or to demonstrate to the SSA that the complete Metering System is within acceptable accuracy limits specified in the Metering Codes of Practice. For this reason, the PPA, as Pool Policeman, requires Meter Operators to produce CT & VT test certificates for inspection by the TAA in accordance with the relevant Agreed Procedures although on a number of occasions they have not been able to produce them since these have not been forthcoming from PES Distribution Businesses.  This has led to non-compliances being recorded against Meter Operators by the Pool Policemen.","See the description of the issue. ",{"$nulls":3},"−","Rejected"]
[925,"The Timing and Frequency of Meter Readings from Prepayment M","N/A","2003-02-13","SIR 2613 The implementation of 1998 Programme CR148 has resulted in unclear obligations regarding the timing and frequency of meter readings from prepayment meters into settlements being input into BSCP504.   The proposal is to clarify these obligations so that they are consistent with the implementation options set out in SVG36/09.  BSCP504 should be amended to reflect the implementation options stated in paper SDG36/09:                                                                                                                                                                                           i) That Suppliers are permitted to reduce the frequency of pre-payment meter readings passed to the data collector using a Pool agreed and auditable algorithm; and\nii) That Suppliers are permitted to use an algorithm that selects the most recent reading at the end of every month to pass to the data collector a nominated period to pass to the data collector. And that that period may be fixed or aligned to a meter reading cycle by may be no longer than three calendar months","See the description of the issue. ",null,null,"SVG","−","Rejected"]
[924,"Missing requirement on data collectors to notify Suppliers","ELEXON","2003-02-13","SIR2690\nThe receipt of a D0052 data flow (Affirmation of Metering Point Settlement Details) by a NHHDC is the first point in the NHH data collection stream that metering systems are identified from a settlement perspective.  The NHHDC is obliged (Service Line SL120 sections 1.3.1.2 & 1.4.1.3) to validate the details associated with each Stage 2 metering system received from a Supplier.  The validation specifically refers to the attributes contained within the D0052. In practice many D0052 records fail validation [to be quantified].  The most significant from a settlement point of view is where the Supplier requests an invalid combination of Profile Class, Standard Settlement Configuration and GSP Group.  The SL does not oblige the NHHDC to notify the Supplier of these inconsistencies. This is an omission from the NHHDC obligations that should be rectified.","Service Line 120 be modified to place an obligation on the data collectors to notify the Suppliers where metering systems have failed validation. BSCP504 be modified to include a response to Suppliers using a new data flow where records contained in a D0052 have failed validation. See appendix B for the proposed wording. Create a new data flow, manual or electronic (see appendix B) to enable the data collectors to respond to Suppliers using a common mechanism.\nNote that the solution suggested is intended to be utilised by NHHDCs to report invalid contents within a D0052, but would also be suitable for an HHDC to perform the same function after validating the contents of a D0289. Note that the proposed change to the DTC includes an instance of this data flow from HHDC to Supplier","−",null,"SVG","−","Rejected"]
[923,"Operational Review of BSCP509 - Change to Market Domain Data","ELEXON","2003-02-11","BSCP509 was written prior to NETA Go-Live and was primarily based on its predecessor from the days of the Electricity Pool, AP509. Some slight amendments were made when the document was re-badged for NETA Go-Live, however the document remained largely unchanged. It is now thought to be an appropriate time to bring the document in line with current working practices which have been adapted and refined over the course of the last 18 - 20 months. The Supplier Volume Allocation Agent (SVAA) is also keen to ensure that the processes outlined in BSCP509 are aligned more closely with actual working practices. In addition to this, an audit issue was raised by PwC which questioned the 'Quality of instruction in BSCP509'.","Perform an operational review of BSCP 509 and all sections contained therein. It is hoped that a number of redundant processes will be removed from the document and that all other processes will be updated to reflect modern working practice.","SVG: 30","CPC00325","SVG","Nov 03 Release","Approve"]
[922,"Clarification of use of data by NHHDC","ELEXON","2003-02-06","CP768 changed BSCP504 to clarify that Change of Supplier readings (D0086 data flow) must be calculated using the historical data provided from the old NHHDC. ","CP0922 proposes to amend this to specify that the historical data used must be from the old NHHDC immediately preceding the current appointment.","SVG: 27","CPC00285","SVG","Implemented","Approve"]
[921,"NGC Notification Processing of MIL/MEL Messages","ELEXON","2003-02-05","Currently the BMRS processes messages received from NGC as soon as they are received in accordance with their Service Level Agreement and the BMRA User Requirement Specification. A problem has been identified with processing files in this manner which from time to time affects the processing of Gate Closure Files and Re- Declarations of MIL and MEL. There are two types of MIL and MEL files that are sent by NGC - the initial values which arrive just after Gate Closure and contain values for all BM Units for the Gate Closure Settlement Period only; and MIL/MEL Re-declarations for individual BM Units, which can contain values for any period from Gate Closure to the current period.","Review comments for the old CP suggested that NGC simply send the Gate Closure and Redeclaration files in the correct order. NGC have stated that it is not practical to simply send files in the correct order as they are generated by 2 separate systems with Gate Closure files coming\nfrom the EDT system and Re-declarations of MIL/MEL coming from EDL. As a result an alternative\nway forward has been suggested to ensure that the files are processed in the correct order by the BMRS. It is proposed that the BMRA will continue to process files in order of receipt, which means that a Gate Closure file may be processed after a subsequent Re-declaration. However, the process that loads Gate Closure MIL/MEL data will be changed to ignore any MIL/MEL data which has been superseded by a subsequent Re-declaration (i.e. one with a later NGC ‘Notification Date/Time’) that is already on the database.",null,null,"ISG",null,"Approve"]
[920,"Distribution Line Loss Factors for new LLFC","ELEXON","2003-01-30","SIR2401\nThere is no process in BSCP509 - Changes to Market Domain, to check that distribution Businesses have supplied Distribution Line Loss Factor Classes (LLFC) are added to Market Domain Data (MDD)",{"$nulls":3},"SVG","−","Rejected"]
[919,"Generation Line Loss Factors","ELEXON","2003-01-30","SIR631\nThe ISRA system is not able to handle LLFs for less than 1.0.  A temporary fix is to be implemented for IMO which involves changing BSCP528 to prevent LLFs less than 1.0 being used in Stage 2 Settlements.",{"$nulls":3},"SVG","−","Rejected"]
[918,"Verification of authorised signatures by the FAA","ELEXON","2003-01-28","The FAA currently receives no tangible confirmation when changes to category M and N signatories for Trading Parties are registered with the CRA.  A process should be established whereby all changes to category M and N signatories should be copied to the FAA either by fax or email.  The FAA will maintain these records for validation purposes when handling requests from Parties.","Amend the IDD to include signatures as part of CRA-F002 content.\n",null,"CPC00369","ISG",null,"Approve"]
[917,"Reporting of upheld Trading Disputes on the BMRS","ELEXON","2003-01-22","There is currently no functionality in the BMRA systems to report notices of Upheld Trading Disputes relating to Credit Default on the BMRS.  ELEXON need to report such messages on the BMRS in order to be in compliance with the Code.  Although there have been no cases of Upheld Trading Disputes relating to Credit Default, it is important to develop such functionality in case it is required in the future.","A new interface will be developed to allow ELEXON to send notices of upheld Trading Disputes relating to Credit Default to the Balancing Mechanism reporting Agent (BMRA), which will then be automatically published on the BMRS. The Panel will need to be asked to determine that upheld Trading Disputes relating to Credit Default are capable of being published on the BMRS in accordance with Section V4.3.1 of the Code. A notice will need to be posted on the BSC Website and each Party and the Authority will be informed in accordance with Section V4.3.2 of the Code that upheld Trading Disputes relating to Credit Default will be published on the BMRS. Note that pending a modification to the Code, upheld Trading Dispute notices relating to Credit Default will still need to be published on the BSC Website as well as the BMRS following the implementation of this CP.",null,null,"ISG","−","Rejected"]
[916,"Timing of the SAAI006 flow from the IA","ELEXON","2003-01-21","There is an inconsistency between the BSC and the requirements in BSCP04. The BSCP requires the Expected Transfer for each Interconnector BM unit to be sent to the SAA 'By 16.00 on the WD following the SD'. It is suggested that this text should be changed to read 'By 24.00 on the WD following the SD'. A new requirement needs to be incorporated into the table for a IA to contact ELEXON if they want to revise BM Unit volumes after the IISR for the relevant Settlement Day.","It is suggested that this inconsistency should be resolved by changing the obligation in BSCP 04.\nIn Section 3.1 of the BSCP table reference 3.1.1 requires the Expected Transfer for each Interconnector BM unit to be sent to the SAA ‘By 16.00 on the WD following the SD’. It is suggested that this text should be changed to read ‘By 24.00 on the WD following the SD’. As a consequence table reference 3.3 will need updating. A new requirement needs to be incorporated into the table for a IA to contact ELEXON if they want to revise BM Unit volumes after the IISR for the relevant Settlement Day.",null,"CPC00304","ISG",null,"Approve"]
[915,"Processing of late and revised SAA I006 files from IA","ELEXON","2003-01-21","Presently the SAA system is set up to automatically process any late, or revised, SAA I006 flows sent from Interconnector Administrators (IA) to the SAA. This process is not compliant with the Balancing and Settlement Code. Section U2.5.1 states that 'Relevant BSC Agents and relevant Parties may not adjust settlement data except in accordance with section 2.5'. Section U2.5.3 states that unless the data was provided on behalf of a particular Party (where it can be changed under certain circumstances with the Party's agreement), it can only be changed with the consent of BSCCo after the settlement data is has been provided to Parties","The BSC Agent should notify ELEXON where a SAA I0006 file is not received from the Interconnector Administrator in compliance with BSCP04 and the Code Section R7.4. The SAA has an obligation to chase the IA for any late file(s) and confirm a valid file has been received before the Initial Information Settlement Run (IISR), where the late/missing file has already been reported to ELEXON. Where the file is not available by the IISR the SAA should seek confirmation from ELEXON that they can proceed with the IISR as dictated by Section U2.5 of the Code. Where a revised, or late, file is received from an IA after the IISR report has been issued for the relevant Settlement Day (s), the SAA should report this to ELEXON and ask what action should be taken. ",null,null,"ISG",null,"Approve"]
[914,"BSCP504 and SVA DC inconsistency","ELEXON","2003-01-21","SIR R2660 was accidentally removed from the SVA DC although its corresponding data flow is included in BSCP504.  This change was lost in the conversion to NETA."," CP0914 is proposing to re-instate the change.",null,null,"SVG",null,"Approve"]
[913,"Clarification of AA / EAC data to be sent by the NHHDC","ELEXON","2003-01-21","Lack of clarity in the current requirements for the provision of consumption data to respective NHHDA on change of aggregator appointment, has led to a majority of NHHDCs sending 'AA/EAC pairs' to both old and new NHHDAs. This result in either or both NHHDAs receiving consumption data that is not applicable to them and, as such, excessive numbers of exceptions are being reported to Suppliers via DTC flow D0095 as part of the NHHDA Check Data Collector Data (CDCD) function. (The exceptions in question are E03/E04 exceptions, indicating the receipt of an AA/EAC respectively which does not overlap with the DA's appointment).","Clarify BSCP504 in line with the proposed solution described in Attachment B, as agreed by NHHTAG (paper NHHTAG/23/157) and endorsed by TS2 (paper TS2/33/863).","SVG: 27","CPC00285","SVG","Implemented","Approve"]
[912,"Changes to Half Hourly Meter Technical Details - D0268.","ELEXON","2003-01-15","The proposed changes are intended to provide remedial action to correct errors and\nomissions within the current version of the D0268 “Half Hourly Meter Technical Details” data\nflow. These changes will enable Half Hourly Meter Operator Agents to fully populate the\nD0268 with all the relevant information about Metering Systems, (e.g. multipliers and\nmethods of communication)","Following a major review of this data flow by the ‘D0268 Working Group’, the following\nitems are proposed for inclusion within the D0268: Feeder Status; Complex Site Indicator;\nMeter Asset Provider Id; Outstation Multiplier; Event Indicator; Meter COP Issue Number;\nDial In/Dial Out Indicator; and Modem Type. It is proposed that the following items are\nremoved: Measurement Class Id (See also MRA WPPS CP 0059); Energisation Status. The\nfollowing items have been amended: Outstation PIN; Communications Method; Meter COP;\nOutstation Password A, B & C; Previous MPAN Core; Previous Outstation Id; CT Ratio;\nChannel Number; Effective From Settlement Date; and Baud Rate.","SVG: 25","CPC00268","SVG","2003-08-01","Approve"]
[911,"Minor correction to ECVAA URS F005 and F006","ELEXON","2003-01-13","In describing the long day clock change rules there is an incorrect reference to 03:00 GMT to identify the start of period 7 of the long day and 03:00 local time for the start of period 5 of the normal day.","Both these references to 03:00 (local time and GMT) should be changed to 02:00 (local time and GMT).",null,null,"ISG",null,"Approve"]
[910,"Withdrawal of Meter Readings Post-Final Reconciliation","ELEXON","2003-01-10","The process for withdrawing meter readings, as defined in BSCP504, does not state what action should be taken when Final Reconciliation has already taken place for the date of the last valid reading. SIR2831.","Amend BSCP504 to clarify the rules around withdrawing Meter readings around the Final Reconciliation\nRun stage.","−","CPC00285/CPC00410","SVG","−","Rejected"]
[909,"Deemed Reads where Initial Reads invalid or unattainable","ELEXON","2003-01-09","SIR2832.\nWhilst there are defined procedures for deeming reads where valid Final Reads are unobtainable, there is currently no equivalent process for the situation where valid Initial Reads are unobtainable. A number of instances of missing or invalid Initial Reads have been reported and this has been noted as an operational issue. An agreed principle was that \"where data is missing or incorrect and processes cannot be operated without this data, estimates can be utilised, preferably using a deemed reading process\".","Amend BSCP504 and SL120 (as appropriate) to enable readings to be deemed when a valid Initial Reading cannot be obtained.","SVG: 40","CPC00285","SVG","−","Rejected"]
[908,"NHH New Connections Sequences.","N/A","2003-01-09","SIR2833.\nThere is an absence of consistency in the processes used for recording New Connections. It is necessary to improve the co-ordination and timeliness of these procedures with respect to the allocation of SSCs, actual meter installation dates and the setting of Supply Start Dates particularly where actual meter installation postdates SSD. The lack of consistency has resulted in Market Participants determining their own processes to deal with the situation when the Non Half Hourly Meter Operator (NHH MO) installs metering equipment after the Supply Start Date (SSD). This has resulted in inconsistent procedures being used across the market.","See the description of the issue. ","−",null,null,"−","Rejected"]
[907,"Security concerns surrounding use of Oracle SYS user","ELEXON","2003-01-09","The current approach to upgrades of the NHHDA & EAC/AA software requires user organisations to log on as the Oracle SYS user raising implications from an IT security & controls perspective.  The approach to upgrades of the Pool software requires the user organization to log on as the Oracle SYS user.  Connecting to an Oracle database as SYS allows the user to manipulate the data contained in the data dictionary tables- the comprehensive set of tables and views internal to Oracle.  These provide a vital source of information for the RDBMS itself, and are used internally by Oracle to manage all objects contained in the database.  In the event of an uncontrolled error being experienced during upgrade, user organizations upgrading as SYS run the risk of corrupting the data dictionary.  If this was to occur a full database recovery would be required which could take several hours to complete.","Change upgrade script so that the SYS password will only be required when creating a new database or recreating an existing database.",null,"CPC00296",null,"—","Withdrawn"]
[906,"Revision to the Minimum Registration Period","ELEXON","2003-01-09","To more closely align the registration periods for those customers with sites trading in both Central Volume Allocation (CVA) and Supplier Volume Allocation (SVA) trading arrangements.","Reduce the 20WD minimum period for Change of Supplier only for sites registered and\ntraded in CVA to 5WD.","−","CPC00337",null,"−","Rejected"]
[905,"Derivation and validation of EACs.","N/A","2003-01-09","Clarity is required in the legal framework over the process for Suppliers calculating EACs for Half Hourly Metering Systems.  Additionally, clarity is required over how HHDCs should validate EACs that they receive from Suppliers. This was SIR3098.",null,"−",null,null,"−","Rejected"]
[904,"Change to SVA Data Catalogue flow D0030","ELEXON","2003-01-09","SVA Data Catalogue is inconsistent with the Data Transfer Catalogue (DTC) in the detail of data flow D0030 (Non Half Hourly DUoS Report)","CP0904 aimed to correct SVA Data Catalogue.","SVG: 27","CPC00285","SVG","Implemented","Approve"]
[903,"Incorrect reference in BSCP531","ELEXON","2003-01-08","BSCP531 refers to BSCP43 but this BSCP does not exist.   This needs to be removed from the BSCP and the BSCP forms.","Remove all references to BSCP43.","−",null,null,"−","Rejected"]
[902,"Revision to the Minimum Registration Period (CRA, CMRS)","ELEXON","2003-01-02","To more closely align the registration periods for those customers with sites trading in both Central Volume Allocation (CVA) and Supplier Volume Allocation (SVA) trading arrangements.","Reduce the 20WD minimum period for Change of Supplier only for sites registered and\ntraded in CVA to 5WD. This will impact process 1.3 and 3.3.1 of BSCP20 ‘Registration, Commissioning and Proving of Metering Systems for Central Volume Allocation’. It is believed that there is no impact on the Balancing and Settlement Code Section K or the CRA Service Description (CRA SD v3.0).","−",null,null,"−","Rejected"]
[901,"Unix 5.1 upgrade","ELEXON","2002-12-19","SIR2401 There is no process in BSCP509 – Changes to Market Domain, to check that distribution Businesses have supplied Distribution Line Loss Factor Classes (LLFC) are added to Market Domain Data (MDD). The forthcoming Unix 5. 1 upgrade will involve the implementation of a new version of the ISRA application and all the DASM and MASM application software. In conjunction with this change we wish to implement some operational improvements in the new version of the Data Marshalling application (Version 2. 00), as follows: – provide warning of hanging FPT processes, remove environment hard coding from Unix shell scripts, provide audit log of changes, Pro*C to display version at run time, Security Admin option added to main menu. These changes will not have any impact on Market Participants and there are no changes required to the Detailed Functional Specification.","The forthcoming Unix 5.1 upgrade will involve the implementation of a new version of the ISRA application and all the DASM and MASM application software. In conjunction with this change we wish to implement some operational improvements in the new version of the Data Marshalling application (Version 2.00). These changes will not have any impact on Market Participants and there are no changes required to the Detailed Functional Specification.","−",null,"SVG","Implemented"]
[900,"Change of address in BSCP601","ELEXON","2002-12-19","BSCP601 'Metering Protocol Approval and Compliance Testing' has ELEXON's old address in forms F601/03 and F601/05. Replace this with ELEXON's new address","Replace the address in forms F601/03 and F601/05 with:\nELEXON Limited\n4th Floor\n350 Euston Road\nLondon\nNW1 3AW\nOR\nRemove the address completely from these forms.","−",null,null,"−","Rejected"]
[899,"Changes to the SVA MAR Requirements","ELEXON","2002-12-17","The Meter Advance Reconciliation (MAR) requirements for the Supplier Volume Allocation (SVA) market, as described in BSCP502 'Half Hourly Data Collection for SVA Metering Systems Registered in SMRS' are currently unclear.","CP0899 proposed amendments to a number of Code Subsidiary Documents (CSD) to better define the MAR requirements.","SVG: 25","CPC00260","SVG","May 03 Release","Approve"]
[898,"Provision of Instruction Failure Information to Supplier","Npower Ltd","2002-12-16","It appears to be a flaw in the SVA Arrangements that the information in the D0023 is not sent to the Supplier as well as the DA, since this is relevant to the diagnosis and correction of a significant proportion of D0235 problems. A similar issue may also apply in the Non Half Hourly process.","It is proposed that BSCP503 (and potentially PSL150, as well as the corresponding NHHDA\ndocuments) should be amended to require the provision of the Instruction Failure Report\n(D0023) or the relevant information contained in it to the Supplier as well as the SMRS.","SVG: 40","CPC00285","SVG","−","Rejected"]
[897,"Clarifications to BMRA URS and SAA URS","ELEXON","2002-12-16","Clarifications are required to changes made to the BMRA URS and the SAA URS when implementing P18A and P72.","Amend the BMRA URS and SAA URS to add the clarifications specified in Appendix 1.","ISG: 24",null,"ISG","Feb 03 Release","Approve"]
[896,"Amendment to BSCP75","ELEXON","2002-12-10","When carrying out a registration transfer in accordance with BSCP68, Aggregation Rules must be submitted via BSCP75. The CDCA enters the Aggregation Rules into their systems at different times depending on whether they are associated with a Registration Transfer or with a new registration. Therefore, when Aggregation Rules are submitted, there needs to be an indication on the relevant form as to whether they are associated with a Registration Transfer or a new registration.","Add a tick box to BSCP75, form BSCP75/4.2 ‘Registration of Meter Aggregation Rules for Volume Allocation Units’, and the following wording:\nTick box if this is a Registration Transfer in accordance with BSCP68.\nThis should be placed between the section for Authorised Signatory and Section 1.",null,null,"ISG","−","Rejected"]
[895,"Clarifications to BSCP502","ELEXON","2002-12-10","A number of changes are required to BSCP502 'Half Hourly Data Collection for SVA Metering Systems Registered in SMRS' to clarify a number of issues relating to proving tests.","CP0895 proposed changes to BSCP502. ","−",{"$nulls":3},"Rejected"]
[894,"Erroneous Registration and Change of Agent","ELEXON","2002-12-10","If there has been an erroneous registration, PSL120 1.3.3.9 sets out the criteria to the use of a 1kW advance if both Suppliers agree to do so. Clarify within PSL120 1.3.3.9 that a concurrent Change of Supplier (CoS) and Change of Agent (CoA) does not preclude Suppliers from using a 1kW advance","Clarify within PSL120 1.3.3.9 that a concurrent CoS and CoA does not preclude Suppliers\nfrom using a 1kW advance.","SVG: 37","CPC00381","SVG","June 04 Release","Approve"]
[893,"Changes to the PAB Escalation Cycle in BSCP534","ELEXON","2002-12-10","Changes to the existing PAB Escalation Cycle in order to address concerns raised by Stakeholders. These changes have been approved by the Performance Assurance Board and are now submitted to the Change Process.","A new Escalation Cycle with 7 Severity Levels that will deliver the following benefits:\n• The Severity Level serves as a clear record of the importance attached by the PAB to an issue, regardless of whether a participant is escalated in a given month.\n• The seriousness of PAB Escalation is maintained because it does not become a routine activity.\n• PAB flexibility in choosing the action most likely to be effective is maintained.\n• Reporting to the PAB and the Panel will be clearer, as it will be based on a Severity Level and escalation activity, rather than an up-and-down Escalation Level.","−","CPC00272/CPC00302","SVG","Implemented"]
[892,"Changes to the flagging of Actual and Estimated Data by the Half Hour Data Aggregator","ELEXON","2002-12-10","Currently, when the Half Hourly Data Collector (HHDC) has flagged one or more Settlement Periods (SPs) in a day as estimated, the Half Hourly Data Aggregator (HHDA) must flag the whole of that day as estimated. (i.e. the data transferred from the HHDA to Supplier Volume Allocation Agent (SVAA) will be summated by the Half Hourly MSID Count per Consumption Component Class.) ","CP0892 seeks to amend this by requiring the HHDA to flag both actual and estimated data within day. Consequently, the data transferred from the HHDA to (SVAA) will be summated by the Half Hourly MSID Count per Consumption Component Class per Settlement Period. This CP has been raised by ELEXON on behalf of the data estimation group (instigated by the Supplier Volume Allocation Group (SVG).","SVG: 30","CPC00275","SVG","2004-08-01","Approve"]
[891,"Upgrade to Oracle 8.1.7.4 for NHHDA software","ELEXON","2002-12-03","There is currently an issue with the ELEXON-owned Non Half Hourly Data Aggregator (NHHDA) software, whereby A12 exceptions (missing PRS data) are reported for some metering systems even though the metering systems do have data in the database. After extensive testing, it was established that the problem is resolved when the Oracle version, currently at version 8.1.7.1, is upgraded to Oracle version 8.1.7.4. As a result, it will be necessary to recompile and test the NHHDA software to support Oracle version 8.1.7.4 to ensure that there is no impact on Settlements.","Logica to recompile and test the NHHDA software to support Oracle 8.1.7.4.","−",null,null,"Implemented"]
[890,"Data Clarification from previous appointment by NHHDC","ELEXON","2002-12-02","Some NHHDCs have been deeming the Change of Supplier (CoS) readings during a coincident COS/CoA using historical data from an earlier appointment (i.e. not the appointment immediately preceding the CoS/CoA) to the Metering System where the old agent has failed to provide the meter history. It this situation the NHHDC will be unaware of any changes to the metering system that have occurred during the old agents registration and the data being used to calculate the deemed reading will be out of date resulting in questionable readings. This has caused inaccurate consumption to enter Settlements (sometimes contributing to the excessively large EAC/AA issue) where the new Agent holds out of date information. This can also cause an inaccurate final read for the old Supplier, an inaccurate starting read for the new Supplier and an inaccurate read for the new NHHDC to use for future validation.","BSCP504 3.2.6.11 states that on Change of Supplier, if no CoS read has been obtained by SSD+8, the new NHHDC should:\nCalculate a deemed meter reading for the SSD, based on the historic data provided by the old NHHDC (where applicable) and the METD provided by the MOA.\nA footnote is required to clarify, as follows:\nThe new NHHDC should not use data from a previous appointment to calculate the deemed meter reading unless the agent has had contiguous appointments up to the deemed reading date (CoS Date).","−",null,null,"−","Rejected"]
[889,"Revision to the ‘TA2000’ and ‘NHH Agent Competition’ text within BSCP511 ‘Entry Process - Supplier Meter Registration Service and BSCP512 ‘Entry Processes - Supplier’","ELEXON","2002-11-19","BSCP511: Section 1.1.6 refers to the use of the SMRS Entry Process to support the introduction of NHH Agent Competition.  This text is no longer relevant and should be removed. Section 3.1.10 again refers to NHH Agent Competition and the setting of the date when a hub can commence Change of Agent activities. This text is no longer relevant and should be removed. Appendix 4.4, Section 4.4.2 'SMRS Functional Tests for Non-Half Hour' refers to 'Agents wishing to undertake competitive change of NHH agent'. This text is no longer relevant and should be removed. As a consequence of the above changes, it is proposed that a generic statement is added to Section 1 'Introduction' to reflect actual market operation. BSCP512: Section 1.1.6 refers to the use of the Supplier Entry Process to support the introduction of NHH Agent Competition. This text is no longer relevant and should be removed. ","CP0889 proposed amendments to BSCP511 and BSCP512. ","SVG: 25","CPC00267","SVG","2003-08-01","Approve"]
[888,"ECVNA Authorisation Terminations Effective on Receipt","ELEXON","2002-11-15","Section P of the Code requires that any Authorisation Termination Request submitted to the Energy Contract Volume Aggregation Agent (ECVAA) be effective on receipt by the ECVAA. This is inconsistent with the lower level documentation such as the ECVAA User Requirements Specification (URS) and the relevant BSCP (BSCP 71 'ECVNA and MVRNA Registration, Authorisation and Termination'), which require 1 calendar days notice of the Authorisation Termination. In addition to this, the Code Subsidiary documents require amending to reflect the requirement contained within the Code for a notification agent as well as one of the two relevant counter Parties to be able to terminate an Energy Contract Volume Notification Agent Authorisation (ECVNAA).","The first solution proposes a new manual process, which represents the minimum change required to the ECVAA systems to allow it to fulfil its obligations as set down in the Code.\nThe second solution proposes to replace the manual interface with an automated electronic version, according with the format outlined in the ECVAA URS and IDD Part 1 for the ECVAA-I002 (ECVNA Authorisation Termination) and ECVAA-I003 (MVRNA Authorisation Termination). The ECVAA-I002 and ECVAA-I003 format also include the relevant data items / structure for requesting the Authorisation of a notification agent and for requesting a Key Change and the ECVAA-I007 and ECVAA-I008 format also include the relevant data items / structure for feedback regarding the request for the Authorisation of a notification agent and for a request for a Key Change.","−",null,null,"Implemented"]
[887,"Update to BSCP 508 File - Re-send Requests","ELEXON","2002-11-13","There are no processes defined to describe how a Participant should request file re-sends from the SVA Agent for either Daily Profile Production Files or Volume Allocation Files. File re-send requests are currently handled on an ad-hoc basis through the PMS and EARS systems at ELEXON and Cap Gemini respectively. ","It is proposed that the current procedure be formally documented in BSCP 508 to handle the processing of file re-send requests. The proposal deals with both Daily Profile Production File requests and Volume Allocation File requests in the same way.","SVG: 28","CPC00296","SVG","Implemented","Approve"]
[886,"ECVNA and MVRNA Authorisation and Key Change","ELEXON","2002-11-12","Currently, the notification agent Authorisation Request and Key Change Request are undertaken via a manual process defined in BSCP 71 ‘‘ECVNA and MVRNA Registration, Authorisation and Termination’, using the forms contained within that BSCP. ","It is intended to change the procedure for undertaking notification agent Authorisation Requests and Key Change Requests from being a manual process to being an automatic process.  This would include the associated feedback.","−",null,null,"−","Rejected"]
[885,"ECVNA Authorisation Terminations Effective on Receipt","ELEXON","2002-11-12","Section P of the Code requires that any Authorisation Termination Request submitted to the Energy Contract Volume Aggregation Agent (ECVAA) be effective on receipt by the ECVAA.  This is inconsistent with the lower level documentation such as the ECVAA User Requirements Specification (URS) and the relevant BSCP (BSCP 71 'ECVNA and MVRNA Registration, Authorisation and Termination'), which require 1 calendar days notice of the Authorisation Termination.","The intent of CP0885 is to replace the manual interface with an automated electronic version,\naccording with the format outlined in the ECVAA URS and IDD Part 1 for the ECVAA-I002 (ECVNA Authorisation Termination) and ECVAA-I003 (MVRNA Authorisation Termination).","−",null,null,"−","Rejected"]
[884,"ECVNA Authorisation Terminations Effective on Receipt","ELEXON","2002-11-12","Section P of the Code requires that any Authorisation Termination Request submitted to the Energy Contract Volume Aggregation Agent (ECVAA) be effective on receipt by the ECVAA.  This is inconsistent with the lower level documentation such as the ECVAA User Requirements Specification (URS) and the relevant BSCP (BSCP 71 'ECVNA and MVRNA Registration, Authorisation and Termination'), which require 1 calendar days notice of the Authorisation Termination. In addition to this, the Code Subsidiary documents require amending to reflect the requirement contained within the Code for a notification agent as well as one of the two relevant counter Parties to be able to terminate an Energy Contract Volume Notification Agent Authorisation (ECVNAA).","The ECVAA system requires amendment to enable within day terminations of Authorisation.\nThe NETA Data File Catalogue, ECVAA Service Description and associated ECVAA system documentation should be amended to include reference to the ability for the notification agent to submit Authorisation Termination Requests.","−",null,null,"−","Rejected"]
[883,"Revise staff availability hours for SMRS operational enquiry","ELEXON","2002-11-08","Reduce the hours that the SMRS enquiry service is available by one hour. This will affect the Supplier's ability to raise operational queries with the SMRS after 17:00 hours.","CP0883 proposed to amend: PSL160 ‘Supplier Meter Registration Service’, Section 2.1.1 to change service hours from “09:00 and 18:00 hours”, to “09:00 and 17:00 hours” and to remove the reference to Working Day from Section 1.6 of BSCP501 ‘Supplier Meter\nRegistration Service’.","SVG: 24",null,"SVG","−","Rejected"]
[882,"Populating the Energisation Status in the D0055 where the in","ELEXON","2002-11-08","Align the SVA Data Catalogue with the Data Transfer Catalogue to ensure that the Supplier provides the SMRS with the Energisation status for the change of supplier.","Modify the SVA Data Catalogue, Volume 1 as follows:\nD0055 ‘Registration of Supplier to Specified Metering Point’\nAdd a new rule at the end of the dataflow to read:\n“When data item, ‘Instruction Type’ is populated with the value ‘SP04’ (Change of Supplier Request) then the data item ‘Energisation Status, shall be populated.”\nThere is no proposal to amend BSCP501.","SVG: 24",null,"SVG","−","Rejected"]
[881,"Provision of SAA-I014 Variant 2 (S0142) to BSC Parties","Innogy Plc","2002-11-07","The BSC sections V3.2.2 and V3.2.3, in conjunction with Annex V-1, states that the Settlement Reports (SAA-I014), including the sub-flow sent to the Transmission Company (S0142), should be available to any Party on request through BSCP 41 flexible reporting requirements. An interim solution has been put in place whereby ELEXON send the S0142 to requesting Parties via e-mail. CP712, (to be implemented in Release 2A) implements an enduring solution and provides for the NETA Central Services Agent to provide a down-load facility of the S0142 from the Low Grade Server. The way that flow versioning has been implemented, any Party receiving a copy of another Party’s S0141 report, receives the version of the report that is generated for the owing\nParty. In the case of S0142 if NGC decide to change the version of the S0142, then any Party receiving the S0142 will also receive the new version. This will have a significant impact on those Parties that have requested to receive the S0142 and creates a dependency between Parties and NGC. ","CP0881 proposes that a new flow is created that has the same content and structure as the S0142,  is under the \"ownership\" of BSC Parties, is not linked into NGC's version changes and is available to 'Any Party (on request)'.","ISG: 39","CPC00401","ISG","−","Rejected"]
[880,"Transfer of Reading History after Change of Profile Class","ELEXON","2002-11-04","On change of Non Half Hourly Data Collector (NHHDC), the old NHHDC is required to send the meter reading and associated AA/EAC history. The minimum historical data requirements are defined in Appendix 4.8 of BSCP Procedure BSCP504. As a minimum, data should be sent \"back to and including the latest of\" a number of events including change of Profile Class. On change of Profile Class, it is not mandatory to obtain a reading, as an Annualised Advance can be calculated for a meter advance period that spans the change. As some NHHDCs are able to effect a change of Profile Class without the need for a reading, this can result in no readings being transferred on change of NHHDC. This can result in periods without an Annualised Advance, or a less accurate Annualised Advance, if the new NHHDC deems a reading for the Profile Class change.","An amendment to BSP504 Appendix 4.8 to the effect that, where the \"bounding event\" of the historical data transfer is the latest change of Profile Class and the change was carried out without a reading, the reading history will comprise the reading prior to the change of Profile Class.","−",null,null,"−","Rejected"]
[879,"Increase  size of the Meter Id in the SVA Data Catalogue","ELEXON","2002-10-30","Increase the field size for the Meter Id (Serial Number) from 10 characters to 16 characters in the SVA Data Catalogue Volume 2.","Make the changes to the SVA Data Catalogue, Volume 2 outlined in Attachment 1 ‘Redlined change to SVA Data Catalogue Volume 2: Data Catalogue Appendix A’.\nThe proposed Implementation Date is May 2003 (consistent with changes proposed to the Data Transfer Catalogue (DTC))",{"$nulls":3},"—","Rejected"]
[878,"Notification of Superseded  ECVNA/MVRNA Authorisations","ELEXON","2002-10-28","BSCP71 3.1.5 & 3.2.5 states that, where an ECVNA or MVRNA Authorisation request is received by the ECVAA that supersedes an Authorisation already contained within the system, the ECVAA shall, in its acceptance of the request to the relevant Parties and Party Agents, confirm that the old Authorisation has been superseded. At present, the ECVAA system does not produce this confirmation and so there is no match for the process in the Service Description or the URS.  However, the ECVAA does comply with the higher-level requirements of the BSC in ensuring that the relevant Parties are notified of any Authorisations that have ceased to be effective, regardless of whether they have been superseded or terminated outright.","The ECVAA requirement to give notification of superseded Authorisations should be removed from Sections 3.1.5 and 3.2.5 of BSCP71.","−",null,null,"Implemented"]
[877,"Notification Agent Forward Contract Report Sub flow","ELEXON","2002-10-21","Prior to the rejection by the Authority of Modification Proposals P17 'ECVNAs to receive 7 day report' and P66 'ECVNAs and MVRNAs to receive ECVAA Forward Contract Report' some initial development work had been done which provided the functionality in the Energy Contract Volume Aggregation Agent's (ECVAAs) software and documentation for these Notification Agent Forward Contract Reports to be produced. The automatic production of these reports is already 'switched off' at source with notes in the documentation stating that these reports are 'not currently available'. ","There are two possible solutions to this problem that have been identified:\nFirstly, the details of this new Report could be removed from any documentation which is visible to external Parties. The functionality would remain in the software, but would no longer be visible and so would be unavailable to external Parties.\nSecondly the functionality could be removed in its entirety from all the software and documentation, in essence reversing all the work that was completed as part of the development of P17/P66.\nThe preferred solution will depend on a number of factors, such as cost, whether this service is likely to be requested in the future and the view of Participants.","−",null,null,"Implemented"]
[876,"Resolution of internal BMRA discrepancies","ELEXON","2002-10-18","BMRA by updating all incorrect references to forecast National Demand Surplus (\"Surplus\"), to be consistent with the BSC Annex X-2. Currently the correct values are used in all cases but some documentation uses the incorrect acronym names. (a) the flow from  the System Operator to the BMRA uses the incorrect acronyms OCNMFD2 and OCNMFW2 (but the correct values)  (b) the BMRA screens use the correct acronyms - SPLW and SPLD (and the correct values) (c) The BMRA Tibco messages use the incorrect acronyms OCNMFD and OCNMFW (but the correct values).\n","CP0876 proposes the BMRA, the IDD parts 1 and 2 and the BMRA SAA Interface Specification are updated to use the correct acronyms SPLD [Surplus (daily value)] and SPLW [Surplus (weekly value).","−",null,null,"Implemented"]
[875,"SVA Data Catalogue P0206 Data Item Omission","ELEXON","2002-10-15","The P0206 required change of profile class flow includes the Meter Register ID data items. These are only of value if supplied with the relevant Meter ID from which they were extracted. Where a number of meters exist on a metering system, each with one or more MD registers, the existing P0206 flow will only indicate the register id and not the meter from which it was extracted.","That the SVA Data Catalogue be amended for the next version to be issued.","SVG: 24","−","SVG","Feb 03 Release","Approve"]
[874,"Include the 'Meter Type' data item within the BSC SVA DC","ELEXON","2002-10-10","Include the 'Meter Type' data item within the BSC SVA Data Catalogue to reflect that contained within the Data Transfer Catalogue (DTC) (Version 7.3) and that proposed for inclusion within the DTC via DTC CP3157 (Amend both the Meter Type (J0483) Valid Set and the entry in Annex C for the population of the D0150)).  This CP supersedes CP760 (Identification of Prepayment Meters within the D0150 'Non-Half Hourly Meter Technical Details' dataflow) which was approved by SVG on 9 July 2002 (SVG/18/222) for implementation on 28 November 2002.","Define the data item ‘Meter Type’ and include it within the D0150 ‘Non-Half Hourly Meter Technical Details’ dataflow. ",null,"CPC00238",null,"—","Withdrawn"]
[873,"Changes to the Half Hourly Data Estimation Requirements","ELEXON","2002-10-10","1. Rewrite appendix 4.2 'Data of BSCP502 'Half Hourly Data Collection for SVA Metering Systems registered in SMRS' to add clarity to the processes of data estimation.\n2. Make a number of additional changes to BSCP502 to add clarity and to enhance requirements relating to data estimation. This CP supersedes CP758 'Improvements to estimation and validation techniques defined in BSCP502', CP759 'Inconsistencies with estimates based on actual HH data more than one month before or after the period of required estimation' and SIR3100 'Check Meter Readings used as actual data'. This CP presents the conclusions of the data estimation group which was initiated by SVG following presentation of paper SVG/18/221.","CP0873 proposes a number of changes to BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’","SVG: 23","CPC00239","SVG","2003-05-29","Approve"]
[872,"Comprehensive changes to D0268","ELEXON","2002-10-10","To apply a number of improvements to the D0268 'Half Hourly Meter Technical Details' dataflow within the BSC SVA Data Catalogue to reflect changes proposed in the MRA Data Transfer Catalogue under DTC CP3154. The improvements relate to a range of areas, including the following: 1. Feeder status; 2. Meter Asset Provider; 3. Outstation Multiplier; 4. Event Indicator; 5. Dialling Indicator; 6. Passwords; and 7. Main/Check indicators.\nComplex Sites changes proposed via DTC CP3154 are already being progressed by CP772.","Modify the BSC SVA Data Catalogue as outlined in the attachment to be consistent with the MRA.’","−","CPC00238",null,"−","Rejected"]
[871,"Operational Review of BSCP40 (Change Management)","ELEXON","2002-10-10","BSCP40 was written before NETA Go Live and was therefore based on how it was thought the change process would work.   In light of operational experience, it is now thought an appropriate time to carry out a wholesale review of the change management procedures to identify, where appropriate, more efficient and effective ways of working.  The review will also look to bring some areas in line with working practice. This review has also been requested by the Imbalance Settlement Group (ISG).","Carry out an operational review of the whole change management process, detailed in BSCP 40\n(Change Management). The end result will be a re-written and re-issued BSCP40.\nThis will be done using an industry ‘expert group’ to ensure all areas of the market have the opportunity to provide the benefit of their experience (good and bad of working with the current\nprocess.","ISG: 24                                     SVG: 24","CPC00261","ISG/SVG","Feb 03 Release","Approve"]
[870,"Reporting of GC & DC Values for BMUs in CRA Reports","TXU Europe Energy Trading Ltd","2002-10-08","Introduce new CRA Report to contain details of GC, DC and CALF for each BM Unit and Effective from dates.","A new CRA Report would provide data on GC, DC and CALF values and Effective From Dates\neach time the data changed (appeals, new Season data or increases within Season).","−","CPC00244",null,"−","Rejected"]
[869,"Inclusion of Credit Assessment QCE in ECVAA I-014","N/A","2002-10-07","Change contents of ECVAA I-014 Report. ","It is proposed that the ECVAA I-014 report (or a new one if it is easier or cheaper to implement that\nway) should contain the value of CAQCE for each Energy Account belonging to the Party.\nConsideration should also be given to reporting to the cumulative CAQCEaj value over the calculation period together with the cumulative value of Contract Notifications over the period (this would allow sight of whether the increase or decrease of the % of Credit Cover utilised was a result of changes to CALF or DC or GC values or a result of changes in Contract Notification Volumes).","−","CPC00244",null,"Implemented"]
[868,"Requirement for NHH Data Collector to provide latest EAC to new NHH Data Aggregator on change of NHHDA","ELEXON","2002-10-07","NHH Data Collector (NHHDC) should send the latest Estimated Annual Consumption (EAC) to the new NHHDA. Failure to do so by the Initial Settlement Data Aggregation Run for the effective date of the new NHHDA's appointment will result in a Default EAC being used in settlement.\nBSCP504 section 3.2.5 describes the requirements for sending AA and EAC data to the new and old NHHDAs in terms of meter advance periods ending before, on or after the appointment date. There is no explicit requirement to send the latest EAC in the event that no reading has been taken on or around the appointment date of the new NHHDA.","Clarify BSCP504 by the addition of an explicit requirement in sections 2.2.5 / 3.2.5 that on notification of a change of NHHDA, the NHHDC should send the latest EAC to the new NHHDA. This EAC should be sent no later than [8] working days after the effective date of the new NHHDA appointment. Move the content of sections 3.2.5.2 to 3.2.5.4 to section 3.3.11. This is on the basis that these actions relate to readings taken (or corrections made) after the change of NHHDA has occurred. Since a subsequent reading may be taken some time (possibly greater than a year) after the change of NHHDA, these requirements do not strictly relate to the change of NHHDA. Every time an AA and/or EAC is sent by the NHHDC, the NHHDC should ensure that they are sent to the relevant NHHDA (s). Include a cross-reference in section 3.2.5 to 3.3.11, to cover the eventuality that a reading is taken prior to the latest EAC being sent.","SVG: 28","CPC00246","SVG","Implemented","Approve"]
[867,"Logging and Performance Monitoring version 2.30","ELEXON","2002-10-02","Logging and Performance Monitoring version 2.30 * Obtain the root location of flat files output from ISRA by reference to a database table, according to settlement date. This change corresponds to Logica's Change 199 provided within ISRA release 6.4.3. * Shell script development to remove environment hard coding.\n* A fix to prevent sequence number jumping in the run number of the Market Indicator report.","Logging and Performance Monitoring version 2.30 * Obtain the root location of flat files output from ISRA by reference to a database table, according to settlement date. This change corresponds to Logica's Change 199 provided within ISRA release 6.4.3. * Shell script development to remove environment hard coding.\n* A fix to prevent sequence number jumping in the run number of the Market Indicator report.","−",null,null,"Implemented"]
[866,"Pool Application version 1.80","ELEXON","2002-10-02","Pool Application version 1.80: Obtain the root location of flat files output from ISRA by reference to a database table, according to settlement date. This change corresponds to Logica's Change 199 provided within ISRA release 6.4.3. Shell script development to remove environment hard coding.","Pool Application version 1.80: Obtain the root location of flat files output from ISRA by reference to a database table, according to settlement date. This change corresponds to Logica's Change 199 provided within ISRA release 6.4.3. Shell script development to remove environment hard coding.","−",null,null,"Implemented"]
[865,"BSCP68  Clarification","ELEXON","2002-10-01","The following minor documentation change is required to BSCP68 'Transfer of Registration of Metering Systems between SMRS and CMRS'.   Section 3.1.1.16 states within the Action box that the: 'CVA MOA registers the Meter Technical Details with the CDCA in accordance with BSCP20 ref 3.1.7 & 3.1.8 and submits form BSCP20/4.3a, b, c Registration of Meter Technical Details with proposed REFD) to the CDCA and Transfer Co-ordinator for information'. This should be altered to: 'CVA MOA registers the Meter Technical Details with the CDCA in accordance with BSCP20 ref 3.1.7 & 3.1.8 and submits form BSCP20/4.3a, b, c Registration of Meter Technical Details with proposed REFD) to the CDCA PDSO and Transfer Co-ordinator for information'.\n","The proposed solution is as highlighted above and is to replace the word CDCA with PDSO\nwithin the action box of BSCP68 Section 3.1.1.16.","SVG: 23","−","SVG","June 03 Release","Approve"]
[864,"Indication of Status of BM Units within S0142 Report","N/A","2002-09-27","The S0142 report (SAA-I014, flow 2, sent to NGC, ELEXON and requesting BSC Parties) provides information on all BSC Parties' settlement information.  At the moment the format of the report does not provide sufficient information in order to fully understand BSC Parties' imbalance positions, as it does not indicate the Production / Consumption Status of each BM Unit.\n","This proposal requests that a slight change to the S0142 format be made so that this information is included.","ISG: 37","CPC00243","ISG","−","Rejected"]
[863,"Inconsistency between the ECVAA SD, URS and Code","ELEXON","2002-09-26","These two amendments are small documentation changes that will remove the risk of confusion between the ECVAA Service Description, the URS and the BSC. A The ECVAA Service Description, sections 8.1d and 9.1d state that a check will be carried out to make sure that ECVNs and MVRNs from the notification agents have been transmitted at or before Gate Closure for each Settlement Period.  This is inconsistent with Code section P and the ECVAA URS, which demands that notifications have to be received by the ECVAA at or before Gate Closure. B\nSection 1.3 of the ECVAA Service Description suggests that ECVNAs and MVRNAs are BSC Agents, like the CRA and FAA.  This is incorrect - notification agents are classed as Party Agents.","Sections 8.1d and 9.1d of the ECVAA Service Description should be altered so that\n‘transmitted’ is replaced by ‘received’. Section 1.3 of the ECVAA Service should be reworded to avoid making the suggestion that ECVNAs and MVRNAs are BSC Agents.\nECVAA Service Description section 1.3 to read:\n","−",null,null,"Implemented"]
[862,"Error in BSCP501","ELEXON","2002-09-25","Minor error in BSCP501:\nPoints 3.3.6 and 3.3.8 in the interface and timetable section say D0029 instead of D0209.","In points 3.3.6 and 3.3.8 of the interface and timetable, replace the term D0029 with\nD0209.","−",null,null,"−","Rejected"]
[861,"SVA Data Catalogue Volume 2","N/A","2002-09-25","The P0186001 - half hourly default EAC form specifies the data item \"HH default EAC\" as being in MWh. The SVA Data Catalogue Volume 2 Data Items defines the data item \"HH default EAC\" as being in kWh.\n","This proposal requests that the SVA Data Catalogue be corrected to define the data item as MWh.","SVG: 25","CPC00267","SVG","May 03 Release","Approve"]
[860,"Clarification of the use of D0150","ELEXON","2002-09-23","An inconsistency exists in PSL110 'SVA Meter Operation' as the frequency details in Sections 5.2.12 and 5.2.13 are different for the D0149 'Notification of Mapping Details' and D0150 'NHH Meter Technical Details' data flows, despite the fact that they are almost always sent concurrently. The text in the 'Frequency' field for the D0150 dataflow details the triggers which cause this dataflow to be sent, but is not conclusive and is therefore unclear.\n","This CP therefore proposes to remove this inconsistency in PSL110.","−",null,null,"−","Rejected"]
[859,"Incorrect reference in BSCP531","ELEXON","2002-09-20","BSCP531 reference BSCP43.  This does not exist.  BSCP531 needs to be changed to remove the reference to BSCP43.","BSCP531 needs to be changed to remove the reference to BSCP43","SVG: 24",null,"SVG","Implemented","Approve"]
[858,"Inclusion of Energy Indebtedness data within ECVAA-I014","First Hydro Company","2002-09-18","The ECVAA-I014 (E0141) report (as sent to BSC Parties) is intended to provide information on their Credit Cover position.  At the moment the format of the report does not provide sufficient information for all Parties to adequately monitor and manage their Credit Cover position.\n","This proposal requests additional data to be included in the report so that BSC Parties are in receipt of the necessary information to adequately manage their credit position.","−","CPC00243",null,"Implemented"]
[857,"Changes required to BSCP28","ELEXON","2002-09-13","The suggested changes will allow for the approval of CVA LLFs by the panel in timescales shorter than 40WD. This will allow the processes in BSCP15 'BM Unit Registration' and BSCP68 'Transfer of Registration of Metering Systems between CMRS and SMRS' which require the approval of CVA LLFs to be completed in the timescales set out by those processes.","CP0857 proposed to make a number of to BSCP28.","−","CPC00243",null,"Implemented"]
[856,"Resolution of internal BMRA discrepancies","ELEXON","2002-09-13","This CP proposes to resolve internal discrepancies within the BMRA by updating all references to forecast National Demand Surplus (\"Surplus\"), to be consistent with the BSC Annex X-2. The BMRA software, IDD Parts 1 and 2 and NGC BMRA SAA Interface Specification incorrectly use the acronyms OCNMFW and OCNMFD to describe weekly and daily Surplus.\nThis CP proposes the BMRA is updated to use the correct acronyms SPLW and SPLD, since OCNMFW and OCNMFD are BSC terms in their own right referring to data displayed on the BSC website","The BMRA software, NGC BMRA & SAA Interface Specification and IDD Parts 1 and 2 will be\nrevised to use the acronyms SPLD and SPLW for Surplus, consistent with the BSC.\nThis change will impact the content of the interface from the System Operator to BMRA so that\nSurplus is defined using SPLD and SPLW instead of OCNMFD2 and OCNMFW2.\nIn the IDD Part 1 the Tibco message subject names “OCNMFD” and “OCNMFW” would be revised\nto be “SPLD” and “SPLW”.","−",null,null,"−","Rejected"]
[855,"Processing of MIL/MEL Messages in Sequence","ELEXON","2002-09-13","Currently the BMRS processes messages received from NGC as soon as they are received in accordance with their Service Level Agreement and the BMRA User Requirement Specification. A problem has been identified with processing files in this manner which from time to time affects the processing of Gate Closure Files and Re- Declarations of MIL and MEL.","ELEXON\nChange in Logica Service Levels to allow for the processing of files in sequence number order\nLOGICA\n1. Software change to process MIL/MEL files received from NGC in sequence number order;\n2. Change supporting procedures to deal with operational problems e.g. files out of sequence (in the same way as is currently done for files from sources other than NGC).\nNGC\nNGC to change software to allow the allocation of sequence numbers at the beginning of the Gate Closure job, to ensure that a Re-Declaration always has a later sequence number than the\ncorresponding Gate Closure file.","−",null,null,"−","Rejected"]
[854,"Provision of a new BSCP (SVA MOA Processes)","ELEXON","2002-09-13","This new BSCP is required to formalise SVA MOA processes and procedures and will cover the following areas: • Appointment changes • Market data activities • Connections and disconnections • Metering system (MS) Energisation status • Change of Measurement Class • MS Replacement or reconfiguration • Proving and Validation • MS investigations and meter reading amendments • Receipt and Processing of Market Domain Data\n• SVA Meter System standing data","The BSCP will be designed in line with the principles adopted in other SVA BSCPs.","SVG: 23","CPC00247/CPC00286","SVG","2003-05-29","Approve"]
[853,"Inclusion of Credit Assessment QCE in ECVAA I-014","N/A","2002-09-12","Change contents of ECVAA I-014 Report. Introduce new CRA Report to contain details of GC, DC and CALF for each BM Unit and Effective from dates","It is proposed that the ECVAA I-014 report (or a new one if it is easier or cheaper to implement that\nway) should contain the value of CAQCE for each Energy Account belonging to the Party.\nConsideration should also be given to reporting to the cumulative CAQCEaj value over the calculation period together with the cumulative value of Contract Notifications over the period (this would allow sight of whether the increase or decrease of the % of Credit Cover utilised was a result of changes to CALF or DC or GC values or a result of changes in Contract Notification Volumes. A new CRA Report would provide data on GC, DC and CALF values and Effective From Dates each time the data changed (appeals, new Season data or increases within Season).","−",null,null,"−","Rejected"]
[852,"Amendments to BSCPs to use terminology used in Annex S-1","N/A","2002-09-10","Replacement of the term Liquidated Damages and the acronym LDs with the term Supplier Charges and SCs to reflect the term used in Annex S-1 of the Code.\nReplacement of the term  'Funding Shares' in 4.5.2 with ,'that Supplier's share of the total quantity of energy attributable to Non Half Hourly Metering Systems taken by all Suppliers in the GSP Group during the relevant month', to reflect the terms used in the BSC, Annex S-1.","Replace the term ‘Supplier Liquidated Damages’ with ‘Supplier Charges’ and the acronym ‘LDs’ with ‘SCs’in BSCPs 533, 534 & 536.\nReplace the term ‘Funding Shares’ in 4.5.2 with ,‘that Supplier’s share of the total quantity of energy attributable to Non Half Hourly Metering Systems taken by all Suppliers in the GSP Group during the relevant month’.","−",null,null,"Implemented"]
[851,"Update to forms in BSCP536","N/A","2002-09-10","The forms in BSCP536 provide less detail to BSC Parties and ELEXON than the forms generated by the PARMS system. The forms generated by PARMS give additional detail to the BSC Parties in indicating where charges have been applied.","Update the relevant forms in BSCP536 to reflect the additional details provided by the forms generated by PARMS.","−",null,null,"Implemented"]
[850,"Creation of exception log in SVAA software for timestamp errors in D0277 Flow","ELEXON","2002-08-30","There has been an instance of the DPP run failing because of a problem with the D0277 TCI Data File. This problem occurred as the times inputted by the Teleswitch Agent are rounded to the nearest minute at EASL. In this instance the rounding of these times resulted in the on/off times being the same, causing the loading of the data by the SVAA to fail. As this is recognised as a format error, rather than a validation error, an error log and not an exception report was generated, which failed to identify the source of the problem.  It is proposed that the SVAA software is modified to include a check for duplicated TCI Effective Times as an extra validation check, so that such duplications would cause a validation error, resulting in an exception report being generated.","An amendment is required to the SVAA User Requirement Specification (URS) to add a new\nvalidation check to clause 6.2.14.6 (process 2.2.6 – Load Teleswitch Contact Details).","SVG: 23","CPC00237","SVG","Aug 03 Release","Approve"]
[849,"SVAA National Service Desk Severity Levels","ELEXON","2002-08-29","Reduction in the number of SVAA National Service Desk Severity Levels from five to four.","Proposed a classification of severity levels.","−",null,null,"Implemented"]
[848,"Logging and Performance Monitoring release 2.2.1","ELEXON","2002-08-27","Logging and Performance Monitoring release 2.2.1. This change will enable the Logging and Performance Monitoring application to produce comparison reports on the data held within the MDD and ISRA databases.","This change will enable the Logging and Performance Monitoring\napplication to produce comparison reports on the data held within MDD and ISRA databases.","−",null,null,"Implemented"]
[847,"MDD Release 5.2","ELEXON","2002-08-27","MDD Release 5.2.  The purpose of this change is to improve error handling by a) increasing the size of error messages, thus eliminating truncated and potentially confusing messages and b) reducing the number of compilation warning messages, which could result in significant messages being overlooked.","a) increasing the size of the error messages, thus eliminating truncated and potentially confusing messages and b) reducing the number of compilation warning messages.","−",null,null,"Implemented"]
[846,"Clarifications to Flexible Reporting in BSCP41","ELEXON","2002-08-20","Changes are required to BSCP41 'Report Requests and Authorisation' in order to clarify processes and terminology that are causing confusion to participants.\nRelease 2 of the BSC Systems Delivery Programme, implemented in August 2002 has introduced new concepts in flexible reporting such as flow versioning.  However, some areas of confusion still remain, particularly in the use of the forms by participants and in the terminology contained in BSCP41.","CP0846 proposes a number of changes to BSCP41 ‘Report Requests and Authorisation’. ","−","CPC00231",null,"Implemented"]
[845,"PARMS - Correction To LD Reports","ELEXON","2002-08-14","Since the introduction of NETA, it is possible for a Supplier to have a negative Deemed Take in the Stage 2 market. There is a defect in the PARMS application that prevents the LD reports being produced if this situation occurs.\nIn addition, functionality to electronically distribute the reports to Suppliers and Parties that was introduced and tested in an earlier version of the system was not kept up to date when changes were made to the software to produce the paper based reports. This should be corrected to allow electronic distribution of the reports.","Amend the software to produce the LD reports electronically in all instances.\n","−",null,null,"Implemented"]
[844,"Correcting Swapped Registers on SVA Multi-Rate Meters","N/A","2002-08-13","There is no method defined within the BSC or subsidiary documentation that prescribes how NHHDCs should correct incorrectly mapped meter registers, once an NHHDC has identified that incorrect mapping details have been used in Settlement.  This CP proposes a robust method that has been agreed by SVG that all NHHDCs should employ.","Include within BSCP 504, sections 2.3 and 3.3, and PASL 120 (if necessary), solutions using\nthe principles agreed by SVG in paper SVG/18/227.","SVG: 23","CPC00236","SVG","Aug 03 Release","Approve"]
[843,"Modification to BMRA Web Site to Support Windows XP","N/A","2002-08-13","The BMRA web site needs to be modified to provide Parties / Non Parties who are unable to access the web pages with instructions on how to rectify the problem","The Help page on BMRA web site should contain a note explaining that the option to automatically\ndownload a Java Virtual Machine is not applicable to PCs operating on windows XP. The note should also explain that it is possible to manually install a Java Virtual Machine and a link to the site\nhttp://java.sun.com/getjava/others.html along with a statement that everything that is required for a\nmanual installation is available at this site.","−","CPC00231",null,"−","Rejected"]
[842,"Revision to Non-Half Historical Data Transfer Requirements","ELEXON","2002-08-08","Revise the current flexibility relating to the transfer of non-half hourly historical data (i.e. meter readings and Annualised Advance / Estimated Annual Consumption) between old and new Non-Half Hourly Data Collectors (NHHDCs). The non-half hourly historical data requirements are described in Appendix 4.8 'Historical Data Requirements' of BSCP504 'Non-Half Hourly Data Collection for SVA Metering Systems Registered in SMRS'.  Appendix 4.8 specifies the minimum historical data transfer requirement which will be triggered in one of the following business events: • A change of NHHDC; and \n• A coincident change of NHHDC and Supplier.\nTherefore the old NHHDC can choose to send more than the minimum specified in Appendix 4.8 of BSCP504.","There are four potential solutions for consideration with solutions A through to C requiring\nchanges to Appendix 4.8 of BSCP504 and potentially PSL120. Solution D does not require a\nchange to the Code Subsidiary Documents.","−","CPC00211/CPC00222",null,"−","Rejected"]
[841,"Substituted metered data in the CDCA I012.","ELEXON","2002-08-07","The CDCA I012 'Raw Metered Data Report' is intended to provide each Metering System Registrant with a record of the metered data uploaded from each Metering System on a daily basis. As the name of the report implies it is intended to provide the data in its raw format and will indicate its status: A - 'Valid Metered Data', B - 'Invalid Metered Data' and C - 'Unavailable Metered Data'\nCurrently CDCA I014 report also includes substituted metered data. As the substituted data appears in the Primary Outstation channel as 'valid meter data' it is interpreted as though the metered data had been uploaded directly from the Metering System.","The CDCA software will be changed to stop any substituted data being included in the CDCA I012 ‘Raw Metered Data Report’.","−","CPC00221/CPC00229",null,"Implemented"]
[840,"Amendments to the IDD- Part 1. (Version 4.7)","N/A","2002-08-01","A new section 7.20.1, Sign Convention, is required and a new sub-heading 7.20.2, Notes on Functionality, to the existing text to the IDD - Part 1. CP raised as a result of PMR31113.\nThis change is for clarification and no software changes are required.","The new section should contain the following text:\n“This section clarifies the notes given in the spreadsheets, Part 2 of the IDD, regarding the sign conventions used for Energy Contract Volume Notifications (ECVAA-I004) and the reporting of this data in the subsequent Notification Reports (ECVAA-I014) and Forward Contract Reports (ECVAA-I022).\n","−",null,null,"Implemented"]
[839,"Amendment to ECVNA Authorisation Termination Request Form","Innogy","2002-07-31","At present an ECVNA Authorisation Termination request can be completed by one counterparty and sent to CRA for termination and the pairings are therefore terminated. An ECVNA Authorisation Request form requires the signature and therefore the authorisation of both parties. It would be prudent if any Termination request required the signature and therefore the approval of both parties concerned in line with all Authorisation requests. This would reduce the risk of any relationship being terminated in error and without the knowledge of the other counterparty.","BSCP71/03 ECVNA authorisation termination request form must be completed and signed by both Parties before CRA/LOGICA will action any termination request.","−",null,null,"−","Rejected"]
[838,"Inconsistencies between the use of D0139 in BSCP 502","ELEXON","2002-07-26","BSCP502 'Half Hourly Data Collection for SVA Metering Systems Registered in SMRS', Processes 3.3.3 'Energise a SVA Metering System and 3.3.4' De-energise a SVA Metering System', steps 3.3.3.4 and 3.3.4.7 both state that flow D0139 'Confirmation or Rejection of Energisation Status Change' is sent from the Supplier to the HHDC by electronic or other method, as agreed. However, the electronic method is not readily available as MRA DTC (version 4.1 onwards) does not include an instance of the D0139 data flow from Supplier to the HHDC as this instance was removed from the DTC in version 4.1 to bring the DTC in line with PSL110. Consequently, BSCP 502 and the BSC SVA Data Catalogue require a change to bring them in line with PSL110. This CP supersedes CP776 and is supported by Scottish and Southern Energy.","Make changes to both processes 3.3.3 and 3.3.4 in BSCP 502 so that as well as the PDSO informing the Supplier of the change of energisation status, it also informs the MOA using the D0139. This can be achieved by adding MOA to the ‘TO’ box in process 3.3.3 step 3.3.3.3 and similarly in process 3.3.4 step 3.3.4.6. Then, instead of the Supplier informing the HHDC of change of energisation status using the D0139, the MOA takes on this role. In BSCP 502, this requires Supplier to be replaced by MOA in the ‘FROM’ box of process 3.3.3, step 3.3.3.4 and similarly in process 3.3.4, step 3.3.4.7.","−","CPC00223",null,"Implemented"]
[837,"Introduction of the use of electronic signatures in BSCP509","ELEXON","2002-07-19","To change BSCP509 to allow electronic signatures to be used on the Change Request forms.","CP0837 proposes a number of changes to  BSCP509.","−",null,null,"−","Rejected"]
[836,"Update of Supplier Meter Registration System (SMRS) database","ELEXON","2002-07-15","The Master Registration Agreement (MRA) has been amended to include a tighter description of the timescale that the PDSO and the Supplier are required to adhere to in updating the SMRS database. BSCP501 \"Supplier Meter Registration Service\", which details the procedure for updating the SMRS database, needs updating to reflect this change.","CP0836 proposes a number of changes to BSCP501 Section 3.2 ‘Update of SMRS Database by\nPublic Distribution System Operator'.","SVG: 26",null,"SVG","Implemented","Approve"]
[835,"Upgrade to UNIX 5 for ISRA/ SVAA software","ELEXON","2002-07-11","The ELEXON-owned ISRA/SVAA software products are currently configured to run on UNIX 4.0.f. However, support for UNIX 4.0.f by Compaq will expire on 30 September 2002. As a result, it will be necessary to reconfigure and recompile the ISRA/SVAA software to run on UNIX 5.1.A (or higher) to ensure that these products will be fully supported after 30 September 2002.","Logica to reconfigure and recompile the SVAA software to run on UNIX 5.1 (or higher).\nLogica have quoted for the upgrade for SVAA to UNIX 5.1.","−",null,null,"Implemented"]
[834,"Dependency of Inter-Agent Transfers on D0151 (Termination Of Appointment","ELEXON","2002-07-09","There are inconsistent views among Non Half Hourly agents with regard to whether inter-agent transfers should be initiated on request (via a D0170 Request for Metering System Related Details) only or should be dependent on both a D0170 and a D0151 (Termination of Appointment). The inter-agent flows in question are the D0150 (Non Half-Hourly Meter Technical Details) and D0149 (Notification of Mapping Details) between Meter Operators and the D0010 (Meter Readings) and D0152 (Metering System EAC/AA Historical Data) between Data Collectors.","Clarify PASL 110 (1.3.2.2), PASL 120 (1.3.2.3.1) and, optionally, BSCP504 (3.2.3 and 3.2.6), to the effect that Non Half Hourly Data Collectors should transfer meter reading and AA/EAC histories and Meter Operators should transfer meter technical and mapping details on request from an accredited agent (or Supplier as applicable), irrespective of whether a termination of appointment has been received from the agent's Supplier.","SVG: 31","CPC000308","SVG","Feb 04 Release","Approve"]
[833,"Revise three of the Serials in PSL110 'SVA Meter Operation'.","ELEXON","2002-07-05","Clarify the use of the following three Serials within PSL110: 1. 5.3.1, Half Hourly Meter Operator Agent: • Serial 8 \"Compare collected data with expected data and send report of  unsuccessful test\". • Serial 9 \"Compare collected data with expected data and send report of  successful test\". 2. 5.3.2, Non-Half Hourly Meter Operator Agent:\n• Serial 1 \"Fault Repairs\".","CP0833 proposed to modify PSL110. ","−",null,null,"−","Rejected"]
[832,"Resolution of Defects in  the IDD","ELEXON","2002-07-05","A number of documentation only defects have been identified in the IDD.  The defects fall into the following two categories:\n1. Defects associated with Observation Reports (ORs). These defects have been identified by Logica and ORs have been raised against each of the defects. 2. Defects raised from PMRs\nPMR31739 was raised by Formfill to highlight the following defect in the IDD.","CP0832 proposed changes to the IDD to address the defects. ","−","CPC00215",null,"Implemented"]
[831,"Amend 'Meter Type' definition for pre-payment meter","N/A","2002-07-04","CP760 (Identification of Prepayment Meters within the D0150 'Non Half Hourly Meter Technical Details' dataflow) was raised to modify the BSC SVA Data Catalogue to describe how the 'Meter Type' data item (J0483) should be populated.  The changes proposed via CP760 do not explicitly cover the instance where a pre-payment meter is being used as a credit meter, so a further amendment to the BSC SVA Data Catalogue is required to indicate how 'Meter Type' should be populated in this circumstance. This CP does not replace CP760, but is an enhancement to it.","CP0831 proposed changes o the BSC SVA Data Catalogue Volume 2.","SVG: 20","CPC00200","SVG","−","Rejected"]
[830,"Services Description Updates to reflect Code changes","ELEXON","2002-07-04","BSC Agent Service Descriptions need to be updated to reflect the changes made to between v1.0 and v1.1 of the Code that relate to Contingency Provisions.  These include the following: § Failing Supplier Process § Suspension of Balancing Mechanism §Manifest Errors § Suspension of Contract Volume Notifications § Black Start - Contingency § Civil Emergencies and Fuel Security Periods § Generator Compensation Instructions\n§ Single Imbalance Cashout Price","Amend the following CSDs:\n• BMRA Service Description\n• CRA Service Description\n• ECVAA Service Description\n• FAA Service Description\n• SAA Service Description","−",null,null,"Implemented"]
[829,"Match Effective Date of CVA LLF to ISG Approval Date.","ELEXON","2002-07-03","Currently, BSCP28 Section 3.1.1 States that CVA LLF's must be submitted at least annually, or by ED-40 WD. This exists to ensure that all tasks set out in the BSCP can be carried out.  Very often it is the case that these tasks can be performed in a timescale far less than 40 WD. Where this is the case, allowing ED to be that of the date of approval will increase the accuracy of data in settlement.","Change text in BSCP28 3.1.1 from:\nAt least annually or by ED-40.\nTo:\nAt Least annually, and by ED-40 (unless otherwise agreed by the BSC Panel)*","−",null,null,"Implemented"]
[828,"New Metering Code of Practice","ELEXON","2002-07-02","There is currently no Code of Practice (CoP) relating to Metering Equipment in the Non-Half Hourly Market as until the present, all Metering Equipment used in this area has been of an Approved Type (by Ofgem) and conforms to British Standard EN 61036. The possibility of New Metering Technology entering the Market in the near future requires the need for a Code of Practice for the Non-Half Hourly Market.","Write a new Code of Practice, CoP 8 titled ‘Code of Practice for the Metering of Energy Imports and Exports via Low Voltage Circuits Fused at 100 Amps or Less per Phase for Non-Half Hourly Settlement Purposes’.\nThis CoP should be written by a group of Industry Experts in this area.","SVG: 52","CPC00269/CPC00393",null,"Implemented","Closed"]
[827,"Clarifications to the CoS and CoMC from NHH to HH.","ELEXON","2002-06-26","A Pilot exercise carried out by SWEB between April and September 1999 for the Change of Supplier (CoS) coincident with Change of Measurement Class (CoMC) has highlighted a number of issues with the current process."," This CP proposes clarifications to this process and affects BSCP 502, BSCP 504, PLS 120, PLS130 and the SVA Data Catalogue. This CP has been raised from SIR 2639, SIR 2667, SIR 2668 and SIR 2669","−","CPC00246",null,"−","Rejected"]
[826,"Reconciliation of Supplier MOA Mismatches.","ELEXON","2002-06-20","This Change Proposal is raised to address the issue of mismatches in appointment details held by Suppliers and Half Hourly Meter Operator Agents (HHMOA). In the Half Hourly market, the HHMOA appointed by the customer might be different from that appointed by the Supplier. ","The proposed solution provides Suppliers with a list of Metering Systems which HHMOAs believe that they have been appointed for. Suppliers will then be able to identify those that are correct appointments and those that are incorrect appointments. Resolution would allow Suppliers and HHMOAs to reconcile appointment details on a regular basis.","−",null,null,"−","Rejected"]
[825,"Provision of Metering System Energisation Status to HHDC","ELEXON","2002-06-20","BSCP 502 'Half Hour Data Collection for SVA Metering Systems Registered in SMRS' Process 3.2.1 New Connection or Registration Transfers from CMRS to SMRS - Metered Supply' does not take into account a delay in meter installation. Consequently the Half-Hour Data Collector (HHDC) has no instruction on what to assume as the default Energisation Status of a new meter. C","CP0825 proposed changes to documents which were required to ensure that HHDCs are notified of the Energisation Status of a metering System for a new appointment.",{"$nulls":3},"—","Withdrawn"]
[824,"Housekeeping Change to BSCP536","ELEXON","2002-06-18","BSCP536\nThe end of section 4.3.1 seems to be missing and section 4.3.2 has been merged in with it, rather than being a separate paragraph.","Rearrange the paragraph.","−",null,null,"−","Rejected"]
[823,"Housekeeping change to BSCP534","ELEXON","2002-06-18","Description of Change\nWhere \"Section X\" is mentioned in section 4.2 of BSCP534 (Supplier Standards heading), this should read \"Section S1\"","Amend section 4.2 to read “Section S1”.","−",null,null,"−","Rejected"]
[822,"Housekeeping change to BSCP533","ELEXON","2002-06-13","BSCP533\nIn the first paragraph of section 4.2 there is a cross-reference to the definition of serials and standards in the MIRT as \"ref. BSCP533 Section 4.12\".  It is thought that this should be \"Appendix\" not \"Section\".  Also, in the main part of this BSCP, right at the end it refers to Appendix 4.12 and Appendix 4.13 being separate documents, respectively the MIRT and the Supplier Data File Formats.  However, the MIRT document itself calls itself BSCP 533 Appendix 4.13 and the Supplier Data File Formats document calls itself BSCP 533 Appendix 4.14.","BSCP533\nIn the first paragraph of section 4.2 there is a cross-reference to the definition of serials and standards in the MIRT as \"ref. BSCP533 Section 4.12\".  It is thought that this should be \"Appendix\" not \"Section\".  Also, in the main part of this BSCP, right at the end it refers to Appendix 4.12 and Appendix 4.13 being separate documents, respectively the MIRT and the Supplier Data File Formats.  However, the MIRT document itself calls itself BSCP 533 Appendix 4.13 and the Supplier Data File Formats document calls itself BSCP 533 Appendix 4.14.","−",null,null,"−","Rejected"]
[821,"Improvements to CVA Allocation Proving Test Requirements","Powergen UK plc.","2002-06-12","An improvement on the processes for Proving Tests in CVA and to ensure that Proving Tests are carried out whenever appropriate.  It will identify and clarify the responsibilities of all parties to the Proving Test process","It is proposed that a new BSCP should be developed titled “Proving Test requirements for Central\nVolume Allocation Metering Systems” and amend/remove the existing requirements in BSCP20.","−",null,null,"Implemented"]
[820,"Enhancements to a number of Unmetered Supplies Processes","ELEXON","2002-06-12","Following a walkthrough of BSCP520 'Unmetered Supplies Registered in SMRS' between ELEXON and a sub-set of the Unmetered Supplies User Group (UMSUG) members on 4 April 2002 a number of enhancements are required to BSCP520 and its associated Appendices document to reflect working practices. The majority of the processes included within BSCP520 are affected to a greater or lesser extent.  ","This CP addresses the action raised by SVG members at their meeting on 6 November 01 (SVG/008/101) 'Detailed Level Impact Assessment: CP690 'Clarifications and improvements to the Unmetered Supplies processes in the Code Subsidiary Documents'.\nThis CP has been raised following review by the Unmetered Supplies User Group (UMSUG), which has ELEXON and a number of BSC Parties represented on it.","SVG: 28","CPC00236","SVG","June 04 Release","Approve"]
[819,"Amend the SVAA software to improve performance","N/A","2002-06-12","The \"Specify SSA Run/Data Aggregation Files for SSR Run\" screen displays a large list of all files for the user to select a file to be used default data. Since this list is very large in the live environment a significant amount of time is spent by the user in selecting the file. It is proposed that the screen will be amended to simplify the selection criteria and consequently reduce the time spent in using this screen.","The “Specify SSA Run/Data Aggregation Files for SSR Run” screen will be amended as\nfollows:\n• Change the query to reduce the number of rows returned\n• Turn off the switch on the aggregation run number that checks the value entered against a list of values\n• Introduce a trigger that validates the run number against the database\n• Unprotect the settlement date and settlement code fields to allow the user to enter values\n• Validate the entries and populate the aggregation run number field.","SVG: 19","−","SVG","Feb 03 Release","Approve"]
[818,"Provision of Metering System Energisation Status (ES)","N/A","2002-06-12","The proposal is for changes to be administered that will ensure that HHDCs are notified of the Energisation Status of a Metering System (MS) for a new appointment.","The following solutions are proposed:\n1. PSL110 1.4.1.2 to include an obligation for Half Hourly Meter Operator Agent (HHMOA)\nto inform HHDC of ES under BSCP502, section 3.2. D0139 cited in BSCP502 for HHMO to\ninform HHDC of ES, where the D0268 cannot be sent.\n2. The D0139 Flow Description in (MRA) Data Transfer Catalogue requires a change in\ndescription so that it can be used to inform of Metering Point ES when required.\n3. BSCP502, section 3.2 to contain a clear statement that HHDC will assume that Metering\nSystem is energised until otherwise informed by D0139 or D0268 flow.\n4. BSCP502, section 3.3.3 to include an obligation on PDSO to ensure that Supplier and\nHHMOA is informed of Metering Point ES prior to new connection appointment start date.\nThe HHMOA should then be obliged to inform the HHDC of the ES for the Metering Point\nappointment during Registration Activities in BSCP502, section 3.2.\n5. BSCP502, section 3.3.4 to be amended such that the PDSO is obliged to inform the\nSupplier and the HHMOA of De-energisation Status. The HHMOA then needs to inform the\nHHDC of the ES for the Metering Point.","−",null,null,"−","Rejected"]
[817,"Reconciliation of Supplier Meter Operator Agent Appointment","N/A","2002-06-12","This Change Proposal is raised to address the issue of mismatches in appointment details held by Suppliers and Half Hourly Meter Operator Agents (HHMOA), and that held in SMRS. In the Half Hourly market, the HHMOA appointed by the customer might be different from that appointed by the Supplier. Resolution would allow Suppliers and HHMOAs to reconcile appointment details on a regular basis.","The proposed solution involves the following changes:\n1) PSL110 to include an obligation on HHMOAs to provide appointment details at regular\ntime periods (to be determined), or on request, to the Supplier.\n2) A new flow allowing HHMOA to inform relevant Suppliers of their appointments.\n3) Supplier to modify SMRS records when a valid inconsistency is identified.","−",null,null,"−","Rejected"]
[816,"Provide HH / NHH SVA data split by BM Unit to NGC","National Grid","2002-06-07","National Grid currently receives the D83 data flow from the SVAA in order to calculate TNUoS charges for Suppliers. The file provides information about the split between half-hourly and non half-hourly energy consumption for each Supplier for each GSP Group. National Grid needs to receive this information split down to the level of individual BM Unit. This level of detail is required for data from 1 April 2002. National Grid will not be reconciling Supplier charges for this year until data is available for the whole financial year (i.e. in May 2003).","One solution would be to amend the format of the D83 file so that it includes the information required in the necessary level of detail.","−",null,null,"−","Rejected"]
[815,"Restructuring of ISRA Flat Files","ELEXON","2002-06-05","The weekly backup of ISRA takes about 36 hours to complete. However, the amount of ISRA data is continuing to increase so that the backup time is continuing to increase. Potentially, even with full archiving, the backup time could increase to about 45hours. This severely constrains the ability of the SVA Agent to perform major upgrades out of normal business hours, particularly in view of increasing data volumes.","The change would partition the storage of SVAA Flat Files across different directories according to the Settlement Date to which they refer. This will enable parallel backups of ISRA to be carried out.","SVG: 19","−","SVG","Feb 03 Release","Approve"]
[814,"Allow Amendments to ISRA Calendar","ELEXON","2002-06-05","The ISRA application does not allow Settlement Calendar data to be amended once the Initial Settlement run has been processed for the date in question, even with Standing Data Manager access. Logica have stated that the application is working to specification. The 1999-2000 Calendar required over 4000 dates to be entered manually, of which approximately 30% were dates for which Initial Settlement runs had already been processed. This number may increase in future Calendars as the full reconciliation cycle has been reached. These dates are also used by the Logging Application to calculate performance against deadlines.","See the description of the issue. ","SVG: 19","−","SVG","Feb 03 Release","Approve"]
[813,"Amend the SVAA Load Data Files screen","ELEXON","2002-06-05","The Load Data Files screen displays, for each input file type, the number of files that are waiting to be loaded, and the number that have failed to load (see attachment).  When a file fails to load it is placed in the Corrupt directory and an entry is made in the cdb-file-reference table giving the file a status of 102 to indicate that it has failed. The failure count for that file type on the Load Data Files screen is then incremented by 1.\nThe only legitimate way to alter the status of the file in the cdb-file-reference table, and thus decrease the failure count on the Load Data Files screen, is to correct the data and reload the file successfully. However, this will never happen. The business process for dealing with failed input files is for the ISR Agent to contact the data provider, who then corrects the problem at source, regenerates and resubmits the data.","Modify the SVAA Load Data Files form to include a new additional column titled ‘Recent Failure’ such that this column will display the sum totals of all the files that have failed to load successfully into SVAA during the current day, or the previous day for each file type listed. Remove the main title for the last two columns, ‘Load Totals’. Change the title of the column currently titled ‘Awaiting’ to ‘Awaiting Load’ and the title of the column currently titled ‘Failure’ to ‘Failure Total’.","SVG: 19","−","SVG","Feb 03 Release","Approve"]
[812,"Improvements to SVAA LLFC Closure Performance","ELEXON","2002-06-05","MDD files are processing slowly due to there being no index to speed up the query that is run when closing LLFCs.","The MDD Load performance could be improved by:\n• Building a table in memory of all the LLFC and their maximum held date in the LLF table. The code\nwould be modified to use this table held in memory rather than searching the whole of the LLF table held in the SVA database.\n• The memory table would only be built when the load MDD code detects a new LLFC closure for the first time. This would mean that if the MDD file being loaded did not contain any new LLFC closures, no performance degradation would occur as a result of building the memory table.","SVG: 19","−","SVG","Feb 03 Release","Approve"]
[811,"Clarify the timescales associated with steps 3.2.5.6 and 3.2.5.7 within BSCP550 ","ELEXON","2002-05-31","Process 3.2.5 'Removal of a Secondary Supplier(s) to a Shared SVA Metering System with a Multiple Fixed Block Allocation Schedule' of BSCP550 'Shared SVA Meter Arrangement' has two timescales within it referring to 'contract SSD'.  The references to 'contract SSD' are incorrect in the context of this process which has nothing to do with the change of supplier process.  This is covered elsewhere in BSCP550.","Change the text in the ‘When’ boxes of 3.2.5.6 and 3.2.5.7 as follows:\n1. 3.2.5.6. To read ‘Within 3WD of 3.2.5.5’.\n2. 3.2.5.7. To read ‘Within 1WD of 3.2.5.6’.","SVG: 28",null,"SVG","Implemented","Approve"]
[810,"Clarification to BSCP502 - Energy Recorded Exceeds Limit","ELEXON","2002-05-30","Amend the text within Appendix 4.1 of BSCP502 'Half Hourly Data Collection for SVA Metering Systems Registered in SMRS', so that it is clear what action the Half Hourly Data Collector (HHDC) takes in the event that the energy recorded exceeds that permissible and no instructions have been provided by the Supplier to the HHDC. This is an opportune change.","Add ‘no’ into the following sentence of 4.1.6 which is contained in Appendix 4.1:\n! “Use actual consumption data if the energy has exceeded the permissible allowed by no more than 20%; or”","−","CPC00210",null,"Implemented"]
[809,"PDSO's obligation to issue D0265 flows to Suppliers","ELEXON","2002-05-20","Currently BSCP 528 'SVA Line Loss Factors for Half Hourly and Non-Half Hourly Metering Systems Registered in SMRS' places an obligation on PDSOs to issue their SVA Line Loss Factor (LLF) data to affected Suppliers and Half Hourly Data Aggregators (HHDAs) using a 'Line Loss Factor Data File' D0265 dataflow via the Data Transfer Network (DTN). However, since the implementation of Modification Proposal P30 'Provision of BSC data to BSC and non-BSC Parties', the Balancing and Settlement Code Company (BSCCo) is now obligated to display LLF data (in both full D0265 form and summarised format) additionally on the BSC Website.","CP0809 proposes removal of the PDSO's obligation to issue their D0265 to Suppliers and HHDAs.","−",null,null,"−","Rejected"]
[808,"Changes to the Software Maintenance Service (SSL370)","N/A","2002-05-20","Clause 1.11 of SSL370, 'Software Maintenance Service' should be modified to reference Mutual Application and Developed Application Software Materials (MASM and DASM, respectively).  MASM is software that is developed for mutual use but may be changed by the SVAA at its own cost, subject to notification to BSCCo.  DASM consists of software developed by the SVAA specifically upon the request of BSCCo.\nThis CP is raised from CR3028.","CP0808 proposes changes to section 1.11 of SSL370.","−","CPC00210",null,"Implemented"]
[807,"Additional Multiplier Field in the D0268 flow","N/A","2002-05-19","Currently a HH Meter will keep in its memory a value for every half hour read, plus it will show a cumulative total on a display. These reads are subject to conversion to show actual volumes by the use of multipliers. The DC will periodically take a visual read from the meter, alongside the HH reads that are electronically sent to it from the meter's memory. For the period between 2 visual reads, the MAR is calculated from the sum of half hourly reads after suitable adjustments using the multipliers and should equal to within 0.1%. There are 3 multipliers that apply to some meters; however, the D0268 'HH Meter Technical Details' only has 2 fields for the indication of multipliers. The addition of another multiplier field to the D0268 would mean that the MO could pass information concerning all of the multipliers to the relevant parties.","Add an additional field to the D0268 ‘Half Hour Meter Technical Details’ for another multiplier, J**** New Multiplier for MAR (Description to be agreed). This would sit in the group with the other multipliers in the D0268. A DTC CP will be raised in accordance with the comments received for the description of a New Multiplier.","−",null,null,"−","Rejected"]
[806,"Changes to the SVA Data Catalogue","N/A","2002-05-15","SIR R2928 and CR R3070 require minor documentation changes to the SVA Data Catalogue to clarify or correct the use of certain data items.\nThis CP supersedes CP798.","SIR R2928\nRemove the data item ‘Profile Coefficients Requested’ from flow P0040 in Part 1 of the SVAA\nData Catalogue.\nCR R3070\nThe description for the data item ‘Date Action Required By’ in Part 2 of the SVAA Data\nCatalogue should be altered.","−","CPC00212",null,"Implemented"]
[805,"Amendment to BSCP502 - inclusion of the D0275 dataflow","N/A","2002-05-15","There are a number of Suppliers and Distribution Businesses who require to be informed of their Half Hourly consumption values by UTC (Co-ordinated Universal Time), whereas BSCP502 stipulates that data from the HHDC should be by local time.  ","This CP proposes that the decision on which time protocol to use should be a Supplier responsibility. The data from the HHDC to the HHDA would continue to be in local time. This CP has been raised from SIR R3008.\nThis CP supersedes CP802.","−","CPC00210",null,"Implemented"]
[804,"Enhance D0268 'HH Meter Technical Details' within the SVA DC","N/A","2002-05-14","Apply a further improvement to the D0268 'Half Hourly Meter Technical Details' dataflow within the BSC SVA Data Catalogue to better reflect an existing manual process which is being operated in the half hourly market relating to removed meters.","Modify the BSC SVA Data Catalogue as outlined in the attachment. There is no impact on any BSCP or PSL",null,"−","SVG","−","Rejected"]
[803,"Missing Requirement to Address Failing Instructions","N/A","2002-05-03","A process is required to cover the situation in which an instruction failure occurs between an SMRA and a Data Aggregator and, although the SMRA may be informed of the fact, it is not able to resolve the failure. In these situations, issues may be left outstanding for long periods of time and the SMRAs do not have any procedures in place to deal with them.\nThis CP has been raised from SIR R2673.","Following attempts by an SMRA to resolve failed instructions, if any failed instruction files\nremain unresolved, or repeat failures occur, Data Aggregators (both HH and NHH) will notify\ntheir associated Suppliers of the failure details. Suppliers would then be expected to take\naction, with or without the SMRA and DA, in order to resolve the problem.\nThe expected impacts are: PSL140, PSL150, BSCP503, BSCP505, Business Process Model,\nSVA Data Catalogue and the MRASCo Data Transfer Catalogue.\nIt is therefore expected that an MRA DTC Change Proposal be raised in parallel in order to\nprogress this change.","SVG: 25","−","SVG","−","Rejected"]
[802,"Amendment to BSCP502 - inclusion of the D0275 dataflow","N/A","2002-05-03","There are a number of Suppliers and Distribution Businesses who require to be informed of their Half Hourly consumption values by UTC (Co-ordinated Universal Time), whereas BSCP502 stipulates that data from the HHDC should be by local time.  This CP proposes that the decision on which time protocol to use should be a Supplier responsibility.  The data from the HHDC to the HHDA would continue to be in local time.\nThis CP has been raised from SIR R3008.","There are currently two dataflows generated by the HHDC in order to provide Half Hourly\nadvances: D0036 ‘Validated Half Hourly Advances for Inclusion in Aggregated Supplier\nMatrix’ and D0275 ‘Validated Half Hourly Advances’. The only difference between the two is\nthat D0036 uses local time whereas D0275 is in UTC, as the generation of the latter is not\ncovered by BSCP502. Therefore, to allow Suppliers and Distribution Businesses to use UTC,\nthe data flow D0275 should be added alongside D0036 in section 3.4.1.9 of BSCP502. The\nHHDA will continue to receive the D0036 only.\nThis change will also require the inclusion of D0275 in the SVA Data Catalogue as use of the\nflow will be formally recognised.","−",null,null,"−","Rejected"]
[801,"Inappropriate date conversion during data estimation","N/A","2002-05-03","BSCP502 appendix 4.2 outlines the estimation methods to be applied by HHDCs.  The method described in 4.2.1 (e) requires that where the Supplier provides an EAC and a Profile Class Identifier, the Default Period Profile Class Coefficients (DPPCCs) contained in Market Domain Data will be applied to the EAC in order to estimate consumption values. The BSCP wording is unclear on the time units of the DPPCCs and as a result some HHDCs have mistakenly attempted to convert the consumption into another time format.\nThis CP has been raised from SIR R3004","Add a sentence to BSCP502 section 4.2.1 (e) to explain that DPPCCs are defined in clock\ntime (BST during the summer months) and therefore the results of the estimation technique\nwill already be in clock time.","−","CPC00210",null,"Implemented"]
[800,"Mandatory Full Refreshes","N/A","2002-05-03","Modify the NHH and HH Data Aggregation rules such that full database refreshes are requested and applied periodically. This CP has been raised from SIR R2807.\nPast experience has shown that inconsistencies between SMRS and Data Aggregator databases are not always resolved by selective refreshes. Although selective refreshes should still be available at any time, periodic full refreshes should be made mandatory to ensure consistency of data.","The following changes are required to PSL140, section 1.3.2.1;  BSCP505, section 3.2.3.1; PSL150, section 1.3.2.1 and BSCP503, section 3.2.2.1.","SVG: 22","CPC00210","SVG","Aug 03 Release","Approve"]
[799,"Amendments to BSCP504","N/A","2002-05-03","A number of SIRs relating to BSCP504 are outstanding and require progression.  They consist of minor clarifications and updates to bring this BSCP into line with other documents and/or current procedure.\nSIRs: R3096; R2509; R1498; R3017; R1503.","R3096: In section 3.4.1.6, add the Supplier as a recipient of the P0028 100kW Demand Report from\nthe NHHDC, along with the Panel. This report should be sent by the NHHDC on a monthly\nbasis, listing all 100kW+ metering systems still registered that qualify for HH metering.\nR2509: Amend section 3.3.6.1 to state that the Supplier should send the Initial EAC to the NHHDC\nvia the D0052 flow.\nR1498: Sections 3.2.6.8 and 3.2.6.15(b) should be amended so that the ‘Information Required’ box\nreads ‘D0086 Notification of Change of Supplier Readings’ instead of ‘D0010 Meter\nReadings’.\nR3017: In section 3.3.7.2, part (a) re-order step three after step four. Revise the line “The NHHMO\nsends ‘new’ meter reading to NHHDC” to read “The NHHMO will obtain the initial meter\nreading and send it to the NHHDC”. This change will also be required in the corresponding\nworkflow diagram (section 2.3.7).\nR1503: Two alterations are required to the workflow diagrams and/or timetables:\n• In section 3.3.2 (Change of Measurement Class from HH to NHH), insert a step\nafter 3.3.2.3 showing the passing of EAC/AA from the NHHDC to the NHHDA.\n• Similarly, insert a step after 3.3.6.1 showing the EAC/AA going from the NHHDC\nto the NHHDA.","−","CPC00210",null,"Implemented"]
[798,"Changes to the SVA Data Catalogue","N/A","2002-05-03","SIR R2928 and CR R3070 require minor documentation changes to the SVA Data Catalogue to clarify or correct the use of certain data items. SIR R2928 The 'Profile Coefficients Requested' data item is not referenced in Part 2 of the SVA Data Catalogue, so it is unclear how this field is populated. Further investigation has shown that the field is not necessary and therefore it can be removed from the flow. CR R3070. The usage of the 'Date Action Required By' data item differs depending on the circumstances and needs to be explained clearly. The change has been successfully implemented in the MRA DTA and so the SVA Data Catalogue should be altered to ensure consistency.","SIR R2928\nRemove the data item ‘Profile Coefficients Requested’ from flow P0040 in Part 1 of the SVAA\nData Catalogue.\nCR R3070\nThe description for the data item ‘Date Action Required By’ in Part 2 of the SVAA Data\nCatalogue should be altered.","−",null,null,"−","Rejected"]
[797,"Provide a full flow for the RF (Final Reconciliation) run","N/A","2002-04-29","Currently the only full flow of the SAA I014 SO flow is the II (Interim Initial) run. For subsequent runs certain information is only included if it has changed.  There have been many settlement re-runs for various settlement dates but at present there is no flow that gives the final position taking into account any or all of the amendments in the previous runs.","To make the RF run of SAA I014 SO flow a full flow run capturing the final position of all changes that have taken place in previous runs.","−","CPC00206/CPC00226",null,"Implemented"]
[796,"BSCP 68 and CRA and CDCA Service Descriptions.","N/A","2002-04-25","Currently, the Service Description v1.0 (paragraph 6.4.3) contains the following obligation: \"Where relevant, comply with the rules and procedures detailed in BSCP 68 with respect to the transfer of the registration of Metering Systems from SMRA to CMRA and vice versa\".\nCurrently Logica are not contractually bound to BSCPs. There is therefore some ambiguity over the extent of the Service Provider's commitment to the BSCP Procedures.","Modify the CRA and CDCA Service Descriptions to include specific obligations in support of Registration Transfers by removing references to BSCP 68 and explicitly stating what is expected of the CRA and CDCA services.","−",null,null,"−","Rejected"]
[795,"Meter Readings failing NHHDC Validation.","N/A","2002-04-23","The validation checks performed by Non Half Hourly Data Collectors (NHHDCs) are used to highlight suspect meter readings that may require further investigation and possibly rejection.  However, in some instances, the unusual readings are correct and should be entered into Settlement.  This is often the case when Suppliers have been informed by their customers of specific circumstances and are expecting to see some unusual meter readings, which would be required for billing purposes. Any meter readings that fail validation are passed on to the Supplier.  At present there is no mechanism that allows Suppliers to inform their NHHDCs that they should accept such rejected readings. This CP has been raised from SIR R2799 'Readings Failing Pool Validation'.\nThis CP supersedes CP793.","A manual dataflow should be introduced between Suppliers and NHHDCs, whereby any\nD0010 meter readings that have failed validation but are deemed by a Supplier to be\ncorrect, can be sent back to the Data Collector for processing in Settlements.","−","CPC00275",null,"−","Rejected"]
[794,"Removal of requirement for CT certificates for LV CTs","N/A","2002-04-18","The present requirement (contained in BSCPs and CoPs) for CTs requires MOAs to procure test certificates for all CTs from Distribution Businesses and pass copies to the TAA as requested.  This requirement has proved difficult and expensive to administer.  There are many outstanding non compliances resulting from the failure of Distribution Businesses to supply the certificates.  LV CTs have been manufactured to Class 0.5 or better for some years now.  ELEXON have recently examined sample test certificates from all Distribution Businesses, in order to consider generic certificates. This work has indicated that all CTs manufactured to Class 0.5, or better, have the accuracy required for CoPs 3 and 5.\nIt is therefore proposed that the requirement for CT test certificates for LV is no longer necessary and should be removed provided the CTs can be identified as Class 0.5 or better.",null,"ISG: 24",null,"ISG","−","Rejected"]
[793,"Meter Readings failing NHHDC Validation.","N/A","2002-04-18","The validation checks performed by Non Half Hourly Data Collectors (NHHDCs) are used to highlight suspect meter readings that may require further investigation and possibly rejection.  However, in some instances, the unusual readings are correct and should be entered into Settlement.  This is often the case when Suppliers have been informed by their customers of specific circumstances and are expecting to see some unusual meter readings, which would be required for billing purposes. Any meter readings that fail validation are passed on to the Supplier.  At present there is no mechanism that allows Suppliers to inform their NHHDCs that they should accept such rejected readings.\nThis CP has been raised from SIR R2799 'Readings Failing Pool Validation'.","A manual dataflow should be introduced between Suppliers and NHHDCs, whereby any\nD0010 meter readings that have failed validation but are deemed by a Supplier to be\ncorrect, can be sent back to the Data Collector for processing in Settlements.","−",null,null,"−","Rejected"]
[792,"Add the MOA as a recipient of D0148","N/A","2002-04-18","PLS110 section 5.2.11 explains that the D0148 'Notification of Change to Other Parties' dataflow is sent from Suppliers to MOAs when there is a change of Data Collector.  However, this dataflow is also required to be sent when there is change of MOA (both Half Hourly and Non Half Hourly) but this is not reflected in PSL110 nor is it accurately reflected in the BSC SVA Data Catalogue.   This CP is raised from SIR R2658 'NHHMO added as a recipient of D0148 \"Notification of Change to Other Parties\" '.\nThe Data Transfer Catalogue already supports this interface.","Revise section 5.2.11 of PSL110 by adding a new frequency of ‘When Meter Operator Agent\nis to be appointed’.\nIn addition add the Supplier to MOA interface to the D0148 dataflow structure within the\nBSC SVA Data Catalogue with the source being PSL110. Currently only the Supplier to Half\nHourly MOA interface is supported by the BSC SVA Data Catalogue with the source being\nBSCP502.","−","CPC00210",null,"Implemented"]
[791,"Notification of SMRS Refreshes.","N/A","2002-04-18","BSCP503 'Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS' and BSCP505 'Non-Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS' imply that the SMRA must issue scheduled date notifications for all information refreshes (either Full or Selective Refreshes) to the Data Aggregator.  The scheduled date is only to be provided for Full Refreshes and this is not reflected in either BSCP503 or BSCP505.  This is inconsistent with BSCP501 'Supplier Meter Registration Service' as well as the Master Registration Agreement (MRA), which states that such notifications are only required for Full Refreshes.\nThis CP has been raised from SIR R2328 'Clarify Agreed Procedures to indicate that scheduled date notifications are not required for selective refreshes'.","CP0791 proposed a number of changes to BSCP503.","−","CPC00210",null,"Implemented"]
[790,"Distribution of Supplier Purchase Matrix (D0041) files","N/A","2002-04-18","Footnote 6 of step 3.3.2.3 of BSCP505 'Non Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS' explains that the D0041 'Supplier Purchase Matrix Data File' are sent by Non Half Hourly Data Aggregators (NHHDAs) to Suppliers in accordance with the Settlement Calendar, but also '…as required, by arrangement between the NHHDA and the Supplier.'  This suggests that Suppliers can opt not to receive this dataflow. This optionality is not supported by the NHHDA software developed for go-live and so NHHDAs attempting to meet the BSCP requirements are incurring extra costs.\nThis CP has been raised from SIR R2253 'Distribution of Supplier Purchase Matrix Data (D0041) files to Suppliers'.","The reference to an optional service should be removed from the footnote in BSCP505,\nmaking the D0041 dataflow mandatory.","−","CPC00210",null,"Implemented"]
[789,"Enhancements to the Validation of NHH Meter Data","ELEXON","2002-04-18","The current validation checks specified in BSCP504  and in PSL120 are lacking in certain areas: 1. The rules relating to the Maximum Demand Register Resets do not recognise a range of circumstances that may occur between meter readings. 2. The 'zero consumption' and 'twice the expected consumption' checks do not take account of Seasonal Tariffs, which may result in no consumption being recorded for several months each year. 3. The 'twice the expected consumption' check may fail due to the non-availability of Profile Coefficients, rather than any metering problems.\n4. The 'negative consumption' checking does not clearly explain that negative consumption is valid in the circumstance where the last reading was deemed prior to an actual reading, providing the current reading is higher than the previous actual reading.","CP0789 proposed amendments to BSCP504 and PSL120.","−","CPC00210",null,"Implemented"]
[788,"Definition of new SVA Manual Data Flow","ELEXON","2002-04-18","CP691 'Incorporate revised proving and validation rules in the Half Hourly (HH) Code Subsidiary Documents (CSDs)' has incorporated a series of revised proving and validation rules in the HH Code Subsidiary Documents. One of the changes incorporated within BSCP502 for CP691 relates to the situation where a Half Hourly Data Collector (HHDC) detects recorded energy in excess of the maximum permissible.  If after sending a Metering System Investigation Request (D0001) to the Supplier there is no response, the HHDC applies the rules stated in Appendix 4.1 of BSCP502.  As a result of CP691, HHDCs will notify BSCCo (via step 3.4.1.7) when such a problem has been detected and the Supplier has not given any advice on the action to be taken by the HHDC.  Although this new flow has been given a manual status, the flow itself has not been defined.","A new manual flow is required in the BSC SVA Data Catalogue and will need to be referenced in BSCP502 step 3.4.1.7.","−",null,null,"−","Rejected"]
[787,"Enhancements to Instruction File Processing","N/A","2002-04-18","PSL120 'Non Half Hourly Data Collection' describes the actions to be taken by the NHHDC when there are problems encountered with an instruction file.  The corresponding BSCP504 'Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS 'explains that once the problem is resolved, a final D0019 (Metering System EAC/AA Data) instruction file is sent to the NHHDA and the Supplier. PSL120 does not make any reference to Suppliers being sent instruction files (original or corrections).  \nIn cases where an NHHDC sends an instruction file shortly before a change of NHHDC and the instruction file fails, there is no requirement for the outgoing NHHDC to resolve the problem and send another instruction file.  Once a new NHHDC has taken responsibility there is no way to clear existing instruction failures.","CP0787 proposed to amend section 1.5.12 of PSL120 so that the Supplier is included in the information and a number of changes to PSL120 and BSCP504.","−","CPC00210",null,"Implemented"]
[786,"Minor Clarifications to BSCP507.","N/A","2002-04-18","When processing standing data change requests from Suppliers or Supplier Agents, the Supplier Volume Allocation Agent (SVAA) has adopted the practice of contacting the originator to resolve any queries before proceeding with the standing data change request.  This additional process is not documented in BSCP507. This CP has been raised from CR R2910 'Update to Stage 2 Settlement Standing Data Changes Process (AP507)'.\nIn addition the identifier of the form referenced in Appendix 4.2 needs standardising.","Modify BSCP507 as follows:\n1. After step 3.1.2 (both Workflow Diagram and Interface and Timetable Information\nreferences) add a new step 3.1.3 which will require the SVAA to liaise with the\nSupplier, in the event that there is a query with the standing data change request, to\naddress any such query.\n2. Re-number all remaining steps in process 2.1 and 3.1.\n3. In addition, the reference number of the Standing Data Change Form included in\nAppendix 4.2 should be corrected from ‘F507/012’ to ‘F507/01’.","−","CPC00210",null,"Implemented"]
[785,"Minor clarification to SSL330 'National Support Services'.","N/A","2002-04-18","Clause 1.2.6 of SSL330 explains that the National Help Desk Service (which is one of the many National Support Services provided by the Supplier Volume Allocation Agent) shall maintain a list of Market Participants and their preferred method of communication with the National Help Desk Service (i.e. fax, email or voice mail).  In cases where the preferred method is unavailable, fax must be used.  However, SSL330 does not reference this requirement.\nThis CP has been raised from CR R2686 'Amendment to clause 1.2.6 of SL330'.","Amend the last paragraph of section 1.2.6 to read:\n“In the absence of a preference, or if a preferred method is unavailable, fax must be\nused.” ","−","CPC00210","SVG","Implemented"]
[784,"Improvement to Metering System Proving Tests","N/A","2002-04-18","When a proving test is carried out on a Metering System, the Meter Operator Agent (MOA) informs the Half Hourly Data Collector (HHDC), the Supplier and the Public Distribution System Operator (PDSO) of the outcome (in the case of a failure, only HHDCs are informed).  However, there are no procedures in place to cover the case where no notification is received from the MOA on the outcome of the proving test.  At present, HHDCs assume that the proving test was successful and use the data in Settlements.\nThis CP has been raised from SIR R1736 'Inconsistency in Pool Documentation in respect of Metering System Proving Test'.","CP0784 proposed changes to BSCP502 and PSL130.","−",null,"SVG","−","Rejected"]
[783,"Minor Enhancements to BSCP501","N/A","2002-04-18","This CP outlines two changes: 1.  Remove the reference to dataflow D0171 'Notification of Distributor Changes to Metering Point Details' from step 3.4.4 of process 3.4 'Change of Supplier for Half Hourly SVA Metering System' of BSCP501. This CP has been raised from CR R3016 'Removal from AP501 of dataflow D0171 from 3.4.4'.\n2.  Add BSCP550 'Shared SVA Meter Arrangement of Half Hourly Import and Export Active Energy' as a related BSCP to Section 1.5 of BSCP501.","Remove the D0171 ‘Notification of Distributor Changes to Metering Point Details’\ndataflow from the ‘Information Required’ box in step 3.4.4 of BSCP501.\nAdd BSCP550 ‘Shared SVA Meter Arrangement of Half Hourly Import and Export\nActive Energy’ to Section 1.5 of BSCP501.","−",null,null,"−","Rejected"]
[782,"Amendments and Clarifications to BSCP15","ELEXON","2002-04-16","This CP seeks to align BSCP15 with the changing and improved processes enabled by the CDCA Improvement Project.  The CDCA Improvement Project is a LOGICA project to rectify shortcomings in the existing CDCA service.  This CP is intended to complement the improvements agreed to the CDCA service and reflect agreed custom and practice of the BSC Agent in BSCP15.   The opportunity has also been taken to undertake general housekeeping on BSCP15 to ensure that the wording, expressions and timescales used within the document are clear and consistent with related documentation.","CP0782 proposed to amend BSCP15 for inclusion in the CDCA Improvement Project.","−",null,"ISG","Implemented"]
[781,"Amendments and Clarifications to BSCP75","ELEXON","2002-04-16","This CP seeks to align BSCP75 with the changing and improved processes enabled by the CDCA Improvement Project.  The CDCA Improvement Project is a LOGICA project to rectify shortcomings in the existing CDCA service. This CP is intended to complement the improvements agreed to the CDCA service and reflect agreed custom and practice of the BSC Agent in BSCP75.   The opportunity has also been taken to undertake general housekeeping on BSCP75 to ensure that the wording, expressions and timescales used within the document are clear and consistent with related documentation.","CP0781 proposed to amend BSCP75 for inclusion in the CDCA Improvement Project.","−",null,"ISG","Implemented"]
[780,"Amendments and Clarifications to BSCP20 and BSCP06","ELEXON","2002-04-16","Amendments and Clarifications to BSCP20 and BSCP06 for the CDCA Improvement Project. This CP seeks to align BSCP20 with the changing and improved processes enabled by the CDCA Improvement Project; it will also remove specified procedures from BSCP20 and move them to BSCP06 to enable greater clarity.  The CDCA Improvement Project is a LOGICA project to rectify shortcomings in the existing CDCA service.  This CP is intended to complement the improvements agreed to the CDCA service and reflect agreed custom and practice of the BSC Agent in BSCP20.  \nThe opportunity has also been taken to undertake general housekeeping on BSCP20 to ensure that the wording, expressions and timescales used within the document are clear and consistent with related documentation.","CP0780 proposed to amend BSCP20 for inclusion in the CDCA Improvement Project.","−",null,"ISG","Implemented"]
[779,"Clarification to the proving of Half Hourly Metering Systems","ELEXON","2002-04-09","In section 4.6.1 of Appendix 4.6 BSCP502, which explains when proving tests should be carried out on Half Hourly Metering Systems, the fourth bullet should be amended to read:","In section 4.6.1 of Appendix 4.6 BSCP502, which explains when proving tests should be\ncarried out on Half Hourly Metering Systems, the fourth bullet should be amended to read:\n‘Following a concurrent Change of Supplier and change of HHDC and where there has\nbeen manual intervention of the MTD;’\n","−","CPC00210","SVG","Implemented"]
[778,"Inclusion of approved CRs in BSCP504 v4.0","ELEXON","2002-04-09","Before NETA go-live, the Agreed Procedures (APs), which formed part of the Pool Documentation, were reformatted and re-badged as the BSC Procedures (BSCPs).  ELEXON has identified a situation regarding BSCP504 in which the latest set of approved amendments made to the corresponding AP, initially driven by SIR R2803, have not been reflected in the BSCP.  Therefore a whole batch of approved changes is required to be included in BSCP504.","CP0778 proposed Pool CRs to be incorporated into BSCP504.","−","CPC00210","SVG","Implemented"]
[777,"Alterations to FAA Doc. to meet four BSC requirements.","ELEXON","2002-04-09","Alterations to FAA Documentation to meet four BSC requirements.  1. Amend the NETA Data File Catalogue and FAA IDD Part 1 to state that Bank Reports/Payment Instructions are sent to Collection Banks and the BSC Clearer. 2. Modify FAA-R011 to reference Postponed Payments as detailed in the Code N 6.6.1 b and section 7.5 of the FAA Service Description. 3. Update FAA-R012 and FAA Service Description section 8.1.2 to reflect requirements in Code N 7.1.2 (a) & (b) that describe the details which should be contained in Advice Notes.\n4. FAA-R046 should state that the Confirmation Notice for Payment Day \"A\" will be sent on day \"A+2 WDs\".","1. Amend the NETA Data File Catalogue and FAA IDD Part 1 to state that Bank Reports/Payment Instructions are sent to Collection Banks and the BSC Clearer.\n2. Modify FAA-R011 to reference Postponed Payments as detailed in the Code N 6.6.1 b and section 7.5 of the FAA Service Description.\n3. Update FAA-R012 and FAA Service Description section 8.1.2 to reflect requirements in Code N 7.1.2 (a) & (b) that describe the details which should be contained in Advice Notes.\n4. FAA-R046 should state that the Confirmation Notice for Payment Day “A” will be sent on day “A+2 WDs”.","−",null,"ISG","Implemented"]
[776,"Inconsistencies between uses of D0139 in BSCP 502 & MRA DTC.",null,"2002-04-05","BSCP 502 steps 3.3.3.4 and 3.3.4.7 both state that flow D0139 'Confirmation or Rejection of Energisation Status Change' is sent from the Supplier to the HHDC by electronic or other method, as agreed. However, the electronic method is not readily available as MRA DTC (version 4.1 onwards) does not include an instance of the D0139 data flow from Supplier to HHDC.",null,"−",null,null,"−","Rejected"]
[775,"Enhanced validation within CRA.","ELEXON","2002-04-05","Enhance Central Registration Agent (CRA) validation to reduce the number of registration errors. The Following Validation Rules could be added to reduce the number of registration errors of the forms set out in the Justification for change: 1. Do not allow a null value in the CALF value field for Open BM Units; 2. When opening a record for a BM Unit, check that this BM Unit does not already have a record open; 3. Do not allow an end date to be added to a Base BM Unit for an active Supplier; 4. Within a BSC Season, do not allow increase in the DC field; Within a BSC Season, do not allow decrease in the GC field;\n5. Check that the Lead Party Name and ID for a particular BM Unit is a valid Market Participant.","Enhance the level of validation on input of data to CRA. It is expected that these will be simple software changes to build some validation into the database (e.g. Not allowing null values for mandatory fields), and/or associated amendments to operational procedures to enhance operator awareness.","−","CPC00226","ISG","Implemented"]
[774,"Definition of new SVA Manual Data Flow","ELEXON","2002-04-05","CP691 has incorporated a series of revised proving and validation rules in the Half Hourly Code Subsidiary Documents.  One of the changes to BSCP502 relates to the situation where an HHDC detects a recorded energy in excess of the maximum permissible.  If after sending a Metering System Investigation Request (D0001) to the Supplier there is no response, the HHDC applies the rules stated in section 4.1 of BSCP502.  As a result of CP691, HHDCs will now also notify BSCCo when such a problem has been detected and the Supplier has not given any advice on the matter.  Although this new flow has been given a manual status, the flow itself has not been defined.","A new manual flow is required in the BSC SVA Data Catalogue and will need to be referenced in BSCP502 step 3.4.1.7.","−","CPC00210","SVG","Implemented"]
[773,"Change to return address in forms F601/03 and F601/05 of BSCP 601 'Metering Protocol Approval and Compliance Testing'","ELEXON","2002-04-05","It has been noticed that the return address for Forms F601/03 and F601/05 of BSCP 601 'Metering Protocol Approval and Compliance Testing' are addresses to the Panel. Steps 2.1.1 and 2.1.4 of BSCP 601 specify that these forms should be returned to BSCCo, and so a change is required to the forms to ensure that they are delivered to the correct department.","In forms F601/03 and F601/05, of BSCP 601 ‘Metering Protocol Approval and Compliance Testing’ change the return address from ‘The Panel’ to ‘BSCCo’.",null,null,"SVG","—","Withdrawn"]
[772,"Enhance D0268 'Half Hourly Meter Technical Details'","N/A","2002-04-05","Apply a number of improvements to the D0268 'Half Hourly Meter Technical Details' dataflow within the Code Subsidiary Documents to reflect existing manual processes being operated in the half hourly market. The improvements relate to the following: 1) Identify whether the half hourly site is a 'complex site' and therefore an information sheet should be provided. 2) Enhance the valid types of communication methods that can be used (for both hand held and Local Area Network (LAN) communications). 3) Identify the date when a half hourly meter has been removed.","Modify the BSC SVA Data Catalogue as outlined in the attachment to be consistent with the\nMRA. ","SVG: 22","CPC00230","SVG","Feb 03 Release","Approve"]
[771,"Modify timescale associated with provision of the SMRS","N/A","2002-04-05","PSL160 'Supplier Meter Registration Service' requires the Supplier Meter Registration Agent (SMRA) to provide an SMRS between the hours of 09:00 and 18:00. BSCP501 ''Supplier Meter Registration Service' is not explicit on when the SMRS should be provided however it defines a Working Day as ''means the period from 09:00 to 18:00 (both inclusive on any Business Day'. MRA CP105 'Provision of access to Metering Point Information' (attached) has been raised by British Gas Trading.  One of the proposed changes impacts Priority Provision paragraph 13.1.  The proposed change to paragraph 13.1 would result in the SMRS being available between 09:00 and 17:00 rather than 09:00 and 18:00.\n","This CP therefore proposes that the intent of the change proposed to paragraph 13.1 of the Priority Provisions of the MRA is reflected within PSL160 and hence that the SMRS is provided between 09:00 and 17:00.","−",null,"SVG","−","Rejected"]
[770,"Corrections to SVA PSLs 110, 120, 130 and 140.","ELEXON","2002-03-26","To correct sections of the current versions of the above Party Service Lines, in order to make reference to the BSC SVA Data Catalogue rather than an unspecified 'Data Catalogue'","PSL110 Section 1.1.5.1 - remove the words ‘and defined Data Interfaces’ from the 4th line of the\nparagraph.\nPSL120 Section 1.1.3.1 - change this section to read:\n‘The Non Half Hourly Data Collector shall send and receive data and other information\nrelating to its activities as Non Half Hourly Data Collector in accordance with the BSC SVA\nData Catalogue.’\nSection 5.4, paragraphs (f) and (g) - replace the words ‘data Catalogue’ with ‘BSC SVA Data\nCatalogue’.\nPSL130 Section 1.1.5.1 - the third line should be changed to read ‘…to satisfy its related obligations\nunder the Code and in accordance with this PSL, its Appendices and the BSC SVA Data\nCatalogue.’\nPSL140 Section 5.5, paragraphs (f) and (g) - replace the words “Data Catalogue” with “BSC SVA Data Catalogue”.","−","CPC00210","SVG","Implemented"]
[769,"Improved NHHDA Screens","ELEXON","2002-03-21","The current 'Manage Instruction Files' NHHDA screen is not very informative when dealing with received Instruction File problems such as duplicated Files, i.e. files with the same File Sequence Number but with different contents. This situation recently arose at a NHHDA site, and the ensuing debate at STAG revealed that the 'Manage Instruction Files' screen did not supply sufficient information for the users to understand, resolve and manage the problems in this area. It was agreed that this screen should be improved with additional information to make it more useful.\nDuring the investigation and analysis of the requested improvements, it was also identified that the 'Browse File Loading Statuses' screen could be improved with the same information to make it more productive to the NHHDA users.","The ‘Manage Instruction Files’ screen will have additional columns to display the received Instruction Files: • File Name • Instruction Sequence Number (both first and last) The ‘Browse File Loading Statuses’ screen will have additional fields in the ‘Instruction’ group to display the Instruction Files: • File Sequence Number • Instruction Sequence Number (both first and last) • Original File Name","−",null,"SVG","Implemented"]
[768,"D0086 Meter Readings","ELEXON","2002-03-21","The wording in BSCP504 3.2.6.10 is ambiguous and it should be specified where this requirement is Applicable. In addition, 3.2.6.11 further complicated by the fact that many DCs who have not received a meter reading on a D0086 dataflow by SSD+8 are using their own historical data related to when they previously owned the supply.  Whilst we accept that the DC is displaying a good intent to help customers receive timely accounts there is a significant risk that poor data will be used resulting in disputed reads. \nIn addition, there may have been several months or longer between each customer transfer in which a number of meter readings may have been processed. Without this more recent data, the new DC is running the risk of entering poor data into settlements.","Amend BSCP 504 to state that in the Change of Supplier process, the new DC must wait for valid historical meter reading data from the old DC prior to generating a deemed D0086 dataflow.","−","CPC00210","SVG","Implemented"]
[767,"Modification to timesteps in BSCP28 to align with BSCP 68.","ELEXON","2002-03-18","The addition of extra steps and different timescales in BSCP28, 'Approval and Notification of CVA Line Loss Factors'.  These should be applicable only in the case of the approval of CVA Line Loss Factors for a Transfer of Registration from SMRS to CMRS, in order to bring the timing of BSCP28 in line with BSCP68, 'Transfer of Registration of Metering Systems between CMRS and SMRS'.","Amend BSCP28 as follows: · Change to the timetable in 3.1.1 to include ‘or by 30 WD before “Effective From Date” in the case of Meter Transfers from SMRS to CMRS’. · Addition to 3.1.4 ACTION to specify ‘In the case of Meter Registration Transfers, submit summary report form F28/01 Part C with recommendations for Panel Approval ex. Committee. Supply any additional information.’ Corresponding addition to WHEN to read ‘Within 3WD of ref (3.1.2) above.’ · Add an additional step between 3.1.5 and 3.1.6 to say ‘Within 10WD of 3.1.4, in the case of meter transfers, if no negative responses are received by transfer co-ordinator from the panel, then the Line Loss Factors are deemed agreed.’","−",null,"ISG","−","Rejected"]
[766,"Minor documentation change to BSCP501.","ELEXON","2002-03-14","Amend section 1.5 of BSCP501 to include reference to BSCP550 as an associated BSC Procedure.","Amend section 1.5 of BSCP501 to include reference to BSCP550 as an associated BSC Procedure.","−",null,"SVG","−","Rejected"]
[765,"Introduce two new MTC's to uniquely identify actual MSIDs","N/A","2002-03-12","P67 introduces the concept of multiple Suppliers who will be able to share Active Energy (Export and/or Import) into predictable and unpredictable elements.  A flexible limit of 8 Suppliers for either the Export or the Import (7 Fixed and 1 Variable) can share this Active Energy (resulting in 9 MSIDs, one actual and eight pseudos) or greater if agreed by all the affected parties without compromising the timescales and processes described in BSCP550.\nTherefore to allow the identification of these MSIDs (both actual and pseudo) in the Supplier Meter Registration Service (SMRS) it is proposed that two new MTC's are specifically created for this purpose.","1. Change MDD to include two new MTC’s: one which will identify the actual MSID, and the other which will identify the pseudo MSID(s). A separate MDD CR ‘Meter Timeswitch Code (MTC)’ has been raised to incorporate this requirement. 2. Modify BSCP550 so that there is a responsibility on the Primary Supplier and each Secondary Supplier to allocate the correct MTC for the actual and pseudo MSIDs in SMRS, where a Shared SVA Meter Arrangement applies. In addition a sentence should be added into Section 1.2 which clarifies that each Supplier utilising the Shared SVA Meter Arrangement will allocate the correct MTC in SMRS.","−",null,"SVG","Implemented"]
[764,"Publication of updated Appendices from BSCP601 on website.","N/A","2002-03-12","Currently, it is difficult to keep appendices 3.2 and 3.3 of BSCP 601 as up to date as necessary due to the length of time that it takes to make a change to a BSCP document following BSCP 40. This CP proposes the same approach as adopted for BSCP 520. Namely, that following approval by the relevant Panel Sub Committee, the revised Appendices are made available on the ELEXON website.","Remove Appendices 3.2 and 3.3 from BSCP 601 so that it is not necessary to go through the formal BSCP 40 route for updates. Put Appendices 3.2 and 3.3 on the ELEXON website as separate document making them easily accessible by those who need to use them at short notice.","SVG: 18","−","SVG","2002-08-12","Approve"]
[763,"Identify Prepayment Meters and Remove Erroneous Data Items","ELEXON","2002-03-11","Modify the D0150 'Non Half Hourly Meter Technical Details' dataflow as follows: 1. Add 2 new data items ('MTC Meter Type Id' and 'MTC Payment Type Id') to the D0150 to identify prepayment meters. 2. Remove the 'Meter Channels' Group on the basis that the data items contained within the group relate to half hourly meters which is inappropriate for the P0150 dataflow.\nIt is intended that CP763 supersedes CP760 'Identification of Prepayment Meters within the D0150 'Non Half Hourly Meter Technical Details' dataflow'.","Modify the BSC SVA Data Catalogue so that the data items ‘MTC Meter Type Id’ and ‘MTC Payment Type Id’ are included and the ‘Meter Channels’ group is deleted from the D0150 ‘Non Half Hourly Meter Technical Details’ dataflow.","−",null,"SVG","−","Rejected"]
[762,"Meter Advance Reconciliation Results to PDSOs","ELEXON","2002-03-08","BSCP05 v2.0 step 3.1.8 states that, if appropriate, the CDCA will notify the relevant DSOs of MAR reports, along with Registrants and MOAs.   Similarly, step 3.4.1.2 of BSCP502 v3.0 states that HHDCs will send MAR reports to PDSOs in addition to Suppliers and MOAs if appropriate.   The BSC does not explicitly require Distributors to be informed of MAR results by the CDCA and indeed, DSOs/PDSOs may not always want to receive such information. However, it is reasonable that the option should exist whereby DSOs/PDSOs can request MAR results from the CDCA/HHDCs if and when they want them.  This CP therefore proposes to make the relevant changes to BSCP05 and BSCP502.\nThis CP supersedes CP624, which initially identified the inconsistency between the Code (section R6.2.1) and BSCP05.","BSCP05 step 3.1.8: remove ‘(and if appropriate DSO)’ and replace with ‘DSO (if requested)’. BSCP502 step 3.4.1.2: in the ‘To’ box, remove the second paragraph which says ‘Supplier, MOA and/or PDSO (as appropriate)’ and replace with ‘MOA and (if requested) PDSO’. The Supplier should continue to be a recipient of the flow.","−",null,"ISG","−","Rejected"]
[761,"BSCP15 Housekeeping change","ELEXON","2002-03-04","Housekeeping change to BSCP15\nFootnote 13 in Appendix 4 refers to \"Exempt BM Units\" when this should read \"Exempt Export BM Units\".","Change Footnote 13 in Appendix 4.","−",null,"ISG","Implemented"]
[760,"Identification of Prepayment Meters within D0150","N/A","2002-02-22","The D0150 dataflow does not contain any information relating to the Meter Type. Suppliers are therefore unable to determine whether the meter is a prepayment meter or not.  Provision of this information would improve the Change of Supplier process and ensure appropriate Agents are appointed to interface with a particular meter type.  \nModify the SVA Data Catalogue so that the data item \"Meter Type\" (J0483) is added with the values proposed and included within the D0150 'NHH Meter technical Details' dataflow.","Modify the BSC SVA Data Catalogue so that the data item “Meter Type” (J0483) is added with the values proposed and included within the D0150 ‘Non Half Hourly Meter Technical Details’ dataflow: K for a Key meter; S for a Smart meter; T for a Token meter; and N for a standard credit Non-Half Hourly meter.","SVG: 18","−","SVG","2002-11-28","Approve"]
[759,"Inconsistencies with estimates based on actual HH data.","N/A","2002-02-19","Appendix 4.2: there is no reference to the technique, or guidance on estimating metered data during extended public holidays, such as Christmas and New Year, when consumption patterns are abnormal compared with other similar week days. A reminder is proposed to be included. The estimation methods specified in section BSCP502 4.2.1 (c) and (d) require that estimations should be based on data limited to one month prior, or one month after, the period requiring estimation - utilising data for the same day of week and time periods.  These sections do not specify that actual data should be used on which to base estimates. This has led to inconsistencies in how HHDCs interpret the methods specified. Although previously allowed for calculating estimations in the 100kW (ERS) market, the use of actual data greater than one month old in constructing estimated data is not permitted in BSCP502.","CP0759 proposed amendments to BSCP502.",null,null,"SVG","—","Withdrawn"]
[758,"Improvements to estimation and validation techniques in BSCP502","N/A","2002-02-19","Appendix 4.2: there is no reference to the technique, or guidance on estimating metered data during extended public holidays, such as Christmas and New Year, when consumption patterns are abnormal compared with other similar week days. A reminder is proposed to be included.","CP0758 proposed amendments to BSCP502.",null,null,"SVG","—","Withdrawn"]
[757,"Missing Timescale in PSL110 Section 5.3.2","N/A","2002-02-19","The Service Level for Serial 1 in Section 5.3.2 of PSL110, \"SVA Meter Operation\", currently states: i) 95% rectified within 5 WD of notification; i) 99% rectified within WD of notification.\nThere is no timescale defined in ii) above.","Amend the Service Level to: ii) 99% rectified within 15 WD of notification.","−","CPC00210","SVG","Implemented"]
[756,"Use of email as an alternative to Authorised Signatures","N/A","2002-02-19","Many of the BSCPs involve procedures where BSC Agents are required to check Parties' authorised signatures before any further action requested by the Party is taken by the BSC Agent.  In practice however, Parties have been sending requests via email and so their requests do not contain all the proper authorisation information. The Central Service Agents have coped with these by accepting requests if the sender's email address is the same as that of the authorised person.  \nIt is proposed to change the BSCPs to recognise the use of email.","The steps in the following BSCPs that involve initial flows from parties to BSC Agents should be amended so as to allow requests to be sent by email in addition to fax and/or post: BSCP15 v2.0, steps 3.1.1 & 3.4.1 BSCP20 v3.0, steps 3.1.1 & 3.4.1 BSCP75 v2.0, step 3.1.1 The ‘Method’ column in the above steps will require changes to include the medium of ‘email’. Any notes that explain the need for authorised signatures should be changed so they only apply when the medium used is fax or letter/post. BSCP38 (Authorisations) would also be changed to allow authorisation requests to be submitted by email as well as letter or fax, and that where email is used, no additional authorisation is sought. Changes will be required in the CRA and CDCA Service Descriptions to explain that email requests may be processed without additional authorisation.","−","CPC00218","ISG","Implemented"]
[755,"Enhanced ECVAA Reporting","N/A","2002-02-19","During the recent collapse of some Enron companies, ELEXON arranged for a number of temporary changes to the production of the Forward Contract Report :- • increasing the frequency of production from two to five times per day;  • including data for the current day together with the next seven days; and • Provision of an extended Forward Contract Report providing long term information beyond the usual seven day horizon.  \nThese were provided to assist Parties in confirming their notified contract position with the ECVAA during the exceptional circumstances.  In light of the increased information these reports provided, it would seem helpful, subject to costs, to consider making enhancements to reports generated by the ECVAA. This would increase the routine reporting to Parties, and help in the management of any future market problems.","CP0755 recommends two specific enhancements to ECVAA reporting that will provide Parties and Notification Agents with more information relating the processing of ECVNs and MVRNs by the ECVAA.","−",null,"ISG","Implemented"]
[754,"Correction of Defect in SAA-I014 Flow 2 Report","National Grid","2002-02-13","Section 5.17 of the current IDD Part 2 document (version 3_6) states that certain information is only included in runs subsequent to the 'II' if it has been changed. The list of groups covered by this is MEL, MIL, FP2, BO2, and BO3. It is understood that the current system does not adhere to these rules. In particular, it does not report changes to zero. This should be investigated and the necessary changes to the system made to match the IDD.\nCP610 extends the list of groups referred to above to include Bid-Offer data (BO4). Whilst this is a related matter CP610 does not resolve the above issue which needs to be addressed independently of progress on CP610.","The system should be changed so that the defects identified above (and any other defects causing any changes not to be reported) are rectified, so that the system reports ALL changes, as stated in the IDD. For the avoidance of any doubt, the IDD should specifically state that ALL changes (including changes to zero) are reported in subsequent runs.","−","CPC00226","ISG","Implemented"]
[753,"Improvements to the Metering Registration Process","ELEXON","2002-02-13","Amend BSCP68, forms and related documents.","A number of changes need to be made to BSCP 68 and therefore related documents to clarify and simplify the transfer process and to remove inconsistencies. For example · Rewritten BSCP 68 timetable · Rewritten BSCP 68 forms · Changes to timetables in related BSCPs","−",null,"ISG","Implemented"]
[752,"Clarify the NHH Deemed Reading Rules at Final Reconciliation","ELEXON","2002-02-12","Change PSL120 'Non Half Hourly Data Collection' and BSCP504 'Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS' to clarify the rules which apply when an Estimated Annual Consumption (EAC) has been provided for the Final Reconciliation Run (RF).","The following changes are proposed: 1. In PSL120, replace paragraph 1.5.4.2 d with paragraph 1.5.7.10 and remove paragraph 1.5.7.10. 2. Change BSCP504 so that Appendix 4.5 ‘Deemed Meter Advance Calculation’ and it’s cross-references are removed on the basis that this section repeats text covered in PSL120 or the BSC.","−","CPC00210","SVG","Implemented"]
[751,"Amendments and Clarifications to BSCP03 for CDCA","ELEXON","2002-02-12","This CP seeks to align BSCP03 with the changing and improved processes enabled by the CDCA Improvement Project.  The CDCA Improvement Project is a LOGICA project to rectify shortcomings in the existing CDCA service.  This CP is intended to complement the improvements agreed to the CDCA service and reflect agreed custom and practice of the BSC Agent in BSCP03.","Amend BSCP03 for inclusion in the CDCA Improvement Project","−",null,"ISG","Implemented"]
[750,"Amendments to BSCP301","ELEXON","2002-02-12","BSCP301 (Clearing, Invoicing and Payment) contains an initial registration form (BSCP301/4) for Funds Accession Details. However, there is no procedure in place to allow Parties to make changes at a later date to the Funds Accession Details. Proposed solution:\nAmend the existing form and re-number it as BSCP301/4(a) and create a new form, BSCP301/4(b) entitled \"Amendments to Funds Accession Details\" as detailed in the attached Appendix.","Amend the existing form and re-number it as BSCP301/4(a) and create a new form, BSCP301/4(b) entitled “Amendments to Funds Accession Details” as detailed in the attached Appendix.","−","CPC00226","ISG","Implemented"]
[749,"Formalising confirmation of Exempt Export BM Unit Status","ELEXON","2002-02-11","Paragraph K1.5 of the BSC creates a process where any Party which is responsible for a Generating Plant (other than that whose exports are measured by SVA metering systems) must provide details to BSCCo stating why the Plant should be treated as Exemptible (as defined in K1.2.2(c)) before taking any steps under Section K which follow from Exemptible status - BSCCo then taking the appropriate steps to verify such status and informing the Party of its conclusions.  However, there is presently no formal procedure for a Party to apply to have its Generating Plant seen as Exemptible for the purposes of the Code, or for BSCCo to verify whether a Plant should be considered as such and to confirm its decision to the Party concerned.","CP0749 proposes to add a new step to BSCP15 (requiring renumbering of the original step 3.1.5 onwards).","−",null,"SVG","Implemented"]
[748,"Estimation of Reactive Metering Data","ELEXON","2002-02-08","As part of the Disputes Process Review possible areas for improvement have been assessed.  One of these is the proposal to use email when raising disputes, rather than fax.  This will significantly reduce the effort in producing the briefing packs for TDC members (which currently takes over a day per meeting and could be more than halved) and improves other more general administration (for example, maintaining the Disputes filing system).  It will also improve speed of communications when additional copies of documents are requested, for example.\nIn order to implement this change BSCP11 would need minor changes.","The following relatively minor changes to BSCP11 are needed. Section 4 has numerous references to “email or fax” and “Fax or an agreed electronic interface”, these would need to change to “email”. Additionally two caveats need to be added to Section 4 stating that : • if a participant does not have email or in an emergency situation (for example, a significant IT system failure) then fax could be used and giving the fax number to use in this situation. • the “mailbox id” from a participant will be acceptable as an “authorised signature” (if it matches the signatory named for disputes on BSCP38) and stating that an acknowledgement will be sent by the next working day, as an added security check. Forms F1 to F10 (inclusive) and F13 (which all give the fax number) would need to be changed to delete the fax number and add the email address (the generic disputes mailbox email address). The ELEXON LWI will also need to be re-worded to accommodate the change.","−",null,null,"−","Rejected"]
[747,"Introduction of a more efficient D0265 data flow format.","ELEXON","2002-02-07","Both the CDCA Service description and URS state that the CDCA shall collect and validate active and reactive metering data. Both documents then go on to detail the estimation process if data is subsequently shown to be invalid or if no data was collected in the first place. However, this estimation process only applies to data associated with active meters, it specifically excludes data from reactive meters. BSCP03 which is the NETA baseline document which describes the data validation and estimation process mirrors the CDCA SD and URS, however, it does not specifically remove reactive data from the estimation process although it is inferred since the estimation process is not suitable for reactive data.\nIt should be noted that there was no estimating process for reactive energy under the P&SA.","The ambiguity should be removed from BSCP03 that the estimation process does not apply to Reactive Energy data.","−",null,"SVG","Implemented"]
[746,"Introduction of a more efficient D0265 data flow format.","ELEXON","2002-02-06","The D0265 version 001 data flow is not a very efficient design for the publication of Distribution Business's Line (LLF data. It is very difficult to use for validation checking, and due to its large size incurs very large DTN costs to distribute. Various papers in the past have been written suggesting improvements to the design of LLF information in the data flow in order to reduce its repetition.  This CP proposes the introduction of a new, more efficient, design for the D0265 (version 002). It is thought that the introduction of this new revised format D0265 data flow would reduce a typical 50MB D0265 version 001 data flow file to about 150KB, i.e. a DTN saving of £299 per 50MB file.  In a typical year, 12.5GB of D0265 data is sent across the DTN in 386 data flows at a cost in the region of £75K. Almost all of this cost would be saved as a result of the introduction of this CP.","It is proposed to replace version 001 of the D0265 with a more efficient design format for the D0265, i.e. version 002. This would compress repetitive LLF data for a Line Loss Factor Class (LLFC), and allow LLFCs to be grouped together for the same LLF data. The proposed design is illustrated in Annex A. The resulting output is almost identical to the format used by the Distribution Business for their LLF summary reports.","−",null,"SVG","−","Rejected"]
[745,"Assignment of CALF values to new BMU Units","ELEXON","2002-02-06","This Change Proposal has been raised to address the problem that BM Units are being registered without Credit Assessment Load Factor (CALF) values in certain circumstances.  This issue arose primarily as a result of instances where new Suppliers register with the CRA, who then automatically generate 12 Base BM Unit. The registration of these BM Units is being completed before the CALF values are provided by ELEXON.","ELEXON needs to be informed, by the CRA, when a Party requests registration of a new BM Unit (BSCP15, steps 3.1.6 and 3.4.4) or when a Party registers as a Supplier through BSCP65 and 12 Base Units are automatically generated. There should be an obligation on the CRA to obtain the relevant CALF values from ELEXON before completing the registration. The functional requirements in the CRA URS need to be modified, such that on registration of new BM Units: a) the CRA sends a copy of the registration form to ELEXON within 1 WD (as specified in BSCP15); and b) ELEXON responds with the CALF values required using the current interface CRA-I011 (within 2 WD). The CRA URS, BSCP15 and BSCP65 should therefore be modified to detail the step whereby ELEXON informs the CRA of the CALF value. This should state that the registration is not completed until the CALF value has been assigned.","−",null,"ISG","−","Rejected"]
[744,"Notice Period for Category 1 non-compliance reminders","ELEXON","2002-01-25","Section 3.5.4 of BSCP26 states that Category 1 non-compliance reminder notices from the TAA to the applicable Registrant should be sent within 11 WD but the TAA URS F008 2 states 10 WD.  However, the TAA Service Description Section 3.4.3 states that the TAA should comply with the timescales set out in BSCP26.\nNotice Period for when Category 1 non-compliance reminder notices are to be sent by TAA","Amend TAA URS F008 2 to reference 11 WD and not 10WD.","−",null,"ISG","Implemented"]
[743,"Changes to BSCP526 and BSCP26.","ELEXON","2002-01-22","Part A  Update BSCP 526 (Technical Assurance of Half Hourly Metering Systems for Supplier Volume Allocation) to add Meter Operators to Suppliers and Distribution Business as parties to be notified when scheduling a site visit with the provision that the Supplier retains overall responsibility for arranging the visit.\nUpdate BSCP 26 (Technical Assurance of Half Hourly Metering Systems for Central Volume Allocation) to add Meter Operators to Registrants as parties to be notified when scheduling a site visit with the provision that the Registrant retains overall responsibility for arranging the visit.","These changes were endorsed by the Performance Assurance Board (PAB) on 10 October 2001 as a pragmatic way forward to ensure that Meter Operators are made aware of scheduled Technical Assurance visits.","−","CPC00226",null,"Implemented"]
[742,"Removal of HH Instruction Processing Specification from SVA DC","N/A","2002-01-16","Appendix H of the current master version of the SVA Data Catalogue: Volume 1 - Data Interfaces references the Half Hourly Instruction Processing Specification which is not a standalone ELEXON Configuration Item in its own right. \nRemove Appendix H of the SVA Data Catalogue: Volume 1 - Data Interfaces and any other references to the Half Hourly Instruction Processing Specification.","Remove Appendix H of the SVA Data Catalogue: Volume 1 – Data Interfaces and any other references to the Half Hourly Instruction Processing Specification.","−",null,"SVG","−","Rejected"]
[741,"Removal of NHH Instruction Processing Specification from SVA DC","N/A","2002-01-16","Appendix G of the current master version of the SVA Data Catalogue: Volume 1 - Data Interfaces references the Non Half Hourly Instruction Processing Specification which is not a standalone ELEXON Configuration Item in its own right. On 4 December 01, SVG authorised version 5.0 of the Non Half Hourly Instruction Processing Specification and agreed that it should become a standalone ELEXON Configuration Item (SVG/09/113).","Remove Appendix G of the SVA Data Catalogue: Volume 1 – Data Interfaces and any other references to the Non Half Hourly Instruction Processing Specification.","SVG: 41",null,"SVG","−","Rejected"]
[740,"Notification of a Party's expulsion or withdrawal.","N/A","2002-01-16","BSCCo should notify all Parties, BSC Agents, Panel Members and the Authority when a Party either withdraws or is expelled from the Code.\nExpansion is required of steps 3.3.4 and 3.4.8 in the BSCP65 Interface Timetable to state that the BSCCo will advise the Authority, Panel Members, Parties and BSC Agents whenever a Party withdraws or is expelled from the Code.","BSCP65: expansion of steps 3.3.4 and 3.4.8 in the Interface Timetable to state that the BSCCo will advise the Authority, Panel Members, Parties and BSC Agents whenever a Party withdraws or is expelled from the Code","−",null,null,"−","Rejected"]
[739,"Services Description Updates to reflect Code changes v1.0 to v1.1.","N/A","2002-01-09","BSC Agent Service Descriptions need to be updated to reflect the changes between version 1.0 of the Code and the Go-Live designated version (1.1).  The following areas should be included in the CDCA and ECVAA Service Descriptions: § Notification Clock Changes; § Resubmission of Energy Contract Volume and Metered Volume Reallocation Notifications; § Failures of the ECVAA System; § ECVAA System Withdrawal; and\n§ Default Line Loss Factors.","Amendments to BSC Agent’s Service Descriptions to ensure that obligations in the Code are clearly recorded as contractual obligations on BSC Agents.","−",null,"ISG","Implemented"]
[738,"Update to Contact Numbers in BSCP42","N/A","2002-01-09","The numbers for contacting an ELEXON Representative on a Business Continuity matter are out of date in the present BSCP.","The numbers are currently cited as: 04325 309410 and: 04325 309183. These should be updated to: 07625 309410 and: 07625 309183","−",null,"ISG","−","Rejected"]
[737,"Volume restriction on use of 1kW advance","N/A","2002-01-07","Removal of the current restriction in PSL120 that the nil-advance erroneous transfer procedure can only be applied when less than 100 metering points have been erroneously registered on a single day.","Removal of the current restriction in SL120 that the nil-advance erroneous transfer procedure can only be applied when less than 100 metering points have been erroneously registered on a single day.","−",null,"SVG","−","Rejected"]
[736,"Timing of BMRS Reporting of Indicative Imbalance Prices",null,"2002-01-07","The parameter that defines the maximum amount of time the Central Service Provider has to publish indicative imbalance prices on the BMRS will be increased from 15 to 45 minutes (when Modification P18A is implemented by the BSC Systems Release 2 Project in March 2002). This will be documented in the BMRA Service Description.\nThis change proposal has been raised to ensure that this new information is reflected in the significant documentation for BSC Systems Release 2, either within the original BMRS Service Descriptions or the BMRS User Requirement Specification.","This is a documentation change to ensure the BMRS Service Description, the BMRS User Requirement Specification and the Reporting Catalogue (Section 2.3) reflect the final implementation, by changing the limit from 45 minutes to 15 +.","−","CPC00226","ISG","Implemented"]
[735,"Formalisation of Manifest Error process","ELEXON","2002-01-04","The current process for resolving Manifest Errors is very informal and responses are required from Participants within strict timescales to resolve the claim where appropriate, for the respective SF Run. The process that is being used currently is very ad hoc and needs to be formalised in a similar manner to the existing Disputes process.  \nThere needs to be formal timescales placed upon Participants to ensure the process is run and managed within the strict timescales of the scheduled SF Run.","The creation of a new BSCP entitled Processing of Manifest Error Claims.","−","CPC00226","ISG","Implemented"]
[734,"Requests for High Grade Service","ELEXON","2002-01-03","Update the BMRA URS to state that the BMRA should notify BSCCo of the number of Parties that have requested the High Grade Service in each month.","BMRA URS version 2.3 BMRA-I013 “The system shall, on the 15th working day of each month, collect information required for charging BSC parties under Schedule D of the Code and send this to BSCC Ltd.","−",null,"ISG","−","Rejected"]
[733,"Reference to Interim Information and Panel approved delays","ELEXON","2002-01-03","1. Interim Initial to be replaced by Interim Information in the SAA URS.\n2. SAA URS to reference the obligation to delay Timetable Reconciliation Volume Allocation or Timetable Reconciliation Settlement Runs as approved by the Panel.","1. Terminology should be amended to avoid future confusion: Interim Initial to be replaced by Interim Information in SAA URS Section 4.2 and F003. 2. Delays of runs specified under the Code Section U 2.3.3 should be references in the SAA URS.","−",null,null,"−","Rejected"]
[732,"Rewrite of BSCP 528 and consolidation of BSCP 528 Addendum","ELEXON","2002-01-02","BSCP528 \"SVA Line Loss Factors for Half Hourly and Non Half Hourly Metering Systems registered in SMRS\", and BSCP 528 Addendum \"Approval of SVA Line Loss Factors for initial market opening\", should be completely revised to reflect current working practice. Opportunity should be taken to consolidate the BSCP 528 Addendum into BSCP 528 at the same time.",null,"−",null,null,"−","Rejected"]
[731,"Rewrite of BSCP 528 and consolidation of BSCP 528","N/A","2002-01-02","BSCP528 \"SVA Line Loss Factors for Half Hourly and Non Half Hourly Metering Systems registered in SMRS\", and BSCP 528 Addendum \"Approval of SVA Line Loss Factors for initial market opening\", should be completely revised to reflect current working practice. Opportunity should be taken to consolidate the BSCP 528 Addendum into BSCP 528 at the same time. Rewrite of BSCP 528 and consolidation of BSCP 528 Addendum","There are a number of changes required to BSCP528 to reflect current working practice.","−",null,"SVG","Implemented"]
[730,"Upgrade to UNIX 5 for NHHDA and EAC/AA software","N/A","2001-12-21","The ELEXON-owned NHHDA and EAC/AA software products are currently configured to run on UNIX 4.0.f. However, support for UNIX 4.0.f by Compaq will expire on 30 September 2002.\nAs a result, it will be necessary to reconfigure and recompile the NHHDA and EAC/AA software to run on UNIX 5.1.A (or higher) to ensure that these products will be fully supported after 30 September 2002.","Logica to reconfigure and recompile the NHHDA software to run on UNIX 5.1.a (or higher). Logica have quoted for the combined upgrade for ISRA, NHHDA and EAC/AA and will provide a separate quote for the change to just the NHHDA and EAC/AA software.","−",null,"SVG","Implemented"]
[729,"Inconsistent Terminology between BSC, CSD & BSC Agents","N/A","2001-12-19","Four items of terminology relating to Indebtedness Data in CSDs and BSC Agent Specifications do not match those in the BSC. The items within the CSDs and BSC Agent Specifications are: • Credited Energy Volume • Aggregated Energy Contract Volume • Indebtedness (%) • Credit Limit The corresponding items within the BSC are: • Credit Assessment Credited Energy Volume • Account Bilateral Contract Volume • Credit Cover Percentage • Energy Credit Cover","It is proposed that the inconsistent items contained within the CSDs and BSC Agent Specifications be replaced with the accurate terminology in order to maintain consistency with the BSC.","−",null,"ISG","−","Rejected"]
[728,"Estimation of Reactive Metering Data","ELEXON","2001-12-18","The CDCA Service description and URS state that the CDCA shall collect and validate active and reactive metering data. Both documents then go on to detail the estimation process if data is shown to be invalid or if no data was collected. However, this only applies to data associated with active meter - it specifically excludes data from reactive meters. BSCP03 - the NETA baseline document which describes the data validation and estimation process - mirrors the CDCA SD and URS.  However, it does not specifically remove reactive data from the estimation process, although it is inferred since the process is not suitable for reactive data.\nIt should be noted that there was no estimating process for reactive energy under the P&SA.","The ambiguity should be removed from BSCP03 and a statement made that the estimation process does not apply to reactive energy data. The first paragraph of Section 1.7 of BSCP03 should be reworded to:- ‘Where there is missing or suspect metered data the following are a set of guidance rules for estimating the metered data. Estimation shall only be performed for active energy data. Reactive data will not be estimated.’","−",null,"ISG","−","Rejected"]
[727,"Enhancements to the SVA BM Unit registration process","ELEXON","2001-12-18","During NETA testing a number of problems were experienced during the SVA Balancing Mechanism (BM) Unit registration process and these relate to: 1. The provision of the BM Unit from the CRA to BSCCo (via the P0193 / CRA-I020 Operations Registration Report) and the SVA Agent for use in Market Domain Data (MDD) (via the P181 / CRA-I015 BM Unit Registration Data File).  2. The validation undertaken by BSCCo to compare the data provided by the SVA Agent (via the P0181 / CRA-I015) against the relevant MDD Change Proposal(s). 3. The information that the BSCCo provides to the SVA Agent instructing them to load the BM Unit data (via the P0181 / CRA-I015). 4. The wording associated with the timescales for proposing changes to BM Unit data.","Amend the following CSDs: 1. BSCP509 “Change to Market Domain Data”; 2. BSCP508 “Supplier Volume Allocation Agent”; and 3. SVAA SSL360 “Market Domain Data Management”.","−","CPC00210","SVG","Implemented"]
[726,"Improvements to the Registration BSCP Forms","ELEXON","2001-12-07","A number of changes are proposed to the area of Registration, which impact a total of 8 BSCPs.","The following BSCPs should be updated to reflected the changes described above: ! BSCP15 BM Unit Registration ! BSCP20 Registration, Commissioning and Proving of Metering Systems for Central Volume Allocation ! BSCP31 Registration of Trading Units ! BSCP38 Authorisations ! BSCP41 Report Requests & Authorisation ! BSCP65 registration of Parties and Exit Procedures ! BSCP71 ECVNA and MVRNA Registration, Authorisation and Termination ! BSCP75 Registration of Meter Aggregation Rules for Volume Allocation Units","−",null,"ISG","Implemented"]
[725,"Enduring Solution for Historical Overwrite in ECVAA","N/A","2001-11-26","CP539 implemented an interim solution to the Historical Overwrite issue within ECVAA.  For an enduring solution, it is proposed that ECVAA be amended to ensure that all data within any submitted Notification, ECVN and MVRN, for Settlement Periods for which Gate Closure has already passed, at the deemed time of receipt, should be disregarded, whether the notification applies within day, or to a range of dates. \nThe associated counterparties to the notification and the submitting Notification Agent would receive a feedback report from ECVAA indicating which data, if any, has been disregarded. This will contain the Settlement Date and Settlement Period from which the Notification became effective, thus enabling a Party and Notification Agent to determine which portion of data has, if any, been disregarded.","On receipt of valid Energy Contract Volume Notifications and Metered Volume Reallocation Notifications, ECVAA will determine which data, if any, in the submission is historical, i.e. pertaining to Settlement Periods for which Gate Closure has already passed and will disregard this data.","−",null,"ISG","Implemented"]
[724,"Amendment to BSCP508 “Supplier Volume Allocation Agent”","SVA. Agent","2001-11-13","Section 3.8 of BSCP508 currently states that the MDDM  should update the MDD Matrix with new distribution details within 1 WD of being notified of the change and send confirmation that the change has been made within 1 further working day.  However, new distribution details are added to the MDD Matrix as part of the Update process which is scheduled in accordance with timescales published in MDD Circulars. These obligations cannot therefore be met.\nThe inability to meet the current requirements of BSCP508 has been identified as a control weakness by the recent PwC audit.","The following changes to BSCP508 are proposed. 1. Section 3.8 amended to reflect the details given in the attachment. 2. The workflow diagram shown in section 2.8 amended to reflect the changes to section 3.8.","−","CPC00210","SVG","Implemented"]
[723,"Automated Meter Reading","British Gas Trading","2001-11-09","The emergence of NHH New Technologies has provided the opportunity for market participants, particularly Suppliers, to be able to automatically retrieve meter readings remotely and at a frequency in some cases, greater than that recorded by HH systems.\nThere are no current provisions in BSCP 504 or Party Service Line 120 to indicate how meter readings from such new meter technology should be treated. The requirements stipulated within BSCP 504 and PSL120 do not accommodate the use of this emerging Automatic Meter Reading (AMR) technology. It is proposed that the requirements within these documents are amended to accommodate AMR technology.","To amend BSCP 504 and PSL120 to accommodate the requirements of AMR","−",null,"SVG","−","Rejected"]
[722,"Special Case' DAA Termination","N/A","2001-11-07","The, 'NHH Instruction Processing Specification', which is an appendix to the SVA Data Catalogue, contains the following statement in section 3.2.1 (d), referring to a 'special case' Data Aggregator Appointment termination instruction:- \"In order to cater for SMRS developments which, because of timescale pressures, cannot support creation of a Data Aggregator Appointment Details instruction as specified when a previously open ended Data Aggregator Appointment has its Effective To Settlement Date set, the following dedicated processing is included.  It should be noted that this processing is not considered part of the instruction processing specification and its longer term support will be an issue for the ensuing Design Authority.\"\nThe use of this 'special case' instruction is now firmly established in practice, such that it could now be considered part of this specification.","Remove the statement, detailed above, from the box in section 3.2.1.(d). Add the following short historical note, to the bottom of the box in section 3.2.1 (d), for reference: (Note2: This special case was originally only proposed as a \"short term\" measure whilst SMRS could not support the creation of a Data Aggregator Appointment Details instruction as specified when a previously open ended Data Aggregator Appointment has its Effective To Settlement date set. It was not, therefore, formally part of the Instruction Processing specification. However, its use is now firmly established in practice and it is therefore now part of this Instruction Processing specification).","−",null,"SVG","Implemented"]
[721,"Enhancements to BSCP509 \"Changes to Market Domain Data\"","ELEXON","2001-11-07","As a result of a walkthrough held on 23rd February 01 for \"Supplier Stops Trading\" (Logica document reference 30-030312, version 1_3) organised by Logica, a number of changes are proposed to BSCP509 \"Changes to Market Domain Data\".\nThese changes are opportune and should therefore be implemented when other higher priority changes are being incorporated within BSCP509.","1) 1.3 “Use of the Procedure”. a) The second paragraph states that the SVAA will be notified of a change to MDD no later than 7 Working Days before the Effective Date. This timescale may not always be applicable and ELEXON and SVAA may need to agree alternative timescales, providing these do not compromise the timescale required by Market Participants to load and validate the MDD into their systems and notify ELEXON of errors / suspected errors. Modify this paragraph so that it is clear that for the majority of instances the 7 days is appropriate but less time may apply, where agreed between ELEXON and the SVAA. b) This proposal also impacts paragraph four. Therefore modify the first sentence so that the Market Participant has “…. 2 Working Days from receipt of the MDD” to contact ELEXON if they believe the changes to be invalid or different to those which were agreed. 2) 4.11 “Registration of Balancing Mechanism Unit”. Add reference “F509/01, Part B in Appendix 5.2” to step 4.11.4, Information Required box. 3) Appendix 5.2 “MDD Change Request Form”. Add “CRA” as an optional recipient of the form to “Part B” for the purposes of Balancing Mechanism Unit registrations.","−","CPC00210","SVG","Implemented"]
[720,"FAA's Involvement in Market Entry Process","ELEXON","2001-11-07","BSCP65 \"Registration of Parties and Exit Procedures\" documents the processes for BSC Parties who accede/de-accede from the Balancing and Settlement Code (the Code). There are a number of areas where interactions with the Funds Administration Agent (FAA) are not specified or are specified incorrectly.\nThere is currently an operational activity whereby the FAA is notified by ELEXON that a party has acceded. This CP proposes to implement this activity formally within BSCP65.","Modify BSCP65 so that it fully incorporates the interfaces with FAA and other BSC Agents.","−",null,"ISG","−","Rejected"]
[719,"Formalisation of Manual Interactions for Credit Cover","ELEXON","2001-11-07","Informal arrangements exist between BSCCo and the FAA relating to the provision of Credit Cover when:\n1) The FAA currently notifies the ECVAA of changes to Credit Cover via dataflow ECVAA-I006 / FAA-I019 \"Credit Limit Data\".  However there is no requirement for this notification to be sent to the BSCCo.  BSCCo requires this data so that they can ensure that the ECVAA system has been updated with the changes to the Credit Cover.  BSCCo have implemented an informal process whereby the FAA notifies BSCCo of Credit Cover changes via e-mail.  If the ECVAA rejects the file submitted by the FAA, then the FAA will be required to notify BSCCo of a revised file.","This CP proposes to formalise the existing informal arrangements","−",null,"ISG","−","Rejected"]
[718,"SVAA SL310 - Defaulting Temperature Data Rules","N/A","2001-11-06","Presently when no Temperature data is received from the Met Office for a GSP Group then the SVAA defaults under ELEXON's authorisation to the previous Settlement Day's data as per Section 1.2.6 of SVAA SL310.  This will continue indefinitely if no data is ever received and has led to poor defaults when the data has been repeated due to the weather station not reporting for a number of consecutive days.","In order to avoid using poor data when the service provider is unable to provide estimates, the final default selection rule in section 1.2.5 (rule 1.2.5.3) of SVAA SL310 should be amended to reflect one of the following options, with the second being the preferred option: 1) If no Temperature data is received and the default data had already been defaulted to the previous Settlement Day then the average temperature data of the adjacent GSP Groups is taken. 2) The SVAA’s contract is amended so they are obliged to get a default temperature from another site in the affected GSP Group and the SVAA SL is amended to allow this. CGEY have received a list of alternative temperature stations from the Met Office that can be used if this option is pursued.","−","CPC00210","SVG","Implemented"]
[717,"Automated Meter Reading","British Gas Trading","2001-11-02","The emergence of NHH New Technologies has provided the opportunity for market participants, particularly Suppliers, to be able to automatically retrieve meter readings remotely and at a frequency in some cases, greater than that recorded by HH systems.\nIt is proposed that BSCP504 and PSL120 are amended to accommodate AMR technology.","To amend BSCP 504 and PSL120 to accommodate the requirements of AMR.","−",null,"SVG","−","Rejected"]
[716,"Change of tenancy and annual calculation of Load Factors","ELEXON","2001-10-24","BSCP516 Appendix 4.4 provides for instances where there is less than the 12 months of metering data necessary for NHHDCs to complete their obligation in AP516 3.2 to recalculate the Load Factor of NHH Maximum Demand meters every February. However, this provision does not specify for instances where the lack of 12 months data is due to change of tenancy and therefore possibly a change of use and consequently a change of Load Factor.\nAlso, it is proposed to amend the wording in Period description i and ii from 'valid metering periods' to 'valid meter readings' for clarity.","Amend section in 4.4.","−",null,"SVG","Implemented"]
[715,"Clarification of HHDA data anomaly check","N/A","2001-10-24","The specification for the HHDA data anomaly check, 'Measurement Quantity by LLF Class does not match Measurement Quantity defined by HHDC (specified in BSCP 503 'Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS' Appendix 4.3, subsection 1.F), needs to be clarified since the Measurement Quantity ID cannot be derived from the LLFC ID supplied by SMRS. The MDD does not provide any linkage between LLFC ID and Measurement Quantity ID.\nThis change proposes that the HHDA data anomaly check should be redefined to check that the 'Direction of Energy Flow' attribute of the Measurement Quantity ID, as supplied by the HHDC, matches that derived from the LLFC ID, as supplied by SMRS.","Replace the present BSCP503 Appendix 4.3 subsection 1.F text with the following text:-\n“Mismatch in the Direction of Energy Flow information provided by SMRS and HHDC.\nCheck that the Direction of Energy Flow derived from the LLFC ID (J0147) provided by SMRS, matches the Direction of Energy Flow (J0727) derived from the Measurement Quantity ID (J0103) provided by the HHDC. For the purpose of this check, values of ‘A’ and ‘B’ for the LLFC ID’s MS Specific LLF Class Indicator (J0775) can be regarded as Import, and values of ‘C’ and ‘D’ can be regarded as Export. If there is a mismatch, treat the consumption value as zero and report the anomaly to the HHDC & Supplier”.","−","CPC00210","SVG","Implemented"]
[714,"Clarifications to Meter Read Audit Trail","ELEXON","2001-10-24","PSL120 defines requirements for Non Half Hourly Data Collectors (NHHDCs) regarding audit trails that must be maintained for meter readings processed.  An audit trail allows NHHDCs to trace the source of a reading to verify its accuracy for use in settlements. Non-compliance with current obligations has been identified by the Auditor, and the issue has been pursued using ELEXON's Performance Issue Management Process.  However, compliance across the industry has not been achieved because some NHHDCs feel the requirements place unnecessarily onerous data storage burdens on them.\n","This CP proposes amendments to the wording of PSL120 to clarify workable data storage levels, and to establish specifications for minimum requirements.","−",null,"SVG","Implemented"]
[713,"Correction to ECVAA Service Description","ELEXON","2001-10-16","As part of the ECVAA Interim Release, CP519 implemented a methodology by which the ECVAA calculates a Trading Party's 'minimum eligible amount' prior to Credit Cover reduction.  Although the CP has been implemented successfully within the ECVAA System, an error was made in the drafting of the Service Description that has left an inconsistency in the definition of a Trading Party's minimum eligible amount of Credit Cover.\nIn section 11.1a of the ECVAA SD, the minimum eligible amount is described as \"…the amount of Credit Cover for which the Credit Cover Percentage, as calculated for the current Settlement Period, would be no greater than 75%.\"\n","Section 11.1a of the ECVAA Service Description should be altered to match the exact wording in section M 2.3.2b of the Code as follows: “…the ECVAA shall calculate the Party’s minimum eligible amount of credit. This is the amount of Credit Cover for which the Credit Cover Percentage, as calculated for the current Settlement Period, would be no greater than 75% the lowest amount for which the Trading Party’s Credit Cover Percentage, if it were redetermined for each Settlement Period in the waiting period on the assumption that the Trading Party’s Credit Cover were equal to that amount, would be no greater than 75% in relation to any such Settlement Period.”","−",null,"ISG","Implemented"]
[712,"Making Transmission Company Reports Available","N/A","2001-10-15","The BSC states that the Settlement Reports (SAA-I014), including the sub-flow sent to the Transmission Company (S0142), and should be available to any Party on request through BSCP 41 flexible reporting requirements.  The Central Service Agent cannot send S0142 automatically to Parties due to the size of the sub-flow. The size of the file, on average 8MB, is such that sending it out automatically would compromise operation of the High Grade Service. The file could disrupt, slow down or inhibit receipt of other more critical reports - such as contract notification acknowledgements and rejections. To comply with the BSC, S0142 needs to be made available through other means","As an ‘interim solution’, ELEXON will send S0142 to requesting Parties via email. Parties wanting to receive S0142 should contact the ELEXON Helpdesk, who will pass the request on to the ELEXON Trading Operations Contact. Upon such receipt, ELEXON Trading Operations will ensure that the requesting Party is entitled to receive the report by ensuring that they are a relevant Party (i.e. acceded to the Code). If more information is required in order for ELEXON to provide the report via e-mail (for example, the e-mail address of the intended recipient of the report, or the format of the compression), then ELEXON will contact the Party for further information. Once this information has been established, ELEXON will provide a compressed version of the relevant reports as required. ","−",null,"ISG","Implemented"]
[711,"Generate an exception error if EAC/AA receives NULL Meter Advance in EAC/AA Request File","N/A","2001-10-08","When the EAC/AA software receives an EAC/AA Request File (PERQ_001), with an SRD record containing a \"Meter Advance\" of NULL, the load process aborts giving the appearance that the run has completed. Totals are produced, but only for the number of records processed up to the time of the abort. Although an \"Output File\" is referenced in the Run Report, no such file is actually produced.","The EAC/AA software should be modified to report an exception error if it detects a NULL Meter Advance in the SRD record for a EAC/AA Request File (PERQ_001). This new type of exception message should be written to the ‘Control Report’ and to the normal ‘EAC/AA Calculation Exception’ report. Processing should then resume such that the whole file is processed and an Output File produced.","SVG: 24",null,"SVG","Implemented ","Approve"]
[710,"Updating PCSec Keys & FTP Account Passwords","N/A","2001-10-01","The current procedure for changing PCSec keys and FTP account passwords was specified in ELEXON Circular No. EL00137, issued on 17 July 01. \nIt has been suggested that this procedure be formalised and included in the `Communication Requirements Document' which is a Code Subsidiary Document.","The procedure for changing PCSec keys and FTP account passwords should be included in the ‘Communication Requirements Document.’","−",null,"ISG","Implemented"]
[709,"Alignment of the use of Participation Capacity in BSCP65","ELEXON","2001-10-01","(This CP has been raised from NCR323 v2)\nThe use of terminology relating to Participation Capacity in BSCP65 4.1 is inconsistent with the Code A1.3.1.","BSCP65 Version 2 i) Form BSCP65/4.1, Party Registration Application / Change of Registration Details Form, to be updated to reflect the Participation Capacity terminology used in the Code, Section A paragraph 1.3.1. A sub-section under Trading Party to be incorporated to reflect Logica categories, CVA Metering System Registrant, Non-physical and Interconnector User. ii) Update the Route Map to show that DSO, TC and IA register as Parties with the CRA after Accession and that the IEA is classified as another Trading Party i.e. one not required to register BM Units and meters but a Party who is allocated Energy Accounts.","−",null,"ISG","−","Rejected"]
[708,"Inconsistency R014A in NDFC with Logica IDD","ELEXON","2001-09-27","The NETA Data File Catalogue is inconsistent with the information provided in the IDD.   Affected Section: Annex A Data File Specification.\nR014A  -- According to the data file catalogue this should be a group identifier RRH for registration report header, in the flow and the IDD the group header is RR2 not RRH.","Change the NETA Data File Catalogue as follows: Change the name of the first data group in flow R014A from RRH to RR2. The data items contained in it remain the same.","−",null,"ISG","Implemented"]
[707,"Inconsistency Between the BMRA and NGC Interface","ELEXON","2001-09-27","The BMRA Software displays incorrect Peak Settlement Period numbers on the Forecast 2-14 Day Ahead Screen. This screen displays the peak values for both the Demand and Margin for each Settlement Day and associated Settlement Period, 2 - 14 Days ahead. The NGC Interface provides the associated date and time in the format YYYY-MM-DD HH:MM but the criterion associated to this format is for the 'Day of Forecast' only. NGC do not provide the time of the peak Settlement Period to the BMRA which results in the value for HH:MM always being 00:00. \nThe BMRA interprets the data provided as Settlement Period 1 GMT or Settlement Period 3 BST for the Settlement Day. The implication of this is that the peaks for Demand and Margin always show as Settlement Period 1 or Settlement Period 3 rather than the correct peak Settlement Period in question.","Option 1 – Amend NGC Interface to include the time of the start of the 1/2 hourly period when the peaks actually occur for both the Demand and Margin. The BMRA would not require any changes as this is how the existing functionality currently translates the time received into an associated Settlement Period Option 2 – Amend the BMRA to remove the Settlement Period data from the Screen. No changes required to the NGC Interface. They will continue to send data to the BMRA in the current format and the BMRA Screen will be amended so this information is not displayed on the Screen.","ISG: 24",null,"ISG","−","Rejected"]
[706,"Provision of SVA HH Data by accredited sources","Powergen UK plc","2001-09-27","When situations occur where the HHDC is unable to collect Half Hourly consumption/export data from SVA Metering Systems but other sources are able to do so, BSCP502 requires a mechanism to allow this data to be used to improve the accuracy of settlements.","Amend BSCP502 to show an accredited HHMO collecting data and passing this on to the HHDC for validation and entry into Settlements.","−",null,"SVG","−","Rejected"]
[705,"Provision of SVA Meter Advance Register data by Suppliers","Powergen UK plc","2001-09-27","When situations occur where the HHDC is unable to collect Half Hourly consumption/export data from SVA Metering Systems, but other sources are able to provide Meter Advance Register information, BSCP502 requires a mechanism to allow this data to be used to improve the accuracy of settlements.","Amend BSCP502 to allow the provision of Meter Advance Register data to the HHDC by Suppliers, for validation and entry into Settlements.","−",null,"SVG","−","Rejected"]
[704,"Re-badging of the SVA Data Catalogue","ELEXON","2001-09-25","There are inconsistencies between the SVA Data Catalogue and the terms and acronyms used in the BSC and its subsidiary documents and between the format of the SVA Data Catalogue and current organisation of the Electricity Trading Arrangements.","The changes proposed are of two types: 1. Formatting changes to remove references to the Pool, Pool It Ltd., etc. and replace them with references to the BSC, ELEXON Ltd., etc.; 2. Consistency changes to replace examples of Pool terminology by their equivalent BSC terminology. Configurable items affected: SVA Data Catalogue Volume 1 Ref:005PAT SVA Data Catalogue Volume 2 Ref: 002AAT.","−",null,"SVG","Implemented "]
[703,"Inconsistencies in the Credit Default Process","ELEXON","2001-09-24","BSC Section M3 relates to the process followed when a Trading Party goes into Level 1 or Level 2 Credit Default. The process for notifying Parties has been carried out by ELEXON since NETA Go-live because the ECVAA were not obliged to do this within the ECVAA Service Description.  The Communications Requirements Document was updated to allow ELEXON to carry out this notification on behalf of the ECVAA.  Updates are also required to the ECVAA Service Description, Communications Requirements Document to include an obligation on the ECVAA relating to the issue of Credit Default notices and the posting of Credit Default statements on the BMRS.","The ECVAA Service Description, Communications Requirements Document, User Requirement Specifications and and associated Operation Service ManualsLines, will need to be amended to introduce an obligation on the ECVAA to issue credit default notices and post credit default statements on the BMRS. The ECVAA will need to be available on a 24-hour basis in order to meet these obligations, which means the ECVAA User Requirement Specification and Operations Manual will need updating. A change to the ECVAA System will also be required to send a report to the ECVAA Operator and/or Logica NETA Helpdesk when the Credit Cover Percentage becomes less than 75 or 90%. To resolve the inconsistency in the naming conventions, the ECVN Feedback (ECVAA-I009) and MVRN Feedback (ECVAA-I010) should be amended to give the following message: “Indebtedness exceeds Level 2 threshold for BSC Party 1/2” ECVAA documentation, including the ECVN and MVRN Feedback reports, should also be changed to use the term Credit Cover Percentage, instead of indebtedness.","−",null,"ISG","Implemented"]
[702,"Operability  Changes to Data Marshalling Software","Cap Gemini","2001-09-18","Changes to improve the operability of the Data Marshalling application: * Validation added to the Environments Maintenance screen to ensure that polled environments have a specified Bad Data Directory. * Correction to a defect in the order of precedence of the Outgoing Routing Instructions. * Amendment to the start-up and stop scripts to reset database flags after a crash to enable successful restart. * Enhancement to enable incoming files with invalid test flags to be handled without halting Data Marshalling. \n* Amendment for Data Marshalling to record the Run Type Code of the P0182 file, enabling the run that created it to be identified, and bringing it in line with other file types.","Update Data Marshalling software to implement changes outlined in the issue description. ","−",null,"SVG","Implemented "]
[701,"Missing SVA Metering System Details","N/A","2001-09-17","BSCP 505 section 3.3.2.5 requires the NHHDA to notify Suppliers, and the BSC Panel, of MSIDs which have been excluded from the Supplier Purchase Matrix because of missing SVA Metering Specific details, within 5 WD of aggregation for the Final Reconciliation Volume Allocation run.  Currently, this information is obtained by running a report against the Aggregation Exception log file for the Final Reconciliation run concerned. Unfortunately, a separate Aggregation Exception log file is produced for each database partition that supports the NHHDA application which means that NHHDA users have to trigger this report an equivalent number of times to obtain the complete report for the Final Reconciliation run. Some NHHDA systems may have up to 24 partitions.","1. Produce only a single Aggregation Exception log file (L0037001 file) for each Final Reconciliation run instead of the individual logs for each partition. This single log file can then be reported against; or 2. Continue to produce the individual Aggregation Exception log files, one for each partition, but at the same time output ‘A12’ exception messages into a new file (new file type) that the users can report against. Note: ‘A12’ exception messages are the source entries for the desired report; or 3. When the users request the report against an Aggregation Exception log file, give the users the choice of whether they wish to report just against the identified file (i.e. as at present) or for the entire Reconciliation Run’s Aggregation Exception log files. The modified reporting process would then identify the Reconciliation run from the identified file, and report against all the log files for the same reconciliation run; or 4. Any other solution which satisfies the required change objective.","−",null,"SVG","−","Rejected"]
[700,"Calculation of Negative EAC by the EAC/AA System","SEEBOARD","2001-09-13","The ELEXON-developed EAC/AA calculator allows a negative Estimate of Annual Consumption (EAC) to be calculated.  A negative Annualised Advance (AA) may arise as a result of an erroneously large previous AA value or as a result of failure to detect a meter-rollover. In the former case, the erroneously large AA and negative AA will cancel out, inasmuch as the overall metered volume over the two meter advance periods will be correct, albeit that the profiled demand values will be inaccurate. In the latter case, no such compensation will take place. In either case, the negative AA may (depending on the magnitude of the negative AA, the meter advance period and the value of the Previous Estimated Annual Consumption (PEAC)) result in a negative EAC.","Potential alternatives to calculating a negative EAC are:- a) to use the previous EAC value; b) to use a GSP Group Profile Class Average EAC value, as defined in Market Domain Data; c) to set the EAC to zero; d) not to calculate an EAC (i.e. set to null). These options are described in more detail in the attachment. The recommended / preferred solution is option (b), namely to use the GSP Group Profile Class Average EAC.","−",null,"SVG","−","Rejected"]
[699,"Inconsistencies in Provision of Monitoring Reports","N/A","2001-09-07","SVAA SSL300 and SSL310 outline the obligations on the SVAA relating to the processing of SVA and DPP.  Section 4 'Service Levels' requires that the SVAA provides the BSCCo with routine performance monitoring reports'.  The timescale by which this information should be provided is inconsistent. The SVAA are actually providing the routine performance monitoring data to BSCCo within 5WD of the end of the month. This is acceptable to ELEXON and therefore needs to be reflected in the two Service Lines.","There are two changes proposed to SSL300 and SSL310: 1. Modify clauses 4.1.2 and 4.1.3 respectively so that the timescale is changed to ‘5 Working Days (5 WDs)’. 2. Delete ‘performance monitoring’ in clauses 4.1.2 and 4.1.3 respectively and rename title of corresponding Appendix 2 from ‘Performance Monitoring Reports’ to ‘SVAA Monthly Service Report’.","−","CPC00210","SVG","Implemented "]
[698,"Enhancements to Instruction Processing Rules","ELEXON","2001-09-07","A set of instruction processing changes were implemented in the NHH Code Subsidiary Documents under the Pool governance via SIR R2700.  \nThis CP proposes to include equivalent requirements in the HH Code Subsidiary Documents.  Clarify what type of file (i.e. a revised or an exact copy) should be sent by the DC or SMRA to the DA.  Streamline the references to the handling of instruction processing within the impacted BSCPs.","Modify the HH and NHH Code Subsidiary Documents.","−",null,"SVG","Implemented "]
[697,"Removal of Inconsistency in BSCP75","ELEXON","2001-09-07","Section 4.1.1 of BSCP75 states that although the CDCA has prime responsibility for determining the Aggregation Rules for GSP Group Takes, he will fulfil this obligation by requesting PDSOs to submit Aggregation Rules for GSP Group Take for their Authorised Area and the PDSOs shall comply with any such request.\nForm BSCP75 / 4.2 is the form which Parties have to use to submit Aggregation Rules to the CDCA   However, there are no boxes to allow the identification of the GSP Group to which the Aggregation Rules apply.","In Section 1 of BSCP75 / 4.2 add two rows, one to identify GSP Group ID and the other to identify GSP Group name","−",null,"ISG","−","Rejected"]
[696,"Application of Default if no Consumption  Data Available","ELEXON","2001-09-07","Modify the Code Subsidiary documents so that the HHDA uses a default EAC, provided by the Market Domain Data Agent where no consumption is provided by the HHDC, in the aggregation process.","Modify the Code Subsidiary documents as follows: 1. BSCP503 ‘Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’ Modify Appendix 4.3 ‘Checks for data anomalies during Data Aggregation Run’ so that it applies the principles outlined in Section f of Appendix 4.2 ‘ Data Estimation’ of BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ whereby a default EAC rather than zero values are applied for the Metering Systems affected. 2. BSCP508 ‘ Supplier Volume Allocation Agent’ Add the HHDA as a recipient of the P0186 ‘Half Hourly Default EAC’ dataflow to process 3.7 ‘Implementation of MDD Changes’. 3. PSL150 ‘Half Hourly Data Aggregation’ Modify clause 5.1.14 so that it applies the principles outlined in clause 1.5.7.2 of PSL 130 ‘Half Hourly Data Collection’. 4. SVA Data Catalogue Add the HHDA as a recipient of the P0186 ‘Half Hourly Default EAC’ dataflow.","SVG: 22","CPC00210","SVG","Aug 03 Release","Approve"]
[695,"Additional Authorisations with BSCP38 for SVA Processes","ELEXON","2001-09-07","Modify BSCP38 so that it incorporates authorisations for the following two SVA processes: 1) Provision of the (NHH BMU data.  A Supplier will use this process if they choose to allocate NHH consumption to an Additional BMU(s); and 2) Provision of SVA LLF data.  The PDSO will use this process when they create LLFs and require the LLF to be approved.","1. BSCP38 Modify BSCP38 to include authorisation of the two SVA processes described above. This will require changes to: a) Section 1: This will need to cross-refer to BSCP507 and BSCP528. b) Section 4: Add one new row (relating to the BSCP507 authorisation) and modify row P (relating to the BSCP528 authorisation). c) Appendices: These will need to be modified to allow for authorisations relating to the two SVA processes. There will be also be an impact on: 1) BSCP507: A change will be required to Section 1 to require the Supplier to complete BSCP38 prior to providing the NHH BM Unit data to the SVAA for processing. 2) BSCP528: A change will be required to Section 1 to require the PDSO to complete BSCP38 prior to submitting LLFs for approval to the BSC Panel.","−",null,null,"Implemented "]
[694,"Inconsistency relating to Transferred Data","N/A","2001-09-07","Modify SL130 so that it is self consistent and is also consistent with BSCP502 in relation to how much data is transferred.  The HHDC should transfer up to 3 months of the most recent metering data in accordance with clause 1.3.2.3 and also in accordance with step 3.2.4.7 of BSCP502.","There are three clauses in PSL130 which are impacted - 1.3.2.2, 1.3.2.3 and 5.1.9. However to minimise the potential for further inconsistencies to be introduced, it is proposed that only one clause exists in Section 1 which refers to the time period, with clause 5.1.9 cross-referencing this Section 1 clause. 1. Clause 1.3.2.2 Modify the last sentence of this clause so that is specifically relates to a Supplier ceasing to be responsible for the Metering System coincidentally with the HHDC. In this circumstance the requirement will be for the HHDC to immediately transfer data and other information to the Panel. 2. Clause 1.3.2.3 This clause needs modifying in two ways: a) It should specifically exclude a Supplier ceasing to be responsible for the Metering System coincidentally with the HHDC, as this is covered in clause 1.3.2.2. b) It should refer to BSCP502 for the period of data to be transferred. 3. Clause 5.1.9 Modify the clause so that the transfer of data will occur in accordance with clause 1.3.2.2 and 1.3.2.3.","−","CPC00210","SVG","Implemented "]
[693,"Allow (HHDA) to apply default where no data provided by HHDC.","ELEXON","2001-09-06","Modify a number of Code Subsidiary documents (BSCP503, BSCP508, PSL150 and the SVA Data Catalogue) so that the HHDA uses a default EAC, provided by the Market Domain Data Agent where no consumption is provided by the HHDC, in the aggregation process.","Modify the Code Subsidiary documents as follows: 1. BSCP503 ‘Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’ Modify Appendix 4.3 ‘Checks for data anomalies during Data Aggregation Run’ so that it applies the principles outlined in Section f of Appendix 4.2 ‘ Data Estimation’ of BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’ whereby a default EAC rather than zero values are applied for the Metering Systems affected. 2. BSCP508 ‘ Supplier Volume Allocation Agent’ Add the HHDA as a recipient of the P0186 ‘Half Hourly Default EAC’ dataflow to process 3.7 ‘Implementation of MDD Changes’. 3. PSL150 ‘Half Hourly Data Aggregation’ Modify clause 5.1.14 so that it applies the principles outlined in clause 1.5.7.2 of PSL 130 ‘Half Hourly Data Collection’. 4. SVA Data Catalogue Add the HHDA as a recipient of the P0186 ‘Half Hourly Default EAC’ dataflow.","−",null,"SVG","−","Rejected"]
[692,"Increase Array Size within Logging Application","N/A","2001-09-04","Raised from Emergency Fix CP689. Software maintenance to increase array size within code with no change to business functionality.","See the description of the issue. ","−",null,"SVG","−","Rejected"]
[691,"Revised Proving & Validation Rules","ELEXON","2001-09-03","A meeting was held on 14th June 2001 between ELEXON and the Association of Meter\nOperators. The purpose of the meeting was to review the proposals presented to the\nHHTAG to ensure that they still reflected good working practice and to formulate a Change\nProposal (CP) to incorporate the proving requirements within the relevant Code Subsidiary\nDocuments. ","Modify the HH CSDs to incorporate a revised set of proving and validation rules.","−",null,null,"Implemented "]
[690,"Clarifications/Improvements to Unmetered Supplies","N/A","2001-09-03","BSCP520 defines the processes associated with Unmetered Supplies registered in the Supplier Meter Registration Systems.  SL170 documents the Meter Administration responsibilities relating to Unmetered Supplies. There are a number of areas where the BSCP and the SL are unclear or incorrect and where process descriptions can be improved. "," This CP proposes to address these areas by adding clarifications, streamlining duplicated areas and removing errors.","−",null,"SVG","Implemented "]
[689,"Increase Array Size within Logging Application","Cap Gemini","2001-08-30","Software maintenance to increase array size within code with no change to business functionality. Version number: 1.33. Reason for change: Code has exceeded array size. Proposed implementation date: 03 September 01 (next PARMS run date).\nThis change will have no impact on other Agents or Parties.","See the description of the issue. ","−",null,"SVG","Implemented "]
[688,"Changes to SAA URS","N/A","2001-08-24","Changes to SAA URS for the ECVAA Interim Release and P10 Project.","See the description of the issue. ","−",null,"ISG","Implemented"]
[687,"Changes to BMRA for ECVAA Interim Release","N/A","2001-08-24","Changes to DCR BMRA for the ECVAA Interim Release and P10 Sub Project.","See the description of the issue. ","−",null,"ISG","Implemented"]
[686,"Changes to NDFC for ECVAA Interim Release","N/A","2001-08-24","Changes to NDFC documents for the ECVAA interim Release P10 Sub Project.","See the description of the issue. ","−",null,"ISG","Implemented"]
[685,"Changes to SAA Service Description for ECVAA Interim Release","N/A","2001-08-24","Changes to SAA service description for the ECVAA interim Release and P10 Sub Project","See the description of the issue. ","−",null,"ISG","Implemented"]
[684,"Changes to Categories of Market Organisations","ELEXON","2001-08-24","The current version of BSCP42 outlines four different Categories of Market Organisation.   These appear to be defined by the criticality of each type of Market Organisation in relation to the Settlement System.  For example, Category 1 includes CVA Systems, while 2, 3 and 4 include such Organisations as BSC Parties and Party Agents.","1) To re-categorise Market Organisations into 2 classes, merging Categories 2, 3 and 4. 2) To reallocate those Market Organisations currently in the wrong Categories 3) Update BSCP42 removing references to Categories 3 and 4.","−",null,"ISG","−","Rejected"]
[683,"Provision of EACs to PDSO","Western Power Distribution","2001-08-23","Following separation of Supply and Distribution businesses, the PDSO no longer has access to EACs. The PDSO requires an accurate forecast of consumption to enable it to calculate planned load on its network and EACs previously provided this.   This change adds an obligation on Non Half-Hourly Data Collectors, when sending EACs to the Supplier and Non Half-Hourly Data Aggregator, to also send them to the relevant PDSO. The alternative would be for the PDSO to develop systems to process meter readings and calculate the EAC itself. This would be wasteful given that data in the required form already exists elsewhere.  This change will assist the PDSO in the efficient operation of the distribution system.  The receipt of EACs will be of benefit when planning at feeder and substation level and will assist in ensuring security of supply.","Requires changes to BSCP504 page 42 section 2.3.11, and page 91 section 3.3.11.5. Add PDSO as a recipient of the AA/EAC sent by the NHHDC. Requires changes to PSL120 page 17 section 1.5.7.9 and page 19 section 1.5.8.4. Add PDSO as a recipient for calculated and withdrawn AA/EACs.","−",null,"SVG","−","Rejected"]
[682,"Upgrade to the ISRA/SVAA software to Oracle 9i","N/A","2001-08-23","The ISRA software currently uses Oracle 7.3.4. Support for Oracle 7.3.4 expired on 31 December 2000. The ISR/SVA Agent has taken out an extended support contract for 01 and will obtain a further extension into 2002 in order to retain support for their current system. However the ISRA/SVAA software must be upgraded to run on Oracle 9, as support for Oracle 7 cannot be renewed indefinitely. The ISRA/SVAA software will be running on an unsupported Oracle platform at some point in the future if this change is not progressed.","Amend the ISRA/SVAA software to run on Oracle 8.1.7.1.","−",null,"SVG","Implemented "]
[681,"New Measure for NHH BMU Allocation Process","ELEXON","2001-08-23","The NHH BMU allocation process has been introduced into a number of Code Subsidiary Documents but no performance standard has been included for this particular process.","As a result of discussions between the SVAA and ELEXON, a new measure was drafted and presented for approval to Trading Stage 2 (TS2). TS2 (TS2/34/881, Attachment 2 to this CP) approved the introduction of the new measure into SVAA SSL300 “Supplier Volume Allocation” as well as a change to the SVAA Contract to cover the NHH BMU allocation process on 13th March 2001 (Appendix 1 on p3 shows the required change)","−","CPC00210","SVG","Implemented "]
[680,"Enhancements to Standing Data Change Form","N/A","2001-08-21","A number of changes are required to the 'Supplier Volume Allocation Supplier / Supplier Agent Standing Data Change Form' contained in Appendix 4.2 of BSCP507.\nThis CP replaces SIR R2894, which was raised under the Pool governance.  It attempts to make the form more operationally workable whereas SIR R2894 addressed one requirement only i.e. The addition of GSP Group Identifier after each of the data flows referenced in Part A of the form.","Modify the form in Appendix 4.2 of BSCP507 as follows: a) Rename form identifier to ‘F507/01’. b) Modify ‘Indicate as appropriate’ to ‘Indicate change(s) proposed for GSP Group’ in Part A of form. c) Remove all occurrences of ‘Effective Date of Change at GSP Group’ from Part A of form. d) Add the text ‘Provide the data items specified in the SVA Data Catalogue’ to Part A of form. e) Add the text ‘Changes attached – Yes / No’ to Part A of form.","−","CPC00210","SVG","Implemented "]
[679,"Removal of Inconsistency from BSCP07","N/A","2001-08-20","BSCP07 Section 2.2 defines \"Effective Date\" as 'The date and time from which the request for a SDC will become effective'. In addition, the Standing Data Change Form (Section 4.2) asks for the Effective Date and Time of the proposed change. By default, all standing data changes take effect from midnight (local time) on the date nominated as the Effective Date.  Therefore a change is required to the definition","Change the definition of Effective Date in Section 2.2. of BSCP07 to \" The date from which the request for a SDC will become effective\". Remove the reference to time in the Standing Data Change Form in Section 4.2 of BSCP07","−",null,"SVG","Implemented "]
[678,"Inconsistency between BSC & the Reporting Catalogue","ELEXON","2001-08-20","There is an inconsistency between BSC Section V and the Reporting Catalogue. The inconsistency has arisen because a change made to Section V has not been reflected in the Reporting Catalogue. Since Go-live, the Transmission Company have confirmed that they are unable to forecast certain data sets as far into the future as they initially thought possible. These data sets are issued in the BMRS, and the relevant changes have already been made to Section V. However, the Reporting catalogue does not reflect these changes.","The following changes should be made to Section 2: Reports from the BMRA of the Reporting Catalogue (Version 2.0): 1. In section 2.1(c) change “D-1, D to D+5” to “D-1, D and D+1” 2. In section 2.1(d) change “D-1, D to D+5” to “D-1, D and D+1” 3. In section 2.1(e) change “D-1 to D+5” to “D-1, D and D+1” 4. In section 2.1(h) change “D-1 to D+5” to “D-1, D and D+1” 5. In section 2.1(i) change “D-1 to D+5” to “D-1, D and D+1”","−",null,"ISG","Implemented"]
[677,"Capitalizing of term \"meter period value\" in SL130","ELEXON","2001-08-14","The term \"meter period value\" is used throughout and needs initial capitalizing otherwise it's meaningless.  This term is defined in the DTC.","The term \"meter period value\" is used throughout and needs initial capitalizing otherwise it's meaningless. This term is defined in the DTC.","−",null,"SVG","−","Rejected"]
[676,"Changes to  CoP 3 for HHTAG Recommendations","ELEXON","2001-08-14","Incorporate agreed guidance in the next issue of the Metering Code of Practice 3 when the opportunity arises.","Incorporate agreed guidance in the next issue of the Metering Code of Practice 3 when the opportunity arises.","−",null,null,"−","Rejected"]
[675,"Errors in install.log upon installation.","N/A","2001-08-14","Errors in install.log upon installation.\nOR3137","See the description of the issue. ","−"]
[674,"Amend NHHDA Logical Design for CP628","N/A","2001-08-14","At present all Data Aggregator Appointments (DAAs) supersede instructions for the same metering system that have failed prior to the DAA's significant date. However with the special case DAA no metering system information is included and therefore the instruction should not supersede any instructions.","See the description of the issue. ","−"]
[673,"Amend NHHDA Physical Design for CP628","N/A","2001-08-14","At present all Data Aggregator Appointments (DAAs) supersede instructions for the same metering system that have failed prior to the DAA's significant date.  However with the special case DAA no metering system information is included and therefore the instruction should not supersede any instructions.","See the description of the issue. ","−"]
[672,"Changes to CoP 4 for HHTAG Recommendations.","N/A","2001-08-13","Raised from R2735 in Pool System.\nIncorporate agreed guidance in the next issue of the Metering Code of Practice 4 when the opportunity arises.","See the description of the issue. ","−",null,null,"−","Rejected"]
[671,"Changes to  CoP 5 for HHTAG Recommendations","N/A","2001-08-13","Incorporate agreed guidance in the next issue of the Metering Code of Practice 5 when the opportunity arises.\n","See the description of the issue. ","−",null,null,"−","Rejected"]
[670,"Changes to  CoP 6 for HHTAG Recommendations","ELEXON","2001-08-13","Incorporate agreed guidance in the next issue of the Metering Code of Practice 6 when the opportunity arises.","See the description of the issue. ","−",null,null,"−","Rejected"]
[669,"HHTAG Recommendations for CoP 7 Version 1","ELEXON","2001-08-13","Raised from R2738 in Pool System\nIncorporate agreed guidance in the next issue of the Metering Code of Practices when the opportunity arises.","See the description of the issue. ","SVG: 31","CPC00332","SVG","Feb 04 Release","Approve"]
[668,"When box needs clarifying","ELEXON","2001-08-13","Raised from R2508 in Pool system.\n\"When\" box needs clarifying to explicitly allow for de-appointments at GSP Group in BSCP507.","See the description of the issue. ","−","CPC00210","SVG","Implemented "]
[667,"Change to section 3.7.7 (item c) of BSCP508","ELEXON","2001-08-13","Cap Gemini have pointed out that the D0227 flow referenced in section 3.7.7 (item c) of AP508 does not go to ISRA from MDD anymore, rather the D0269 flow is used (which is referenced in this section (item a)).","Remove the reference to D0227 from item c. ","−","CPC00210","SVG","Implemented "]
[666,"Amendments to AP508","ELEXON","2001-08-13","Raised from R2805 in pool system to remove an obligation on ISRA to re-send MDD if no acknowledgement received for those MDD dataflows which are manual.","See the description of the issue. ","−",null,"SVG","−","Rejected"]
[665,"Removal of Obligation for MDD Manual Data flows","ELEXON","2001-08-13","Raised from R2806 in Pool Database to remove an obligation on ISRA to re-send MDD if no acknowledgement received for those MDD data flows which are manual.","See the description of the issue. ","−","CPC00210","SVG","Implemented "]
[664,"Addition of field \"GSP Group ID\" in form \"AP507/01","ELEXON","2001-08-10","See the solution description. ","CP664 proposes to add the field \"GSP Group Id\" to form BSCP 507/0.","−",null,"SVG","−","Rejected"]
[663,"NHHDA Archiving Software Defect  OR 3139","ELEXON","2001-07-26","A Severity Two defect has been identified within the Instruction Processing Function of NHHDA Release 7.1.0 and NHHDA Release 7.2.0. This defect incorrectly allows certain instructions which should have failed, to be applied and impact settlement, dependent on the Archive Date.\nOnce these instructions are applied there is no method of rolling back the database for that metering system.  Should instructions be incorrectly applied then the only fix is to request an individual refresh (NH01, NH09) from the appropriate source for the metering systems affected.","It is proposed that a patch is issued to Non Half Hourly Data Aggregators to correct this defect","−",null,"SVG","Implemented "]
[662,"Revise timescales for Annual/Ad-hoc LLF Loads","ELEXON","2001-07-24","Step 3.2.9 “Update, Annually or as Required, of SVA LLFs for an Existing LLFC Id\" within BSCP528 requires the SVAA to load the LLFs within 5 Working Days of receiving the schedule from the PDSO.\nThe timescale specified in BSCP528 is too tight for both the annual and the ad-hoc update of LLFs.  This activity normally takes around 10 Working Days to complete.","The proposal is therefore to amend the timescale as follows: “Within a timescale agreed between SVAA and BSCCo, taking into account the updates required to MDD.”","−",null,"SVG","Implemented "]
[661,"BSCP65 - MDD Updates:  Supplier Stops Trading","N/A","2001-07-24","As a result of the \"Supplier Stops Trading\" walkthrough on 23 February 01, it was agreed that a new step 3.2.7 should be incorporated into BSCP65, to ensure that when a Party changes their participation capacity from that of a Supplier they should be required to update Market Domain Data, via BSCP509.","See the description of the issue. ","−",null,null,"Implemented "]
[660,"Amendment to SSL330 Relating to Response Times","N/A","2001-07-24","Table 2 \"Call Progress Response Times\" of SVAA SSL330 requires the SVAA to respond to incidents within given timescales. Part a of Contract Change Notice 079a  provides a derogation for the SVAA against the timescales specified in the \"Follow-up Calls to Caller\" column within Table 2.  The derogation requires that the SVAA agrees the follow-up time with the caller.\n","It is proposed that the SSL is modified to reflect the derogation and that the derogation is consequently withdrawn. Replace the text in the “Follow-up Calls to Caller” column of Table 2 with the following “Within timescale agreed with caller”. The change should be incorporated at an opportune time within the SSL. Withdraw the derogation once the change has been implemented in the SSL.","−",null,"SVG","Implemented "]
[659,"Issues with ISRA Archiving","ELEXON","2001-07-20","The ISRA Archive and Restore (IAR) facility is designed to remove redundant files and database records from the Live ISR system. It is essentially a deletion tool, and removes data relating to a Settlement Date which is at least two years old and has had a Final Reconciliation run successfully performed. To date, however, the facility has not been used to remove data from the Live system.","To be specified.","−",null,"SVG","Implemented "]
[658,"Amendments to the Acceptance Test Pack for ISRA/SVAA Archiving Project","N/A",null,"Amend the Acceptance Test Pack for the ISRA/SVAA Archiving Project. To be specified. SVG has approved the development and implementation of the ISRA/SVAA Archiving Project. This change will ensure consistency between the ISRA/SVAA s/w and the Acceptance Test Pack.","See the description of the issue. ",null,null,"SVG",null,"Closed"]
[657,"Amendments to ISRA/SVAA System Management Guide","N/A","2001-07-20","Amend the ISRA/SVAA System Management Guide for the ISRA/SVAA Archiving Project.","These changes will be made by Logica - exact details unknown.","−",null,"SVG","−","Rejected"]
[656,"Amendments to ISRA/SVAA Operations Guide","N/A","2001-07-20","Amend the ISRA/SVAA System Management Guide for the ISRA/SVAA Archiving Project.","These changes will be made by Logica - exact details unknown.","−",null,"SVG","−","Rejected"]
[655,"Amendments to ISRA/SVAA Physical Design","N/A","2001-07-20","Amend the ISRA/SVAA Physical Design for the ISRA/SVAA Archiving Project.","These changes will be made by Logica - exact details unknown.","−",null,"SVG","−","Rejected"]
[654,"Amendments to ISRA/SVAA Logical Design","N/A","2001-07-20","Amend the ISRA/SVAA Physical Design for the ISRA/SVAA Archiving Project.","These changes will be made by Logica - exact details unknown.","−",null,"SVG","−","Rejected"]
[653,"Amendments to SSL320 for ISRA/SVAA Archiving Project","N/A","2001-07-20","Amend Sections 1.3.12 and 1.3.13 of SSL320 to describe the new Archiving functionality\nintroduced by the ISRA/SVAA Archiving Project.","Sections 1.3.12 and 1.3.13 of SSL320 deal with the implementation of the archiving s/w by the ISR/SVA Agent. It is proposed that the changes incorporated do not specify the detail of when data should be archived, rather that the client or its nominated agent sets the rules and notifies Cap. This is an approach already used in other documentation.","−",null,"SVG","−","Rejected"]
[652,"Amendments to ISRA/SVAA URS","N/A","2001-07-20","Amend Sections 4.5.16 and 9.1.1 of the ISRA/SVAA URS to describe the new Archiving functionality introduced by the ISRA/SVAA Archiving Project.","Sections 4.5.16 and 9.1.1 of the ISRA/SVAA URS deal with the implementation of the archiving s/w by the SVAA Agent and contain details of when data can be deleted. If it agreed by the Project Board, a further section may be included that is specifically dedicated to the process of archiving.","−",null,"SVG","−","Rejected"]
[651,"Amendments to ISRA/SVAA software","N/A","2001-07-20","Amend the ISRA/SVAA software for the ISRA/SVAA Archiving Project","The Archive and Restore software The changes to the software will address the following issues 1. The deletion of Unix files is not recorded. 2. The deletion of database records is recorded, but only for those tables that are audited. 3. Database entries for files recorded with a status of deleted are not removed. 4. Exception Reports from failed file loads are not cleared down by the archive. 5. A number of database tables are not updated during an archive. 6. A number of input data files, which do not relate to particular Settlement Dates, are not deleted by Archive and Restore. These include Line Loss Factors, Regression Equations, Profile Data, Pool Market Domain Data and Sunset Data. 7. Currently the deletion of files used for defaulting is handled incorrectly 8. The specification of the archive period is currently a fixed parameter within the software.","−",null,"SVG","−","Closed"]
[650,"Changes to the Acceptance Test Pack for NHHDA V7.2.0","N/A","2001-07-09","Changes required to the Acceptance Test Pack as part of the changes to upgrade NHHDA to V7.2.0","See the description of the issue. ","−",null,"SVG","−","Closed"]
[649,"Changes to NHHDA Instruction Processing Specification","N/A","2001-07-09","Changes required to the NHHDA Instruction Processing Specification as part of the changes to upgrade NHHDA to V7.2.0","See the description of the issue. ","−",null,"SVG","Implemented "]
[648,"OR3106 - The Special Case DAA is not Validating Correctly","N/A","2001-07-09","(OR 3106)\nThe special case DAA is not validating correctly","See the description of the issue. ","−",null,"SVG","Implemented "]
[647,"Removing/Mitigating Effect of Sys Balancing Actions (MP18)","ELEXON","2001-07-04","As part of the assessment of Urgent Modification MP18 it is necessary to obtain an assessment for implementing a number of the possible enduring solutions, and also associated interim solutions,\nfor MP18 which would be needed during the interim period.  ","This CP contains a number of independent, but related changes. Initially there are two possible interim system architectures, that have been included as the anticipated timescales of an enduring solution are expected to be significant: • Interim System Architecture 2 • Interim System Architecture 1a Next there are the two potential architectures for the enduring solution: • Enduring System Architecture 2 • Enduring System Architecture 3 Lastly there are two options which are to be considered in association with the enduring solutions: • BMRA Changes • Enduring System Architecture 2 (Alternative CID Options)\n(This CP will be superseded on completion of the HLIA by Logica when it will be possible to clarify the exact requirements.)","−",null,"ISG","−","Rejected"]
[646,"Accreditation of ECVNA and MVRNA Registrations","N/A","2001-06-26","The CRA system functionality for registration of the ECVNA and MVRNA, mandates setting the Accreditation and Certification Status on registration of these Party Agents.  However, under the provisions of the BSC, neither the ECVNA nor the MVRNA are required to be Accredited or Certified and therefore this information is not provided to CRA on such registration. \nThis Change Proposal replaces (NCR 357.","Amend the Central Registration Agent functionality so that only that information relevant to the registration of ECVNAs and MVRNAs is mandated, i.e. remove the mandatory requirement for the Accreditation Status and Certification Status to be set on registration of an ECVNA and / or MVRNA.","−",null,"ISG","−","Closed"]
[645,"Incorrect Default Rules for missing DA Data","N/A","2001-06-22","When SIR R2717 was implemented and the defaulting rules for missing Data Aggregator files for Initial Settlement were amended in SL300) incorrect text was included in section 1.7.6.1 for defaulting arrangements. These defaulting rules are valid for NHHDAs only.  Defaulting rules for HHDAs are different and should be:\n \"Missing Half Hour Data Aggregator data - for Weekday, Saturday and Sunday Day Types substitute data from the previous Settlement Day of the same Day Type and for all other Day Types substitute data from the previous Sunday Day Type Settlement Day, with sufficient number of Settlement Periods in respect of each Supplier / Data Aggregator combinations.\"","Remove reference to Half Hour Data Aggregator in section 1.7.6.1 of SSL300. Insert a new section before section 1.7.6.2, containing the following text: \"Missing Half Hour Data Aggregator data - for Weekday, Saturday and Sunday Day Types substitute data from the previous Settlement Day of the same Day Type and for all other Day Types substitute data from the previous Sunday Day Type Settlement Day, with sufficient number of Settlement Periods in respect of each Supplier / Data Aggregator combinations;\" Renumber the subsequent sub-sections of 1.7.6.","−","CPC00210","SVG","Implemented "]
[644,"Extension To Selection Criteria for MP18","ELEXON","2001-06-21","Urgent Modification Proposal P18 is currently being assessed. The Panel recognise the importance of this change and have requested that the next report (Mid-July) should include detailed information and costing of a workaround that could be put into place a short period after a positive determination on P18.","As part of the work on P10, a new view is being created to query the Bid-Offer volumes (i.e. QAOn ij) and the Acceptance volumes (i.e. QAOkn ij) to determine which volumes are DeMinimis and should be excluded from the calculation of SSP/SBP. We have been informed by Logica that it would be a simple technical change to also consult the raw acceptance data (using the acceptance number in the key) to include the deemed acceptance flag as part of the selection criteria. Currently this flag is always set to false and this would mean include the acceptance. Setting it to true would mean ignore this acceptance and its associated volume when calculating SSP/SBP. It is not proposed this change would affect the cashout prices for each Bid or Offer.","−",null,"ISG","−","Closed"]
[643,"Modification P10 - Removing De Minimis Acceptances","ELEXON","2001-06-20","Modification P10 - Removing De Minimis Acceptances from the Calculation of SBP/SSP\nAmend the Imbalance Price (SBP/SSP) Calculations to exclude all Bid/Offer Acceptances with a volume less than a De-Minimis Acceptance Threshold (DMAT). The threshold to be set by the Panel, initially at 1 MWh.","1. Implement a new operator-maintained parameter (DMAT) in SAA and BMRA, configurable for a Settlement Day. A parameter value of zero will indicate that the threshold is not to be applied for a Settlement Day. 2. For SSP and SBP calculations in BMRA and SAA, exclude all Bid/Offer Acceptances with an absolute Acceptance Volume less than or equal to the value of DMAT. 3. Make no changes to Balancing Payments for BM Units where Acceptances were below DMAT. 4. Display the value of DMAT on the ELEXON web site.","−",null,"ISG","Implemented"]
[642,"Enduring Process to Replace W016","N/A","2001-06-19","CRA-I020 is sent from the CRA to ELEXON and the SO but its IDD description has been interpreted differently by the two participants.  ELEXON are unable to use the interface in its current format. To address this, Workaround 16 was developed in which a spreadsheet is e-mailed on a weekly basis from the Logica Consortium to ELEXON. This contains all currently valid BMUs and the information relating to each BMU and its associated attributes. It is intended that the enduring solution to this workaround is for the data held in this spreadsheet be sent to ELEXON in the form of a data flow. This would be loaded into ELEXON databases to enable registration data validation and reporting.","The data sent as part of W016 will continue to be sent to ELEXON whenever attributes associated with a BM Unit are changed.","ISG: 37","−","ISG","2004-11-03"]
[641,"Enduring Process to replace WA021","N/A","2001-06-19","CRA-I020 (R0201) is sent from the CRA to ELEXON and the SO but its IDD description has been interpreted differently by the two participants.  ELEXON require substantially different information and formatting to that carried by CRA-I020.\nCRA-I020 should provide details of changes to the association of BMUs to Trading Units, by specifying the 'Trading Unit Name' for each BMU in group 'BR3'.  However, the 'Trading Unit Name' is the Trading Unit that the 'BM Unit' was associated with as at the 'effective from date' of the BMU (and associated parameters), the penultimate item in the group.  The 'Trading Unit Name' could therefore be null if the BMU was established before it was associated with a Trading Unit.  This means that even if the BMU association has changed, it would not be reported in this flow, unless a BMU parameter, such as GC or DC, has also changed.","1. Send the existing CRA-I020 to the SO only (and not to ELEXON.) a. Add a note to the description of the CRA-I020 to clarify the usage of the BM Unit ‘Effective From Dates’ and ‘Effective To Dates’ within the flow. Specifically: Version 3.6 of the “Interface Definition and Design – Part2” requires the following changes: Section 4.5, page 3, add the following paragraph after “The first field of each record … c) not changed”: “The ‘Effective from Date’ and ‘Effective To Date’ in the BM Unit Registration Group (BR3) are defined as the dates between which the BM Unit and all associated parameters within the group are valid. For example, if a CRA-I029 is received stating that a new Transmission Loss Factor (TLF) for a BM Unit will be effective from 1-Aug-2001, the BM Unit Registration Group will include the original record for that BM Unit but with the BM Unit ‘Effective To Date’ set to ‘31-Jul-2001’, as well as a new record with the changed TLF parameter and an ‘Effective From Date’ of ‘1-Aug- 2001’. Records which have an ‘Effective To Date’ which is in the past are not included in the flow.” b. This flow should also contain the Trading Unit Name to which a BM Unit is currently assigned and should be sent to the SO if and when this association changes, providing details of the new Trading Unit to which the BM Unit is assigned. It should be ensured that the Trading Unit to which a BM Unit is associated should always be on this flow. A full refresh report should also be available upon request.","−",null,"ISG","−","Closed"]
[640,"Change to CDCA URS","N/A","2001-06-19","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON.\nBSCP03 v2.0 3.1.4 currently states that the CDCA shall send the raw Meter Data Report to the Registrant, DSO or TC and Non Owner Party. The CDCA URS currently has no requirement for the CDCA to send the report to these parties.","Inconsistency PWC 37 Amend the CDCA URS to include the issuing of the Meter Data Report to the Registrant, DSO or TC and Non Owner Party.","−",null,"ISG","−","Closed"]
[639,"Handling of Missing or Invalid Data (SAA)","N/A","2001-06-19","The SAA system functionality and the SAA specification documentation do not accord with the requirements of BSCP 01 and the BS C (v1.1 Section T) with respect to the handling of missing or invalid data. \nCurrently a workaround (W022) is in place for the identification and handling of such invalid / missing data. This change proposes to replace the workaround (W022) with an enduring solution. It also addresses NETA CR397 and NETA Issues 143,155 and 156.","Where data is identified as missing or invalid prior to a Settlement Run, then: • SAA will ensure that there is a check prior to each run of the system to determine whether any inbound data is missing or invalid. The attachment to this change proposal details the checks required for each of the inbound data flows to SAA, and indicates what the procedure is that should be followed in the event of missing / invalid data. • If data is missing or invalid, and SAA are unable to obtain correct data prior to the scheduled run time in accordance with the requirements of the BSC and associated BSCPs, then the ELEXON Helpdesk should be informed (indicating that the call relates to missing SAA data, and that the priority is high). SAA will act in accordance with the BSC under instruction from BSCCo. In addition BSCP 01 ‘Overview of Trading Arrangements’ requires amendment. Currently the BSCP references ‘significant’ and ‘insignificant’ when referencing missing or invalid data, however, the process to be followed by SAA, under the provisions of BSC Section T 1.4, is the same regardless of the significance of the missing or invalid data.","−",null,"ISG","Implemented"]
[638,"HH Estimation Using Physical Meter Readings","ELEXON","2001-06-19","Where a site that cannot be dialled has no previous HH history, BSCP502 requires the use of EAC/Profile Class to estimate the HH data to be used in Settlements. There is no option listed that allows the use of actual meter advances with PC Profile even though this is closer to reality than use of the EAC. If the default EAC is used this could be many times higher (or lower) than the actual consumption. \nAlthough the BSCP does not list this combination where there is no previous data, it does allow the use of actual meter advances in conjunction with previous data (presumably even estimated/profile data). It therefore follows that once use has been made of the EAC and Profile data for at least one week, the way is then clear to commence using actual advance information in conjunction with the week's profile in accordance with BSCP502 4.2.1 (c) 3.","SSI's proposal is to add the following rule to BSCP502 4.2.1: Where no check meter or previous HH data exists for a non-dialling site, use profile data in conjunction with actual meter advances where available and with the EAC (or default EAC) where not available","−",null,"ISG","−","Closed"]
[637,"Meter Serial Number Field Length (CDCA)","ELEXON","2001-06-14","The field length of Meter Serial Numbers (for HH and NHH meters) permitted by NETA was originally set at 10 characters long, but the increase in the number of new meter owners has required an extension of up to 12 characters.  As a result, the CDCA's systems, which were designed in accordance with the NETA requirements, cannot accept some of the newer serial numbers that use more than 10 characters.  This causes problems for the CDCA when collecting and registering meter technical details and needs to be resolved.\nThis change proposal addresses Workaround 013 and NETA Issue 106.","One solution would be to alter the CDCA systems to accept longer meter serial numbers. However, a change such as this would have massive implications and is not considered cost-effective, since there are only a few of these meters in existence (which have already been registered) and it is not expected that many new serial numbers with excess lengths will arise in the future. Instead, the system that was set up for Workaround 013 should be used by the CDCA as an enduring solution to this problem. The CDCA’s procedures should be amended so that, in the event that a Meter Serial Number (MSN) is found to exceed 10 characters, the CDCA shall inform BSCCo immediately. With the agreement of the impacted Party, BSCCo will then instruct the CDCA to reduce the MSN down to 10 characters by removing any non-significant characters from the MSN as appropriate.","−",null,"ISG","Implemented"]
[636,"Inconsistencies in  BSCP28","N/A","2001-06-13","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON (IRP CP016)\nInconsistency 4 (Log Ref: CDCA_4) and 5 (Log Ref: CDCA_5) - IDD2 v3.6 CDCA-I022 actually has 'Electronic DataFile Transfer' as the mechanism. BSCP28 v2.0 3.1.8 states that media is Fax and/or Electronic.","Inconsistency 4 (Log Ref: CDCA_4) and 5 (Log Ref: CDCA_5) Change the medium in BSCP28 section 3.1.8 to ‘Electronic Data File Transfer’","−",null,"SVG","−","Rejected"]
[635,"Inconsistencies between the BSC & CRA URS","ELEXON","2001-06-13","There are several procedures described in the BSCPs which do not currently have a match in the CRA URS v.2.4: a) 19 & 20 (Log Ref. CRA_09 & 10): BSCP15 v.2 section 3.5: De-registration of specific BM Units. b) 56 (Log Ref. CRA-I031): BSCP20 v. 3 formF20/4.7: De-registration of Metering Systems. c) PWC2: BSCP31 v.2 section 3.2.4: De-registration of a Trading Party. d) 57 (Log Ref. CRA-I003): BSCP20 v.3 form F20/4.8 is used to register a new MOA.  The CRA URS does not allow for new MOA registrations. e) 145, 146,147 & 148 (Log Refs. CRA_4, 5, 6 & 7)\nf) BSCP 20 v.3 sections 3.3.3, 3.3.4, 3.3.5 and describe the process whereby an old registrant can object to a change of registrant of a metering system.  If an objection is raised, the CRA has to inform the CDCA and then refer the matter to BSCCo.  Section 3.4.3 goes on to say that an MOA can also raise objections about changes of meter registration. T","The CRA URS needs to be amended to describe these de-registration and objection procedures clearly and in accordance with the relevant BSCP. Inconsistency 1 BSC_A URS_CRA CRA URS needs to be updated to acknowledge the receipt from BSCCo of updated Party information.","−",null,"ISG","−","Closed"]
[634,"Inconsistency between IDD, NDFC & Reporting Catalogue","N/A","2001-06-13","The term 'Code of Practice Requirement' is used incorrectly in the IDD (CDCA-I018), the NETA Data File Catalogue and the Reporting catalogue\nThis CP has been raised to replace NCR309","Replace the term ‘Code of Practice Requirement’ with the term ‘BSCP Requirement’ in the following documents: Reporting Catalogue (Section 6.4) Logica IDD (CDCA-I018) NDFC (Annex G)","−",null,"ISG","Implemented"]
[633,"Bid-Offer records within Settlement Report","ELEXON","2001-06-13","Add a note to the description of Flow SAA-I014 sub-flows 2 and 3 in the IDD stating that only accepted bid-offer pairs are reported in settlement runs after the Interim Initial Settlement Run.\nThis CP has been raised to supersede NCR338.","Version 3.6 of the “Interface Definition and Design – Part 2” requires the following changes: For both Section 7.26, page 63 and Section 5.17, page 46, add the following sentence after “For subsequent Settlement Runs … and BM Unit Period Bid-Offer Acceptance Spot Points (BO3)”: “Furthermore, BM Unit Period Bid-Offer Information (BO4) and BM Unit Period Bid-Offer Spot Points (BO2) are only provided for Bids/Offers that have been accepted.”","−",null,"ISG","−","Rejected"]
[632,"Inconsistencies in  SAA URS","ELEXON","2001-06-13","This CP has been raised to address inconsistencies identified by the NETA Programme and subsequently reviewed by ELEXON. (IRP CP026). a) Inconsistency 375 URS_SAA_4 BSC uses 'BM Unit metered volumes for suppliers'. The URS has 'Allocated supplier volumes'.  Meaning is the same but the different terminology could be confusing. b) Inconsistency 385 URS_SAA_14 When establishing bid offer ranges, Section T 3.5.2(b) states that where the bid offer pair number is less than zero (n<0) then BOLRnij(t) has two possible values, depending on FPNij(t).  The URS SAA-F005 part 3 has the same values for BOLR but the condition is for when n<1.  c) Inconsistency 387 URS_SAA_16\nT 3.6.1 lists the two equations for determination of Accepted Bid-Offer Volume, qABOknij(t).  In the Code, the second qAij term has a superscript of k-1 for both equations (i.e. qAk-1ij).  The URS section SAA-F005 part 5 just has qAk-i","CP0632 aimed to remove inconsistencies between section T of the BSC Code v.1.1 and the SAA URS v.2.4.","−",null,"ISG","Implemented"]
[631,"Inconsistencies in the BMRA URS","ELEXON","2001-06-13","BSC Section Q 6.1 Submission of data to the BMRA and BMRA URS BMRA-I003 version 2.3 use different terminology to reference the same data item: Section Q 6.1.2 (b) uses \"national Generating Plant Demand Margin\" compared with the BMRA URS BMRA-I003 that uses \"National Demand Forecast Week\". Q 6.1.3 uses \"peak National Demand forecast\" compared with the BMRA URS BMRA-I003 that uses \"National Demand Forecast Day\". Q 6.1.4 uses \"peak National Indicated Margin\" compared with the BMRA URS BMRA-I003 that uses \"National Margin Forecast, 2-14\".\nThe times when data is sent from the Transmission Company to BRMA are stated in Section Q 6.1.7.  These times should be replicated in Appendix C of the BMRA; however the BMRA URS makes no reference to the 1600 transmission.","CP063 aimed to remove inconsistencies between the BMRA URS and section Q of the BSC Code.","−",null,"ISG","Implemented"]
[630,"Inconsistency in BSCP01","ELEXON","2001-06-13","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON.  (IRP CP023)\nChange the diagram in BSCP01 section 3.1 to include a 'GSP Group Take' arrow flowing from the CDCA to the SAA.","Change the diagram in BSCP01 section 3.1 to include a ‘GSP Group Take’ arrow flowing from the CDCA to the SAA.","−",null,"ISG","Implemented"]
[629,"Inconsistencies between the BSC & the CDCA URS","ELEXON","2001-06-13","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON.  (IRP CP025)\nBSC Section R, 5.6.2 says that for each Volume Allocation Run the CDCA shall ensure that it makes use of any relevant data that has been adjusted or revised since the Initial Run.  In section 5.6.3 the Code explains that the relevant information includes registration data, Meter Technical Details, Aggregation Rules, Line Loss Factors and metered data.\nThe CDCA URS sections F026 and F027 say that adjusted metered data should be taken into account, and omits the other information types.","Amend CDCA URS sections F026 and F027 to make clear that the CDCA should carry out a Volume Allocation Rerun when any changes have been made to the following: Metered Data, Line Loss Factors, Aggregation Rules, Registration Data and Meter Technical Details.","−",null,"ISG","Implemented"]
[628,"Design Deficiency in Non Half Hourly Data Aggregator (NHHDA)","ELEXON","2001-06-11","See the solution description. ","These following options were discussed at the Software Technical Advisory Group (STAG) 1. Do nothing – The number of incorrect supersede Instructions will continue to grow and will have an impact on data quality and the accuracy of initial settlement, because the correct EAC/AA will not be used in aggregation. 2. Change the NHHDA Software. The solution discussed has been aired since March 2000 and is considered by STAG members to be the only practical change to make to the NHHDA software.","−",null,"SVG","Implemented "]
[627,"Changes to BSCP301","ELEXON","2001-06-08","Interface tests undertaken by the FAA covers the both manual and electronic interfaces with Parties, however the interface with Clearing Banks is not tested until it comes to actually claiming the payment.  The process detailed in BSCP301 needs to be clarified to explicitly exclude Interface Tests with Clearing Banks and the Communication Requirements Document should reference the tests undertaken between the FAA and Parties.\nThis Change Proposal has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON (IRP CP021)","Inconsistency 167 FAA_01 65, Inconsistency 168 FAA_02 65 & Inconsistency 174 FAA_08 65 The process detailed in BSCP301 version 2 needs to be clarified to explicitly exclude Interface Tests with Clearing Banks and the Communication Requirements Document should reference the tests undertaken between the FAA and Parties.","−",null,"ISG","−","Withdrawn"]
[626,"Out of Sequence File Handling","ELEXON","2001-06-08","BSC, Section P 2.3.5 and 3.3.5 relates to the ordering of Volume Notifications (ECVNs and MVRNs respectively), and requires only that it be established whether one Volume Notification is prior to another. \nTherefore, in order to ensure that Volume Notifications were processed in the order required by the Notification Agent, ECVAA implemented File Sequence Numbering. This requires that file headers of Volume Notifications contain a File Sequence Number and on receipt of each Volume Notification from a Notification Agent, ECVAA checks the File Sequence Number to determine whether the Volume Notification is the next expected file (i.e. the File Sequence Number of the last received file incremented by 1) from that Notification Agent.","ECVAA system functionality be amended to remove rejections as a result of out of sequence file handling.","−",null,"ISG","−","Rejected"]
[625,"Inconsistencies between the BSC and the  BMRA URS","ELEXON","2001-06-07","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed and deemed to be valid by the Inconsistency Review Project (IRP CP010). a) BMRA URS refers to ETMO & ETLMO as opposed to TMO & TLMO detailed in the Code.  b) The Code does not reference \"(=SkCAOknij)\" detailed in the BMRA URS Version 2.2 F003.\nc) The S in the BMRA URS F004_4 should be S.","Inconsistency 367 BSC_T BMRA URS should be amended to use the same defined terms as the Code. Inconsistency 368 BSC_T The inconsistency should be removed from the BMRA URS. Inconsistency 370 BSC_T Change the BMRA URS F004_4 such that the \"S\" is \"Σ\" (i.e. change the font to \"Symbol\").","−",null,"ISG","−","Withdrawn"]
[624,"Change to BSCP05","ELEXON","2001-06-07","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON (IRP CP015).\nBSCP05 instructs the CDCA to notify the Registrant, MOA, DSO and BSCCo of MAR results, for BSCCo only where there is a discrepancy greater than +/- 0.1% and DSO as appropriate.   R 6.2.1 (b) makes no reference to the DSO being notified.","BSCP05 step 3.1.8 should be amended to remove “(and if appropriate DSO)”.","−",null,"ISG","−","Closed"]
[623,"Change to BSCP03","ELEXON","2001-06-07","Description of Change (mandatory by originator) This Change Proposal has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON (IRP CP014). Inconsistency PWC 37 - BSCP03 v2.0 3.1.4 currently states that the CDCA shall send the raw Meter Data Report to the Registrant, DSO or TC and Non Owner Party. The CDCA URS currently has no requirement for the CDCA to send the report to these parties. Proposed Solution(s) (mandatory by originator) Inconsistency PWC 37.\nAmend the CDCA URS to include the issuing of the Meter Data Report to the Registrant, DSO or TC and Non Owner Party. Justification for Change (mandatory by originator)\nTo remove inconsistencies between BSCP03 v.2 and CDCA URS v.2.4","Inconsistency PWC 37 Amend the CDCA URS to include the issuing of the Meter Data Report to the Registrant, DSO or TC and Non Owner Party.","−",null,"ISG","−","Closed"]
[622,"Changes to the NETA Data File Catalogue",null,"2001-06-07","This CP has been raised to address a number of inconsistencies in the NETA Data File Catalogue","See the description of the issue. ","−",null,null,"−","Rejected"]
[621,"Changes to BSCP20",null,"2001-06-07","This CP has been raised to address a number of inconsistencies in BSCP20","See the description of the issue. ","−",null,null,"−","Rejected"]
[620,"Receipt of CDCA-I050","ELEXON","2001-06-07","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON. (IRP CP009)\na) URS CDCA-I050 currently states that if the SAA finds an error when processing CDCA files, it should send an exception report to the CDCA. There is currently no reference to the CDCA receiving this report in the BSCPs.","Inconsistency PWC 19 Suggest amending relevant BSCPs to include details of CDCA receiving this report.","−",null,"ISG","−","Withdrawn"]
[619,"Amendments to TAA URS","ELEXON","2001-06-07","This CP has been raised to address a number of inconsistencies in the Technical Assurance Agent User Requirements Specification","CP0916 aimed to remove inconsistencies between BSCP26 v.2, BSCP32 v.2 and TAA URS v.1.3.","−",null,"ISG","Implemented"]
[618,"Changes to the CDCA URS","ELEXON","2001-06-07","This CP has been raised to address a number of inconsistencies in the Central Data Collection Agency User Requirements Specification document.","CP0618 aimed to remove inconsistencies between:\nBSCP03 version 2;\nBSCP05 version 2;\nBSCP20 version 3;\nBSCP26 version 2;\nBSCP68 version 3; and\nCDCA URS version 2.3.","−",null,"ISG","−","Withdrawn"]
[617,"Inconsistencies between the BSC & the Reporting Catalogue","ELEXON","2001-06-07","Raised from NCR387\nBSC v1.1 contained some changes to Section V. Specifically the requirements for NGC to report certain data items up to five days ahead was removed and replaced with the requirement to report these values up to one day ahead.  The Reporting Catalogue was not updated to reflect the changes to the Code.","Changes to the Reporting Catalogue to bring it in line with v1.1. of the BSC.","−",null,"ISG","−","Withdrawn"]
[616,"Service Levels for the Reporting of data to NGC by Logica","ELEXON","2001-06-06","Raised from NCRs 336 and 248 NGC requires information from flow SAA-I014 to calculate the TSUoS charges for participants.   In order to meet their commitments under BSCP01 NGC require the SF (Initial Settlement), RF (Reconciliation) and D (Disputes) versions of this flow by 06:00 on the relevant day (e.g. D+17 in the case of SF) to enable the appropriate billing reports to be generated and sent to FAA by 12:00.  NGC also requires the II (Interim Initial) version of SAA-I014 by 12:00 on the relevant day to enable the draft bills to be processed and sent to participants by 17:00.\nThe current settlement timetable only requires Logica to produce the report on a particular day and send it to NGC with no time constraint on arrival.  This is not sufficiently stringent to ensure that NGC can meet their obligations","See the description of the issue. ","−",null,"ISG","−","Withdrawn"]
[615,"Alignment of the CRA URS with the BSC","ELEXON","2001-06-06","Raised from NCR360 \nBSC Section K 1.4.4 makes reference to the capture of information on both Boundary points and System Connection Points. The URS currently makes no reference to the capture of information on System Connection Points. The CRA systems as built and implemented allow capture of all relevant information. Hence this NCR is to align the URS with the Code and with the systems as implemented.","Amend Function CRA-F017 to reference the capture of System Connection Points.","−",null,"ISG","Implemented"]
[614,"BSCP32:  Metering Dispensations - Consultation comments","ELEXON","2001-06-06","See the solution description. ","A Transfer of Metering Dispensation Section 3.4: To be expanded to cover the application process to transfer metering dispensations for both CVA and SVA metering systems. See Attachment 1 B Not needed for Go live Sections 1.10, 4.1, 4.3, BSCP32/4.1a, BSCP32/4.1b, BSCP32/4.3a, BSCP32/4.4, BSCP32/4.5: Redlining in section 1.1 has changed “commercial boundary” to “Boundary Point or Systems Connection Point”. These amendments should be made to the sections identified throughout the document. Section 1.11: The comma after the second occurrence of “Equipment” should be removed. Forms 4.1a and 4.3a: It is not clear what is being requested in the “Dispensation against the requirements in relation to the commercial boundary set out in the BSC” or the “BMU Configuration” spaces on the form. Add (Y/N) box as appropriate. Forms4.1ab and 4.3b: The declaration statement should include the words “and BSC” at the end of the first sentence. Form 4.4: This form should include the application reference number as allocated by BSCCo. Form 4.5: Replace “Pooling and Settlement Agreement” with BSC. DRA appears on this form, which should either be replaced or explained in section 2.1.","−",null,"ISG","Implemented"]
[613,"FAA Bad Debt Processing","ELEXON","2001-06-06","This CP supersedes NCR154.\nThe FAA needs to be able to support the processes for dealing with Bad Debts as described in clause 8.4 of Section N of the BSC.  In summary this requires that the costs of any such losses are shared among Parties in proportion to their General Funding Share.  This CP will also require a process by which BSCCo (ELEXON) provides the monthly General Funding Shares values for each Party to the FAA","The FAA needs to be able to support the processes for dealing with Bad Debts as described in clause 8.4 of Section N of the BSC. In summary this requires that the costs of any such losses are shared among Parties in proportion to their General Funding Share. This CR will also require a process by which BSC Co (ELEXON) provides the monthly General Funding Shares values for each Party to the FAA. This CR is raised to initiate a high level impact analysis by EPFAL and detailed discussions to identify the most effective way of delivering the requirement. No formal issue Get response from Epfal - Deliver without impact party system","−",null,"ISG","−","Withdrawn"]
[612,"Changes to the CRA URS","ELEXON","2001-06-06","This CP has been raised to address inconsistencies:\na) BSCP15 sections 3.5.8, 3.5.9 and 3.6.1 are somewhat misleading and require clarification.\nb) BSCP15 section 3.1.6 states that the CRA will inform the CDCA, TC and BSCCo when a new BM Unit is registered; IDD CRA-I015 states that the BMRA, FAA and ECVAA should be informed. \nc) BSCP15 section 3.1.7 states that if BM Unit is embedded, the CRA shall notify the relevant DSO.  This requirement is not in the CRA URS.\nd) BSC section A 3.3.5(a) places an obligation on the BSCCo to send a copy of Party details to the CRA.  The URS section 1 says that the CRA shall seek authorisation from BSCCo for changes to registration details.","Inconsistency PK1/316 BSCP15 sections 3.5.8 and 3.5.9 (De-registration of BM Units) should be clarified to make clear that these steps are not required for CMRS/SMRS transfers. In addition, section 3.6.1 should be altered so that the time-scale for notification of cessation of a supplier is 30WD prior to the Effective Date, rather than just 30 days, which may be misleading. Inconsistency 13 (Log Ref. CRA_03) CRA-I015 should be changed so that the CRA informs the CDCA, TC and BSCCo. Inconsistencies 14 and PWC3 (Log Ref. CRA_04) The CRA URS should be altered so that the relevant DSO is notified by the CRA if a registered BM Unit is embedded. Inconsistency 1 (Log Ref. URS_CRA 1) The CRA URS section 1 should be altered to read: “This process, regardless of registration object, thus has a number of key, common features. These are detailed in CRA-N001 and summarised below prior to the individual functional requirements.",null,null,"ISG","—","Withdrawn"]
[611,"Inconsistencies between the CRA URS and BSCP65","ELEXON","2001-06-06","1. Currently, the CRA URS does not recognise the requirement stated in BSCP65, Section 3.18 to undertake Interface Tests;\n2.  BSCP65 Version 2.0 currently does not stipulate the Central Data Collection Agent as a user of the BSCP in respect of Interface Tests.\nRaised from NCR 321","Modify the URS/BSCP65 to reflect this requirement. See NCR 321 attached for details of the specific changes to be applied.","−",null,"ISG","−","Rejected"]
[610,"IDD Documentation Errors and Inconsistencies","ELEXON","2001-06-06","A small number of documentation errors and inconsistencies have been identified in the IDD document and spreadsheet - Part 2.  See NCR325 for details of the inconsistencies.","A small number of documentation errors and inconsistencies have been identified in the IDD document and spreadsheet – Part 2. Please note that the changes detailed below are not believed to have any material impact on any systems, however, it is necessary for clarity that the documentation is brought in line with the system functionality. 1. Section 5.16 of IDD Document - Part 2: in the definition of SAA-I014, NGC variant (S0142), add Bid-Offer data (B04) to the list of data which is only included in Settlement Run reports where there are changes (this is the current functionality of the report and has been discussed with NGC). 2. IDD Spreadsheet – Part 2 - NGC Sheet - ADJUST flow - the \"Sett Date\" item data type changes to \"date\" from \"datetime\" as there is already a Settlement Period in the flow - note that this flow currently arrives manually and this definition is only used internally by the Central Systems.","−",null,"ISG","Implemented"]
[609,"Visual Inspection of Metering Systems - Changes to BSCP05","ELEXON","2001-06-06","1. a new form to be completed by the CDCA on a meter reading site visit and an associated new step in the Interface Timetable, 3.1.6.  The new form includes an additional requirement for the CDCA to check for any de-energised circuits, this requirement will also need to be reflected in section 4.3 of the BSCP.\n2. Step 3.1.9 to be expanded: \"Notify the Registrant and MOA of the MAR result(s) and request an explanation of discrepancies greater than +/- 0.1%\" and Step 3.1.11 the recipient should be the MOA and not the Registrant.","Amendment A Attached is a new form (Attachment 1) to be completed by the CDCA on a meter reading site visit and an associated new step in the Interface Timetable, 3.1.6. (Attachment 2) The new form includes an additional requirement for the CDCA to check for any de-energised circuits, this requirement will also need to be reflected in section 4.3 of the BSCP, see Attachment 3. Amendment B Step 3.1.9 to be expanded : “Notify the Registrant and MOA of the MAR result(s) and request an explanation of discrepancies greater than +/- 0.1%” and Step 3.1.11 the recipient should be the MOA and not the Registrant.","−",null,"ISG","Implemented"]
[608,"Improvements to BSCP509","ELEXON","2001-06-06","Section 1.5 List of Associated BSC Procedures is incomplete.  Add “BCSP11, BSCP40, BSCP65, and BSCP508\".\nSections 1.3, 2.2, 3.6, 4.1.1, & 5.2c: The term \"Effective Date\" is misleading and change should be reversed. Replace with \"Go Live Date\".","Following review by ELEXON, the NETA Programme and also Cap Gemini changes are proposed to a number of legal framework products which include the SVAA related legal framework and also those legal framework products which have been amended to support either the NETA Package 1, NETA Package 2 and / or re-badging. This NCR focuses on the changes that are required to BSCP 509, “Changes to Market Domain Data” only. These changes are critical for Go Live. There may be an impact on the SVA Agent as a result of implementing these changes. Please refer to the attachment on p3 for details of the required changes.","−",null,"ISG","Implemented"]
[607,"Error Messaging","ELEXON","2001-06-06","Description of Change:\nEnhance PCSec to include defined parseable error messages. Proposed Solution(s):\nAn assessment from Logica is required detailing the options in addressing this requirement and associated costs. Justification for Change: The change described in this Change Proposal will provide a more useable version of PCSec.\nThis change was proposed by the NETA Programme.  ELEXON undertook to take this forward after NETA Go Live.","An assessment from Logica is required detailing the options in addressing this requirement and associated costs.","−",null,"ISG","−","Rejected"]
[606,"Support for PCSec under Windows 2000","ELEXON","2001-06-06","Support for PCSec to run under Windows 2000.  (Currently the Windows NT version is believed to work properly but it is not formally supported by Logica).\nIt is understood that the Baltimore Toolkit that is used to build PCSec is only officially supported under Windows NT.","An assessment from Logica is required detailing the costs associated with meeting this requirement.","−",null,"ISG","−","Rejected"]
[605,"UNIX Version of PCSec","ELEXON","2001-06-06","Description of Change: Develop a version of PCSec to run under UNIX.  This was first documented as NCR261. An investigation by Logica is therefore required to determine costs and timescales involved in providing versions of the PCSec utility on UNIX platforms. Note: The investigation of this requirement should also consider the enhanced functionality that is described by other outstanding Change Proposals that relate to PCSec. Proposed Solution(s):\nA version(s) of PCSec to run under UNIX Justification for Change :\nThis change was proposed by the NETA Programme.  ELEXON undertook to take this forward after NETA Go Live.","A version(s) of PCSec to run under UNIX.","−",null,"ISG","−","Rejected"]
[604,"Removal of restriction on Polling Interval","ELEXON","2001-06-06","At Go Live it was recognised that PCSec seemed to have a 'memory leakage' problem. This defect caused significant problems when PCSec was used with a sub-second polling interval as originally specified. A work around was therefore agreed to increase the polling interval to 10 seconds in order to deliver a useable version of PCSec for Go Live.\nIt is understood by ELEXON that a technical solution to this defect has been found by Logica.  Consequently, it is proposed that the polling interval is set to the original sub-second interval to reduce the risk that files miss Gate Closure due to the slow polling of outbound files.","To re-configure PCSec with a sub-second polling interval as originally intended as part of a future release of PCSec.","−",null,"ISG","—","Withdrawn"]
[603,"PCSec as a Windows NT Service","ELEXON","2001-06-06","Description of Change: PCSec was developed as a user program under Windows NT.   This change is to enhance PCSec to run as a Service under Windows NT to enable standard NT System tools to be used in monitoring PCSec. Proposed Solution(s) : It is proposed to modify PCSec by introducing new functionality to meet the above requirement as a future release of PCSec. Justification for Change : The change described in this Change Proposal will provide participants with a more useable version of PCSec.\nThis change was proposed by the NETA Programme.  ELEXON undertook to take this forward after NETA Go Live.","It is proposed to modify PCSec by introducing new functionality to meet the above requirement as a future release of PCSec.","−",null,"ISG","—","Withdrawn"]
[602,"Three Enhancements for PCSec","ELEXON","2001-06-06","The following enhancements are proposed to PCSec 1) Start Up Messaging 2) PCSec as a callable routine \n3) Auto Restart of PCSec","It is proposed to modify PCSec by introducing new functionality to meet the above three requirements as a future release of PCSec.","−",null,"ISG","−","Rejected"]
[601,"Utilisation of Interconnector Error Administrator BMUs","ELEXON","2001-06-05","Currently the Central Services do not support the functionality described in the URS regarding the utilisation of Interconnector Error Administrator BMUs either as part of the registration process, or as part of the settlements process. SAA, as implemented, allocates the Interconnector Error Amounts directly to the Energy Accounts of the Party registered in the role of IEA, therefore bypassing the requisite allocation of this amount to one of the relevant Interconnector BM Units of the Interconnector Error Administrator for that Interconnector, as a result of the functionality for these BM Units not having been implemented in the Logica Systems.","Each BSC Party with the Interconnector Error Administrator role should be allocated and registered against two BM Units (one Production and one Consumption) of the type ‘Interconnector Error Administrator BM Units’. The CRA specification documentation should be updated to reflect how this is achieved. During settlement, the Interconnector BM Units should be used by SAA for the allocation of any Interconnector Error amount, according to the process defined in Section T 4.1 of the Balancing and Settlement Code and Section 5.10 SAA – F010 of the SAA User Requirements Specification. The note regarding Interconnector Users in Section 5.10 of the SAA URS is assumed to be incorrectly referencing Interconnector Users and that this should in fact refer to the Interconnector Error Administrator and this should be updated to reflect the implementation of the IEA BM Units.","−",null,"ISG","—","Withdrawn"]
[600,"BSCCo Ltd as a Recipient of SAA-I014 Sub flow 2.","N/A","2001-06-05","BSCCo Ltd currently receives the SAA-I014 Sub flow 3 but the information provided therein is not sufficient to meet the obligations on BSCCo Ltd with respect to reporting and monitoring requirements. BSCCo Ltd should become an 'official' recipient of the SAA-I014 Settlement Report, Sub Flow 2 for all Settlement Runs, thus providing an enduring solution for, and replacing, Workaround 014 (W014).","See the description of the issue. ","−",null,null,"−","Rejected"]
[599,"Non Unique ECVN / MVRN Feedback Reports","N/A","2001-06-05","Where a number of non unique volume notifications are submitted within day - i.e. where the ECVN Id and contract volumes are the same for a number of submissions, and there is a rejection at the business validation stage, insufficient information is contained within the rejection Feedback Report to identify the submission to which the rejection pertains.  Therefore an amendment to the information contained within the ECVN Feedback Report (ECVAA-I009) and MVRN Feedback Report (ECVAA-I010) is required to enable Trading Parties (and Notification Agents) to determine the volume notification which caused the rejection.\nThis CP supersedes NCR389.","Information unique to the submitted volume notification should be provided in the ECVN Feedback\nReport (ECVAA-I009) and the MVRN Feedback Report (ECVAA-I010) to enable determination by the Trading Party / Notification Agent of the original submission against which the rejection is being\nmade. This information could comprise the ECVNA / MVRNA File Creation Timestamp, and / or the\nFile Sequence Number, and /or the Filename from the header of the original submission.","−",null,"ISG","−","Rejected"]
[598,"Procedural problem with BSCP 04","ELEXON","2001-06-05","Change section 3 in BSCP04, \"BM Unit Metered Volumes for Interconnector Users\", to reflect the requirement for the SAA to inform BSCCo of missing BM Unit volumes for Interconnector Users.\nThis CP has been raised to supersede NCR368.","See the description of the issue. ","−",null,"ISG","2002-08-13"]
[597,"Changes to SAA-I014 to meet NGC's Audit Requirements","ELEXON","2001-06-05","The current NGC settlement report format does contain a CDCA Run Number field - however this is populated with the CDCA Run Number used by SVAA and thus reflects the Stage 2 meter volumes feeding into settlement, not the Stage 1 volumes).","Flow SAA-I014 should be modified to include the CDCA Run Number and Run Date whilst maintaining the run number and date provided by the SVAA. This change should apply to the NGC variant or the flow and, subject to consultation, the other variants as well.","−",null,"ISG","2002-08-13"]
[596,"Correction to the SAA URS","ELEXON","2001-06-05","SAA URS Section F013 contains a minor error.  In point 3 paragraph 2 it states that BSCC Ltd sets the FPN flag, when in fact the flag is set by the Lead Party as detailed in the CRA URS and BSCP15.\nThis Change Proposal has been raised to address NCR365.","The following changes should be made to SAA-F013, point 3, paragraph 2: “FPN Flags apply to BM Units, the Lead Party BSCC Ltd will identify BM Units for which the flag will be set to ‘N’, the default value will be ‘Y’. This flag will be used to indicate whether a Party is required to submit an accurate FPN for a particular BM Unit or not. The Lead Party BSCC Ltd will set these FPN flags through the CRA interfaces.”","−",null,"ISG","Implemented "]
[595,"Suppression of ELEXON Exception Reports","ELEXON","2001-06-05","ELEXON is receiving repeated SAA Data Exception Reports (SAA-I017) which are causing an overload on ELEXON processing, as ELEXON business procedures requires inspection of each such exception dataflow manually within the Formfill product.  There is no obligation on ELEXON to receive or process these SAA Data Exception Reports (SAA-I017) therefore they are considered unnecessary at this time.","The generation of SAA Data Exception Reports (SAA-I017) to ELEXON should be suppressed by ‘switching off’ these Exception Reports to ELEXON as a recipient. It should be noted that the ‘switching off’ of these reports should utilise the same functionality as that defined in BSCP41 (Report Requests and Authorisation) and that therefore ELEXON have the option to ‘enable’ receipt of these exception reports at a future date if so required, (by submission of the BSCP41/1 Form ‘Changes to Individual Reporting Requirements’).","−",null,"ISG","2002-08-13"]
[594,"Incorporation of the manual disputes process in CSDs","ELEXON","2001-06-05","The implementation of NCR129 will result in the FAA receiving, from BSCCo, the disputed amount to be recovered / paid and the revised payments / charges to be levied in order to distribute the sum over one or more Party. Consequently the FAA will be required to: 1. Calculate the VAT and interest. 2. Calculate the income tax to be deducted, if applicable. 3. Issue Advice Notes to each affected Party. 4. Collect and distribute payments in accordance with normal FAA processes.\nThis CP proposing to incorporate the details into the relevant Code Subsidiary Documents.","Incorporate the detail from the clarification note into the following Code Subsidiary\nDocuments: FAA Service Description. FAA User Requirement Specification (URS). BSCP11 ‘Volume Allocation and Settlement Run Queries’. BSCP301 ‘Clearing, Invoicing and Payment’. NETA Data File Catalogue: Although the interface between the BSCCo and the FAA will\nbe manual there is a requirement to add this interface.","−",null,"ISG","−","Rejected"]
[593,"Interim Initial Settlement Run (CDCA URS)","ELEXON","2001-06-04","The SVAA does not require GSP Group Take Information as provided by flow CDCA-I043 for Interim Initial Settlement runs. The SVAA requires this information from the first settlement Final (SF) run and for all subsequent settlement, reconciliation and dispute runs. The CDCA URS does not recognise this requirement and the Logica IDD does not allow flows to be switched on and off by reference to the Settlement Run Type. \nThis Change Proposal has been raised to supersede NCR305, and will provide the enduring solution to Workaround W005.","The CDCA URS, system and service should be modified to reflect the SVAA’s requirements.","−",null,"ISG","Implemented "]
[592,"Inconsistencies between Central Services Software and the NDFC","ELEXON","2001-06-04","All NETA Central Services software should be consistent with decimal formats in the NETA Data File Catalogue.","The NETA Data File Catalogue V3.0 Section 4.4.4 defines the decimal format to be used by\nNETA Central Services interfaces. Amend all NETA Central Systems software so that those Data Items with format “Decimal” follow the rules set out in section 4.4.4.","−",null,"ISG","−","Rejected"]
[591,"Availability of Transmission Company SAA-I014 Reports","ELEXON","2001-06-04","This CP proposes to improve the process for providing the following reports/data to Parties:  1) Settlements Reports for all Trading Parties (2) Balancing Mechanism Data\n(3) Historic Balancing Mechanism Data","(1) Make the Transmission Company variant of the SAA-I014 (S0142) available to all Parties on request by removing the role code restriction. Alternatively, the data could be made available as a download on the NETA website (a zipped Transmission Company SAA-I014 is approximately 1 Meg including Bid-Offer data and 400kByte without Bid-Offer Data.) If the Settlement Administration Agent costs are too high and the implementation timescales too long, ELEXON has the data and could possibly make the data available from the ELEXON website or via email. (2) Balancing Mechanism data is contained in the Interim Information Run of SAA-I014 sent to the Transmission Company (iS0142). Hence availability of this report, as above, provides a solution to this problem. (3) Until data is available on an ongoing basis, a possible solution is to make available Balancing Mechanism data from the Go Live Date available on CD-ROM, with monthly updates.","−",null,"ISG","−","Rejected"]
[590,"Design enhancements to the standing data process","ELEXON","2001-06-04","This CP proposes to: 1. Streamline the CVA and SVA standing data activities so that they are contained in one BSCP.  As a result of the introduction of NETA, there are now standing data processes, which impact both CVA and SVA.\n2. Remove the interfaces between BSCP07 and \"Feeder BSCPs\".  Currently when certain CVA standing data are updated e.g. BM Unit Registration data, CRA notifies the affected parties electronically.  Therefore there is little point in the CRA additionally informing the affected parties manually that the change has been applied, which is the obligation in BSCP07.\n3. Incorporate the NETA process, for the provision of changes to BSC Agent contact details relating to CVA and SVA standing data, into the streamlined BSCP.  The SVA aspects are currently documented in BSCP507.","1. Streamlining the Code Subsidiary Documentation\nIncorporate the existing SVA standing data activities contained in BSCP507 in BSCP07.\nThe following changes are proposed:\na) Withdraw BSCP507 from service.\nb) Replace BSCP507 cross-references with BSCP07 in the following documents:\n2. Removing links to “Feeder BSCPs”\n3. Incorporation of new NETA process\nThere is a requirement for BSC Agents to provide CRA with changes to BSC Agent\ncontact details but this is only currently covered in BSCP507 from a SVAA perspective.","−",null,null,"−","Rejected"]
[589,"BMRA BM Unit Identification","ELEXON","2001-06-04","This Change Proposal supersedes NCR264. The BMRA screens currently do not display sufficient information to allow participants to ascertain the market position.  This CP proposes changes to enable users to: view the BM Unit registration data, to enable users of the service to identify and search on BM Unit information in which they have specific interest.\n§ enhance the single BM Unit selection facility in BMRS with a facility to select and sort displayed information by a variety of keys and selection criteria.","1) BM Unit Identification.\na) The majority of information currently displayed on the BMRS is referenced by BM\nUnit. Implement a BM Unit information search facility, which would allow users to more easily identify and access data on BM Units in which they have a specific interest.\nb) The information could be provided in a screen that detailed for each BM Unit.\nc) The information should be downloadable in a standard CSV format.\n2) BM Unit Selection Criteria\na) Enhance the BM Unit Data reports in the BMRS to enable selection of data across\nmultiple BM Units.\nb) Enhance the BM Unit Data reports to enable filtering and sorting of data according to\na number of keys (see 1(b) above).\nc) Make the information downloadable in a standard CSV format.\nd) Any implementation of this facility should not impede the performance of the system\ndue to the volume of data selected.","−",null,"ISG","2002-12-10"]
[588,"Data Receipt and Validation by the SAA","ELEXON","2001-06-04","Section T 1.4 of the BSC Code v.1.1 describes the process to be followed by the SAA when data required for Settlement Runs is missing or invalid.  It places an obligation on the SAA to decide whether the missing or invalid information makes up a significant proportion of the total Settlement data and sets out different options accordingly.  Reference is made to BSCP01, and here each inbound data flow to the SAA is listed along with the procedure to be followed when the data is, in the Sea’s opinion a significant or insignificant proportion of the Settlement Data.  The procedure has two possible outcomes: BSCCo can send the SAA default data to be used in the Settlement Run in place of any invalid or missing information; or BSCCo can instruct the SAA to delay the Run until all the required data has been collected.","A change is suggested to section F002 of the SAA URS.","−",null,"ISG","−","Rejected"]
[587,"Inconsistency for Data Retention Requirements","ELEXON","2001-06-04","This CP supersedes NCR250 There is an inconsistency between Section W:  Trading Queries and Trading Disputes and SVA Code Subsidiary Documents.  \nSection W of the Code extends the current timescales for raising a Dispute in respect of a Settlement Day from 2 years to 3 years.  SVA Code Subsidiary Documents currently oblige the SVAA, Suppliers and their Agents to retain data to support Disputes for a period of 28 months.","There are 2 possible solutions: 1. reduce the period in which a Trading Query or Trading Dispute may be raised from 3 years to 2 years. This solution would require a modification to para 1.2.5 of Section W: Trading Queries and Trading Disputes; 2. extend the data retention period to support the raising of a dispute up to the 3rd anniversary of the Settlement Day to which the Dispute relates. This solution would require a number of SVA Code Subsidiary Documents (listed in NCR250 attached) to be amended.","−",null,null,"−","Rejected"]
[586,"Notification of Files where decryption has failed","ELEXON","2001-06-04","If a participant sends in a file that fails in decryption, then no error message is returned.  The only way of detecting the problem is that the expected acknowledgement for the file does not arrive. In such cases it is not possible for the NETA Central Systems to generate an automatic NACK (Not Acknowledged) because the necessary information cannot be extracted from the file to trigger such a process.","A version of PowerSec that produces a “free text” NACK for files that fail decryption and sends this to the owner of the directory where the undecryptable files arrived.","−",null,"ISG","−","Rejected"]
[585,"BMRA and SAA Data Corrections to Replace W018","ELEXON","2001-06-04","The BM System Operation Agent cannot electronically resubmit all data provided to the BMRA and SAA via interface BMRA-I002 (BM Data), when it is found that the data originally submitted was incorrect or incomplete. Currently all data corrections are resubmitted through a manual process implemented as Workaround W018.\nThis CP describes the options for replacement of Workaround W018 with an enduring solution.","A number of possible options have been identified. This Change proposal seeks High Level Impact Assessment of each option and views on the most appropriate solution.","−",null,"ISG","−","Closed"]
[584,"BSCP26:  Policing of Metering Systems for CVA","ELEXON","2001-06-04","Section 1.11: last paragraph: replace ‘to effectuate rectification’. Section 1.11: re-word to “…configurable meter parameters (as detailed in the Meter Technical Details) are not….” Section 1.14 below the bullets: replace with ‘Each month the TAA shall:’\nTable 3.1: All Methods to order manual methods as email / fax/ letter","See the description of the issue. ","−"]
[583,"Clarification of methods for requesting reports under BSCP41","ELEXON","2001-06-04","Changes to BSCP41 to clarify the process for requesting reports and publication of an updated list of available reports.","Currently there are two methods for requesting reports under BSCP41; firstly to request reports defined as being available to “Any Party on Request” and secondly confidential reports i.e. reports classified as being available to the “Relevant Party”. To clarify the process it is proposed that the procedure is broken down into 3 areas: 1) Amendments to a Parties or Party Agents Standard Reports; 2) Reports Available to “Any Party on Request” and 3) “Relevant Party” Reports Made Available to Another Party","−",null,"ISG","−","Rejected"]
[582,"Update of Logica TAA Service description","ELEXON","2001-06-04","This CP has been raised to implement material changes to the TAA Service Description (originally raised during the NETA Programme as Logica CR142)","CR148 was raised to make non-material changes to the Logica Service Descriptions. This NCR is to track the changes to the above Service Description.","−",null,"ISG","−","Rejected"]
[581,"Update of Logica SAA Service description","ELEXON","2001-06-04","This CP has been raised to implement material changes to the SAA Service Description (originally raised during the NETA Programme as Logica CR139)","CR148 was raised to make non-material changes to the Logica Service Descriptions. This NCR is to track the changes to the above Service Description.","−",null,"ISG","−","Rejected"]
[580,"Update of Logica ECVAA Service description","ELEXON","2001-06-04","This CP has been raised to implement material changes to the ECVAA Service Description (originally raised during the NETA Programme as Logica CR143)","CR148 was raised to make non-material changes to the Logica Service Descriptions. This NCR is to track the changes to the above Service Description.","−",null,"ISG","−","Rejected"]
[579,"Update of Logica CDCA Service description","ELEXON","2001-06-04","This CP has been raised to implement material changes to the CDCA Service Description (originally raised during the NETA Programme as Logica CR144)","CR148 was raised to make non-material changes to the Logica Service Descriptions. This NCR is to track the changes to the above Service Description.","−",null,"ISG","−","Rejected"]
[578,"Update of Logica CRA Service description","ELEXON","2001-06-04","This CP has been raised to implement material changes to the CRA Service Description (originally raised during the NETA Programme as Logica CR140)","CR148 was raised to make non-material changes to the Logica Service Descriptions. This NCR is to track the changes to the above Service Description.","−",null,"ISG","−","Rejected"]
[577,"Update of Logica BMRA Service description","ELEXON","2001-06-04","This CP has been raised to implement material changes to the BMRA Service Description (originally raised during the NETA Programme as Logica CR141)","CR148 was raised to make non-material changes to the Logica Service Descriptions. This NCR is to track the changes to the above Service Description.","−",null,"ISG","−","Rejected"]
[576,"Recording of Transmission Los Factors by Settlement Period","ELEXON","2001-06-04","Make Transmission Loss Factors (TLFs) effective on a Settlement Period basis, rather than a Settlement Day basis, in the NETA Central Services (SAA and BMRA)\nThis CP has been raised to supersede NCR 395","Amend the SAA and BMRA software so that TLFs are effective for a Settlement Period for a BM Unit","−",null,"ISG","−","Rejected"]
[575,"Party and Party Agent Authorisations","ELEXON","2001-06-04","The authorisation process is unclear in the Logica URSs/Service Descriptions as to which flows need to be received from a registered authorised person. The authorisation process also needs to be clarified, are both signatures and passwords required. This Change Proposal has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON. (IRP CP 019)","Where applicable the authorisation process should be detailed / clarified in Logica IDDs / Service Descriptions and BSCP398.","−",null,"ISG","−","Rejected"]
[574,"Payment & Settlement Calendars","N/A","2001-06-04","Inconsistency A- Payment Calendar BSCP301 version2, FAA URS Issue 7 version 11, FAA IDD Part 1 Issue 12 version 15 and FAA Service Description version 14 are not consistent on who the Payment Calendar recipients are: BSCP301: BSCCo, SAA and Payment Parties; FAA URS: Parties, SAA and BSCCo; FAA IDD: BSCCo, Parties and SAA; and FAA Service Description: all relevant Agents and Payment Parties. Inconsistency B - Settlement Calendar BSCP301 version 2 and Logica IDD Part 1 version 3_6 detail different recipients for the Settlement Calendar: BSCP301: SVAA, CDCA and Payment Parties; and Logica IDD: Parties, Party Agents, SVAA, BSCCo and the CDCA.","This Change Proposal has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON. (IRP CP017)","−",null,null,"−","Rejected"]
[573,"Amendment to BSCP71","ELEXON","2001-06-04","BSC Section P 2.2.2 and 3.2.2 states that an Authorisation Termination is effective when received by the ECVAA, however BSCP71 states that it can only be effective 1 Calendar Day after receipt by the ECVAA.\n","Amend BSCP71 sections 3.3.1 and 3.5.1 to state that an Authorisation Termination is effective when received by the ECVAA.","−",null,"ISG","−","Rejected"]
[572,"Inconsistencies between the BSC and BSCP01","ELEXON","2001-06-04","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed and deemed to be valid by the Inconsistency Review Project (IRP CP013). Errors relating to the SAA have been identified in BSCP01. In several sections, 'Quiescent Physical Notification' has been omitted or misplaced, required a change in the BSCP.","Change BSCP01 sections 3.2, 4.1.3, 4.1.8, 5.1 and 5.2 to include Quiescent Physical Notification along with Final Physical Notification. Section 4.1.6 should also be changed so the QPN is sent at the same time as the FPN, i.e. no later than 15 minutes after Gate Closure instead of 5 minutes.","−",null,"ISG","2002-08-13"]
[571,"Amendments to the ECVAA URS","ELEXON","2001-06-04","This CP has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed and deemed to be valid by the Inconsistency Review Project (IRP CP002). a) The BSC Code section M 3.3.3 refers to Credit Default Refusal and Rejection Periods for ECVNs/MRVNs.  These terms are not mentioned in the ECVAA URS.\nb) BSCP71section 3.2.5 states that when an ECVNA/MVRNA Authorisation specifically supersedes another one, the ECVAA should send confirmation to the ECVNA/MVRNA and Lead and Subsidiary Parties.  The ECVAA URS makes clear that an acceptance confirmation is sent, but no mention is made of the process when one Authority supersedes another.","Inconsistency 130 (Log Ref. URS_ECVAA 28) Suggest amending the ECVAA URS to include Credit Default Refusal and Rejection Periods in the ‘Perform Credit Check’ section (ECVAA-F007). Inconsistencies 181 and 183 (Log Refs. ECVAA_02 & ECVAA_04): Amend sections F003 and F004 (Process EVNAA and MVRNA respectively) so that acceptance confirmation is also sent out if one Authorisation specifically supersedes another existing one.","−",null,"ISG","2003-06-24"]
[570,"Aggregation Rule – acknowledgements by CDCA","ELEXON","2001-06-01","A change to BSCP75 is required to allow acknowledgement of aggregation rules by e-mail, and an internal process is to be moved to an earlier step of the BSCP. See below NCR 374. Move an internal process in, as described in the redlined version attached, and allow acknowledgement by e-mail. This will ensure that BSCP75 is in line with the current operating procedures.  It covers PR0950.","Move an internal process in, as described in the redlined version attached, and allow acknowledgement by e-mail.","−",null,"ISG","2003-06-24"]
[569,"BSCP20 – Equipment Owners consent","ELEXON","2001-06-01","This CP has been raised to supersede NCR 367.\nBSC Section K 2.2.4 (g) states that the Equipment Owner’s consent is required before the registration of a Metering System becomes effective. Failure to implement this change will result in Registrants being in default of the Code when registering Metering Systems.","BSC Section K 2.2.4 (g) states that the Equipment Owner’s consent is required before the registration of a Metering System becomes effective.","−",null,"ISG","2002-08-13"]
[568,"Allocation of BM Units","ELEXON","2001-06-01","This CP supersedes NCR 359\nNTCC Ref 620 of the PST Reg script refers to ELEXON sending notification of the Supplier Id and associated Base BM Unit Ids to CRA on notification of a New Supplier, supported by BSCP15 3.3.1.  However, the actual process, as defined in CRA-F001 / CRA-F013 and BSC Section K 3.3.1 all support the operational process whereby the Base BMUs are generated automatically on registration of a Party as a Supplier, with the BMU Ids being allocated according to a defined and 'known' algorithm. The notification of Supplier registration/information from ELEXON and CRA is covered by BSCP65 3.1.6 and 3.1.11 and, as such, appear to be notifications distinct from the action defined by BSCP15 3.3.1.  The BSCP is, therefore, inconsistent with other industry documentation and with the operational process.","Amend BSCP15 3.3.1 to \"Notification of a new Supplier and Base BM Unit Ids.\"","−",null,"ISG","Implemented "]
[567,"Inconsistencies in BSCP15 and BSCP20","ELEXON","2001-06-01","This CP supersedes NCR 349. Under the ACTION column in BSCP 15 \"This process continues under BSCP509\" to be moved from step 3.3.5 to step 3.3.6.  Add a footnote in BSCP 20 section 3.1.8 to state \"Where the Technical Details are not consistent or not compliant to the relevant CoP, the registration will be rejected, and MOAs will be required to resubmit the Meter Technical Details under step 3.1.7.\"\nBSCP20 Section 3.1.8 – note 3 – Where the Technical Details are not consistent or not compliant to the relevant CoP the registration will be rejected, does this terminate the whole process or just that specific part?","BSCP15 Under the ACTION column in BSCP 15 \"This process continues under BSCP509\" to be moved from step 3.3.5 to step 3.3.6. BSCP20 Add a footnote number 3 in section 3.1.8 to state \"Where the Technical Details are not consistent or not compliant to the relevant CoP the registration will be rejected, and MOAs will be required to resubmit the Meter Technical Details under step 3.1.7.\"","−",null,"ISG","2002-08-13"]
[566,"IDD & BSCP03 - Consistent originator of flow CDCAI013","ELEXON","2001-06-01","The IDD CDCA-I013 is an input from either the MOA or BSC Party.  The flow in BSCP03 3.1.6 has the Registrant being the party to accept or reject data estimates. The IDD should be amended to remove the MOA from this flow.\nThis Change Proposal supersedes NCR 347.","All references are to BSCP 26 v 2.0 1. Paragraph 1.3, second bullet point: change !0 WD to 20 WD 2. Paragraph 1.9, first sentence: change 10 WD to 20 WD 3. Table 3.4, ref. 3.4.1: in \"when\" column change 10 WD to 20 WD 4. Table 3.4, ref. 3.4.2: in \"when\" column change 10 WD to 20 WD","−",null,"ISG","2002-12-01"]
[565,"Inconsistencies within BSCP26","ELEXON","2001-06-01","During the inconsistency checking exercise, inconsistencies in timings were identified between\nthe Code, BSCP 26 and the TAA_URS. The Code specified 20 WD notice for a Site Visit, BSCP\n26 specified 30 WD and the TAA_URS specified 10 WD.\nBSCP 26 was modified (NCR 225) to align it with the TAA_URS (i.e. the Registrant receives 10\nWD notice of a proposed Technical Assurance Visit from the TAA).\nA change request was also raised to remove the 20 WD from the Code and refer all timings to\nthe relevant BSCP. This change request was subject to the consultation process and a\nresponse has been received which stated that the Registrant should get as much time as\npossible to make the necessary arrangements for a sit visit and the timing should not be\nreduced.","This CP supersedes NCR 334. 1. Paragraph 1.3, second bullet point: change !0 WD to 20 WD 2. Paragraph 1.9, first sentence: change 10 WD to 20 WD 3. Table 3.4, ref. 3.4.1: in \"when\" column change 10 WD to 20 WD 4. Table 3.4, ref. 3.4.2: in \"when\" column change 10 WD to 20 WD\nDuring the inconsistency checking exercise, inconsistencies in timings were identified between the Code, BSCP 26 and the TAA_URS. The Code specified 20 WD notice for a Site Visit, BSCP 26 specified 30 WD and the TAA_URS specified 10 WD.","−",null,"ISG","Implemented "]
[564,"Implementation of short codes for dialling of CVA meters","ELEXON","2001-06-01","This CP supersedes NCR 332 IMServ have an agreement with NGC to utilise the NGC CTN to dial up a number of CVA meters.  NGC require IMServ to utilise \"short\" dialling codes in order to restrict access to only allowed numbers on the CTN.  As currently implemented, the CDCA and MV90 databases contain the initial full codes used in order to enable dialling to start for testing and pre-production. \nA change in the CDCA procedures is required to implement short code dialling via a lookup table in MV90,while retaining the long codes for use in testing.","A change in the CDCA procedures is required to implement short code dialling via a lookup table in MV90, while retaining the long codes for use in testing.","−",null,null,"−","Rejected"]
[563,"Inconsistencies in BSCP01 & BSCP03","ELEXON","2001-06-01","Modify BSCP01 and BSCP03 to reflect the fact that CDCA will either obtain actual meter readings\nor provide initial estimates for all missing meter readings by SD+4WD and that the CDCA\nsystem can only run when it has readings for all registered meters. ","This CP supersedes NCR 330\nThe Change Proposal proposes a number of amendments to BSCP01 and BSCP03","−",null,"ISG","2002-08-13"]
[562,"Inconsistencies in the CDCA URS","ELEXON","2001-06-01","This CP supersedes NCR 318.\nSection R, 3.3.1 to 3.3.5 and BSCP75 require the CDCA to perform a series of checks on Aggregation Rules. Currently the URS makes no explicit mention of these rules. This Proposal seeks to incorporate the requirement for these checks in the CDCA URS.","Add a new bullet point to CDCA-F002: ‘6. The CDCA will check all new and modified Aggregation Rules in accordance with the provisions of both Section R, paragraphs 3.3.1 to 3.3.5 of the BSC Code and BSCP75.’","−",null,null,"−","Rejected"]
[561,"Process to Obtain French Interconnector Meter Readings","ELEXON","2001-06-01","This CP supersedes NCR 256 The current CDCA system has no means to process data files from French meters and so a change is required to enable the CDCA to carry out its duties.\nThis proposal sets out recommendations for obtaining meter readings for the French Interconnector, validating them and loading them into CDCA. It will not be possible simply to follow normal CDCA procedures to obtain these meter readings, as a special protocol exists between France and England, which stipulates that meter readings for the interconnector will be provided by RTE using DC meters. These readings will be adjusted for losses by RTE to give a reading at the point where electricity enters the England and Wales system (Sellindge).  These readings will need to be loaded into the CDCA system so that they can be processed for settlement.. A utility programme will be required to process these readings.","RTE will provide a file of readings for each settlement day.","−",null,"ISG","−","Rejected"]
[560,"Handling of BMRA During BM System Operation Outages","ELEXON","2001-05-31","Workaround W023 provides for the BMRA calculations to be switched off when an Outage occurs, and for the BMRA calculations to resume when the Outage is over and the backlog of BM Data has been caught up.","Workaround W023 provides for the BMRA calculations to be switched off when an Outage occurs, and for the BMRA calculations to resume when the Outage is over and the backlog of BM Data has been caught up. See the attached Workaround W023 for a detailed description of the process. Workaround W023 processes will be incorporated into the enduring services for the NETA Central Services and BM System Operation Agents. This Change Proposal extends the scope of the existing Workaround to cover missing data arising from communications failures between NGC and BMRA and any other Outage as defined by BSC Section Q, Paragraph 1.2.1 (c).","−",null,"ISG","2002-08-13"]
[559,"Inclusion of Settlements Run Type Info in Aggregated Reports","ELEXON","2001-05-30","The CDCA produces aggregated data reports for BSC Parties in accordance with the standard Settlements Calendar which specifies up to 6 different runs for each Settlement Date - II, SF, R1, R2, R3 and R4. Reports sent to Parties do not specify which Settlement Run Type applies to the aggregated data received. This makes it difficult for them to identify which report relates to the appropriate run in the Settlements Calendar and can lead to difficulties in understanding and validating NETA Settlements bills over the Settlements Reconciliation cycle.","The data item – Settlement Run Type [N0202] – should be added to CDCA aggregated data reports particularly flows C0301, C0421 and C0291. If a Dispute Run or a Dispute Final Run is completed by the CDCA, the relevant reports should also include a Settlement Run Type for the Dispute Run (DR?) or the Dispute Final run (DF).","−",null,"ISG","2001-12-01"]
[558,"Removal of Support for D0269 & D0270 version 001 dataflows","N/A","2001-05-30","The solution for SIR R1445,\" Inclusion of Meter Timeswitch Codes in Market Domain Data\", proposed that after a period of 12 months after its implementation a further exercise would be undertaken to remove the original versions (Version 001) of the D0269 & D0270 dataflows from the DTC. The new versions (Version 002) of the D0269 and D0270 dataflows were first published in the DTC catalogue version 5.0 on 13th August 1999 (DTC CP3016). SIR R1445 was implemented in Oct 1999. The SVG/02 meeting of 8th May 2001 expressed the view that it was now appropriate to accelerate the withdrawal of support for Version 001 of the D0269 and D0270 dataflows.","Amend the following Configuration Item: • The MDDM system – to remove support for the production and distribution of D0269 and D270 version 001 dataflows in Q1 2002. The target “cut off” date is 1st Jan 2002. This will effect all market participants who currently use these versions of the dataflows. As a consequence, the following additional Configuration Items will be amended: • The NHHDA system – to add support for D0269 version 002 • The ISRA system - to add support for D0269 version 002 • Business Definition Documents (i.e. Data Interfaces and Data Catalogue).","−",null,null,"−","Rejected"]
[557,"Income tax processing within the Funds Transfer System","N/A","2001-05-30","Prior to the NETA Go-live, ELEXON instructed the FAA to remove income tax processing from the Funds Transfer System (FTS2000) as it was not applicable under NETA. Prior to NETA, income tax applied to Reconciliation interest and interest on payments due if billing was late. The FAA have implemented a manual process that results in: • The tax rate being set to zero;  and • References to income tax being removed from the Advice Notes.   This approach is consistent with Inland Revenue instructions. This process was intended to be a workaround only and therefore this CP proposes a FTS2000 system change to enable the removal of income tax information from printed matter as well as facilitating any future income tax changes.\nImplementing this change will ensure that there is no reference to income tax on printed matter which is essential to meet the Inland Revenue requirements in this area","The proposed solution requires changes to the FTS2000 system and may require changes to FAA documentation eg. URS.","−","CPC00226"]
[556,"Participation Capacity Clarification in BSCP65 version 2","ELEXON","2001-05-30","There is inconsistent use of terminology relating to Participation Capacity between BSCP65 4.1, the Code A1.3.1 and CRA URS CRA F001 - all documentation should be aligned. Proposed amendments are detailed in Attachment 1. This Change Proposal has been raised from NCR323 version 2.","BSCP65 Version 2\ni) Form BSCP65/4.1, Party Registration Application / Change of Registration Details Form, to be\nupdated to reflect the Participation Capacity terminology used in the Code, Section A paragraph\n1.3.1.\nii) Update the Route Map to show that DSO, TC and IA register as Parties with the CRA after Accession\nand that the IEA is classified as another Trading Party i.e. one not required to register BM Units and\nmeters but a Party who is allocated Energy Accounts.\nCRA URS Version 2.4\nWhere the CRA URS refers to Participation Capacities the URS needs to be updated to reflect the\nterminology used in the Code, Section A paragraph 1.3.1.","−",null,"ISG","−","Rejected"]
[555,"Amendments to the SAA URS","ELEXON","2001-05-29","This CP has been raised to address inconsistencies identified by the NETA Programme (IRP CP003). A) BSCP301 Section 3.1.6 state that the FAA will produce and distribute the authorised Payment Calendar no later than 31 January. Section I011 of the SAA URS has a date of 30 January. b) BSCP301sections 3.1.7-3.1.13 describes the timetable for the drafting, reviewing and publication of the Payment and Settlement Calendars.  If the maximum time allowance is used, then there is a 22WD gap between the distribution of the Payment Calendar by the FAA on 31 January and the publication of the Settlement Calendar by the SAA.  However, the functional requirement SAA-F001 demands that the Settlement Calendar be published by 14 February, even though the Calendar may still be under review. \nc) Section SAA-I006 of the SAA URS uses the old terminology of \"Interconnector Deemed Metered Accounts\" instead of \"BM Unit.","CP0555 has been raised to address inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELEXON (IRP CP003).","−",null,"ISG","2002-08-01"]
[554,"Amendments to BSCP301","ELEXON","2001-05-29","This CP supersedes NCR322 and addresses inconsistencies initially identified by the NETA Programme and subsequently reviewed by ELELXON (IRP CP001). a) BSC section N 8.7.1 states that “Any amounts standing to the credit of Clearing Account at the close of business on any Payment Date shall be transferred to the Reserve Account so that the balance in the Clearing Account at the end of such day will be nil.” This process is not covered in BSCP301. b) EPFAL IDD FAA-I010 requires the Quarterly Statement to be sent to Parties and Customs & Excise for VAT purposes, the BSCP 301 only has the flow being sent to Parties. \nc) BSC Section N 6.6.1 (b) lists the Panel as a recipient of a notification to postpone a Payment Date. This is not reflected in BSCP301.","CP0554 has been raised to progress NSC322 and to address inconsistencies initially identified by\nthe NETA Programme and subsequently reviewed by ELELXON (IRP CP001).","−",null,"ISG","2001-08-12"]
[553,"Amendments to FAA URS","ELEXON","2001-05-29","NETA Programme identified inconsistencies (IPR CP005).","This CP has been raised to address inconsistencies identified by the NETA Programme. (IPR CP005).","−","CPC00226",null,"2001-04-26"]
[552,"Enduring Process to replace W016 - CRA Registration Details",null,"2001-05-29","CRA-I020 is sent from the CRA to ELEXON and the SO but has been interpreted differently by the two participants. ELEXON are unable to use the interface in its current format. The BM Unit Effective dates in CRA-I020 relate to the BM Unit and all associated parameters. ELEXON require the effective from and to dates of the BM Unit as a whole, i.e. the registration and de-registration dates.",null,"−",null,null,"−","Rejected"]
[551,"Enduring Process to replace W006 - P0181 flow to SVAA","ELEXON","2001-05-29","CRA-I015 sub-flow 2 (known in Stage 2 as 'P0181') sent from the CRA to SVAA, is used to generate MDD for Stage 2 participants. SVAA expects a full refresh of this data every time it changes.  The way in which the file is currently being produced makes it unsuitable for use in generating MDD. In fact, use of the flow in its current format would make it impossible to perform Reconciliation runs in Stage 2.","Rename existing CRA-I020 to ‘CRA-I020 sub-flow 1’ and change it so that it is sent to SO only (and not to ELEXON). Create a new Flow CRA-I020 sub-flow 2 which will be sent to ELEXON only.\nCRA-I020 sub-flow 2 will be the same as CRA-I020 sub-flow 1, except for the following:\nIn the ‘BM Unit Registration’ group, include ‘Effective From’ and ‘Effective To’ dates that relate to the\nBM Unit as a whole, i.e. the registration and deregistration of the BM Unit, and not any parameters for the BM Unit. In addition, include the CALF value associated with the BM Unit within the BM Unit\nRegistration Group and the Trading Unit to which the BM Unit is currently assigned. All BM Units that have been updated need to be included in this flow. The following data should therefore be in the flow for all relevant BM Units (one record for each BM Unit):","−","CPC00226",null,null,"Closed"]
[550,"Addition of Authentication Processes in BSCP38","ELEXON","2001-05-25","There are a number of circumstances where participants will need to request rapid changes to the configuration parameters of the NETA Central Systems to enable them to recover from operational problems. Currently, there is no formal authentication process associated with these requests in BSCP38.","Include authorisation process in BSCP38.","−",null,"ISG","−","Rejected"]
[549,"Display duration of BMRA System Warning Messages","ELEXON","2001-05-25","Currently System Warning messages are displayed on the BMRA for 24 hours. In some cases, this means that a message warning of an NGC Outage can be displayed and then withdrawn from display before it has been seen by BMRA service users. This CP supersedes NCR 369.","System Warning messages should be displayed on the BMRA service for 7 consecutive calendar days instead of one.","−",null,"ISG","2002-08-13"]
[548,"Default Values and Effective Dates for  Line Loss Factors","ELEXON","2001-05-25","For existing CVA Metering Systems where previously approved LLFs have expired and no new ones have been approved, BSCP28 currently states that a value of 1.00 shall be applied as a default value. The proposed change is that the default values should be the continued use of the current approved LLFs. In addition BSCP28 states that LLFs may have an effective (from) date prior to the date of approval (by the Panel). It is proposed that LLFs cannot have an effective date prior to the date of approval (i.e. no retrospective application).","For existing CVA Metering Systems where previously approved Line Loss Factors (LLFs) have expired and no new ones have been approved, BSCP28 currently states that a value of 1.00 shall be applied as a default value. The proposed change is that the default values should be the continued use of the current approved LLFs.","−",null,null,"2002-08-13"]
[547,"ECVNA and MVRNA Registration, Authorisation and Termination","ELEXON","2001-05-25","Forms F71/01 & 02 in BSCP71, ECVNA and MVRNA Registration, Authorisation and Termination, should have each authorisation section on a separate page.  In addition each party i.e. ECVNA / MVRNA, Party 1 and Party 2 need to have a field for a signature and password. Sections 3.1 and 3.2 under METHOD to be expanded to stipulate that the original will follow by post. Having the 3 authorisation sections on separate pages will ensure that Party 1 and 2 do not have access to the other Party's signature and password it is assumed that the Party Agent / Party contract will cover confidentiality in relation to the disclosure of passwords and signatures to the ECVNA / MVRNA. Passwords have been added, as the Logica authorisation process requires passwords for verification. Concern was raised at signatures being fax and how legible they would be; therefore originals will follow the faxed version by post.","Forms F71/01 & 02 in BSCP71, ECVNA and MVRNA Registration, Authorisation and Termination, should have each authorisation section on a separate page. In addition each party i.e. ECVNA / MVRNA, Party 1 and Party 2 need to have a field for a signature and password.","−",null,null,"2002-08-13"]
[546,"Enduring Solution to replace NETA Workaround 001","ELEXON","2001-05-25","Workaround 001 was implemented to address the differences between the BSCP forms and the formats/screens developed by Logica / IMServ for processing the BSCP forms submitted by Parties and Party Agents. The enduring solution will ensure that configured items, BSCP Forms, Logica IDD & systems are aligned and that issues identified by Logica / IMServ in processing the forms have been addressed. The issue described above needs to be resolved by a review being undertaken of the BSCP's, the system requirements and the IDD.  For each anomaly, a decision will be required as to the most appropriate product to update (BSCP, System or IDD). This CP supersedes NCR333 version 2.","The specific problems encountered by Logica/IMServ will be addressed by altering the BSCPs, and in particular the BSCP Forms.","−",null,null,"Implemented "]
[545,"BSCP07:  Standing Data Changes - Consultation comments","ELEXON","2001-05-25","See the solution description. ","A number of changes are proposed to BSCP07.","−",null,null,"Implemented "]
[544,"Notification and Sealing of Metering Equipment for CVA","ELEXON","2001-05-25","Section 4.2: A caveat similar to that in BSCP05 should be added.  This states: \"The Universal Meter Reading Sheet is an example meter reading sheet.  Different meter reading sheets may be used as long as they contain the same information.\" Comments received from Scottish Power during BSCP consultation on Version 1.1, changes omitted from Version 2, it was agreed with Scottish Power that comments would be included when the procedure is next updated. Add explanatory text to BSCP06.","Add explanatory text to BSCP 06.","−",null,null,"−","Rejected"]
[543,"BMRA Browser Support","ELEXON","2001-05-25","This CP supersedes NCR286. Test the BMRA service against later versions of Microsoft Internet Explorer (IE) and Netscape. Implement any necessary changes to enable the service to work against these browser versions. Update the BMRA help text to reflect the support for these versions. The BMRA service is available over the public internet and it is not possible to place undue restrictions on the browsers to be supported for members of the public. The only currently supported browser for the BMRA is Internet Explorer Version 4. The latest available version is 5.5 and participants may not be able to legitimately source new copies of version 4.\nMany participants may have corporate standards mandating the use of up-to-date versions of web browsers and BMRA is required to function and be supported in these environments.","Test the BMRA service against later versions of Microsoft Internet Explorer (IE) and Netscape. Implement any necessary changes to enable the service to work against these browser versions. Update the BMRA help text to reflect the support for these versions.","−",null,null,"Implemented "]
[542,"BSCP65 - MDD Updates:  Supplier Stops Trading",null,"2001-05-24","As a result of the \"Supplier Stops Trading\" walkthrough on 23 February 2001, it was agreed that a new step 3.2.7 should be incorporated into BSCP65 \"Registration of Parties and Exit Procedures\", to ensure that when a Party changes their participation capacity from that of a Supplier they should be required to update Market Domain Data, via BSCP509 \"Changes to Market Domain Data\".","See the description of the issue. ","−",null,null,"−","Rejected"]
[541,"Changes to BMCAEC/BMCAIC","ELEXON","2001-05-23","Section M 1.2.4 of the BSC states that any change to the BM Unit Credit Assessment Export or Import Capability for a BM Unit should result in the re-determination of Energy Indebtedness for the associated Trading Party(s), as if the change were in effect from the first of the 29 days used in the calculation of Energy Indebtedness. \nHowever, the current ECVAA functionality does not apply the amended BMCAEC/BMCAIC values retrospectively in the Energy Indebtedness calculations. Therefore the functionality requires amendment.","The required amendment to functionality is that only where ELEXON determine that retrospective application of revised values of BMCAEC / BMCAIC is required, that: • Manual notification is provided by ELEXON to ECVAA that the revised values of BMCAEC / BMCAIC, are to be applied to from the ‘ECVAA effective date’ specified by ELEXON. This date is the effective date that the revised values should be applied in Energy Indebtedness calculations for the relevant Trading Party(s).","−",null,null,"−","Rejected"]
[540,"Adequate ECVAA Delay Functionality","ELEXON","2001-05-23","The ECVAA Credit Checking delay functionality should be amended to reflect the enduring requirements of the Balancing and Settlement Code Section M 3.3.5 and 3.3.6 (b). This CP has been raised from NCR342 The BSC defines the Credit Default Refusal Periods and Credit Default Rejection Periods as not commencing until Credit Checking for the associated Settlement Periods has completed where there is a delay to the ECVAA Credit Checking processing.  Therefore this requirement should be reflected in ECVAA functionality.\nThe ECVAA delay handling process is currently not operating in accordance with the enduring process as defined in the Balancing and Settlement Code Section M 3.3.5 and 3.3.6 (b) due to the Suspension Period (BSC Section E). The current operation is defined in BSC Section M 3.3.8 and is required to be superseded by enduring functionality under BSC Section E.","The BSC defines the Credit Default Refusal Periods and Credit Default Rejection Periods as not commencing until Credit Checking for the associated Settlement Periods has completed where there is a delay to the ECVAA Credit Checking processing. Therefore this requirement should be reflected in ECVAA functionality.","−",null,null,"Implemented "]
[539,"Disregard Historic ECV Data for on the Day ECVNs","ELEXON","2001-05-23","Energy Contract Volumes within Energy Contract Volume Notifications and Metered Volume Reallocations within Metered Volume Reallocation Notifications, pertaining to Settlement Periods for which Gate Closure has already occurred should be disregarded by ECVAA when processing such Notifications. This CP was raised from NCR345","For Energy Contract Volume Notifications (regardless of whether they are additive or overwrite) covering a single day – i.e. the Effective from Date is the same as the Effective to Date, Energy Contract Volumes within that Notification which pertain to Settlement Periods for which Gate Closure has already passed will be disregarded by ECVAA. For Metered Volume Reallocation Notifications (regardless of whether they are additive or overwrite) covering a single day – i.e. the Effective from Date is the same as the Effective to Date, Metered Volume Reallocations within that Notification which pertain to Settlement Periods for which Gate Closure has already passed will be disregarded by ECVAA. This should be the case for all such Notifications, i.e. this is not Participant specific, nor will there be a functionality to enable ‘opting’ out by specific Participants. There will not be a specific confirmation to the ECVNA (or Counterparties), nor to the MVRNA (or Lead / Subsidiary Party) that such data has been disregarded. It should be noted that this is an interim solution to the issue of Historic Overwrite and that this change may be superseded in the longer term by the enduring solution.","−",null,null,"Implemented "]
[538,"Release 2 of the New Electricity Arrangements","Trading Development","2001-05-23","At NETA Go-live on 27 March a number of non-essential NETA Change Requests (NCRs) were outstanding, many of which had been designated \"for implementation within 6 months of Go-live\" by the NETA Programme. In addition, a number of Operational Improvements have been identified since Go-live that need to be addressed. Release 2 of the New Electricity Arrangements Project will address both of these requirements.\nThis Project may also include the implementation of CPs raised from any Proposed Modifications that have been authorised by the Modifications Panel.","The scope of the Project will comprise amendments to NETA Services Software, especially ECVAA, Code-subsidiary legal framework documents and NETA Business Definition documents.","−",null,null,"−","Rejected"]
[537,"BMRA Reporting of Historic Market Data","ELEXON","2001-05-23","Add 2 new reports to the BMRA website: 1. Historic Market Depth Data.  A facility to view, in a single table, the data currently displayed under Market depth for historic Settlement dates. 2. Historic Market Activity Data. A facility to view, in a single table, the data for Accepted Bids and Offers submitted across all BM Units that affect a particular historic Settlement Period.","The scope of the Project will comprise amendments to NETA Services Software, especially ECVAA, Code-subsidiary legal framework documents and NETA Business Definition documents.","−",{"$nulls":3},"Rejected"]
[536,"Parameters for Automatically Generated BM Units","ELEXON","2001-05-22","The Party Applicant provides their registration details to both the CRA and BSCC Ltd (BSCP65, step 3.1.3, CRA-I001.  However this information is not sufficient to register the associated BM Units.  The following data items are required by CRA for the BM Units to be created and should be provided by BSCC Ltd: Transmission Loss Factor (TLF)· Credit Assessment Load Factor (CALF) However, the only information provided by BSCC Ltd to the CRA is accession details (BSCP65 step 3.1.6) and notification/authorisation of the new Supplier (BSCP65 step 3.1.11, BSCP15 step 3.3.1), neither of which include the above data items. This CP supersedes NCR394.","Modify the functional requirements in the CRA URS, such that on registration of supplier, the CRA sends a list of the newly registered BM Units to BSCC Ltd. and that BSCC Ltd. responds with the parameters required by the CRA, by creating two new flows.","−",null,null,"−","Rejected"]
[535,"ECVAA Functionality for MVRNA and ECVNA Authorisations","ELEXON","2001-05-22","ECVAA currently validates MVRNA and ECVNA Authorisations on a ‘date of receipt’ basis, rather than on an ‘affectivity basis. This validation is not in accordance with the relevant Section of the Balancing and Settlement Code (Section P 2.1.2, 3.1.2) and therefore the ECVAA System validation criteria should be amended to reflect the requirements of the BSC. This is a defect in the ECVAA software. This CP has been raised from NCR393","As ECVAA is not validating Notification Agent Authorisation Requests in accordance with the requirements defined within the Balancing and Settlement Code, it is proposed that ECVAA system validation functionality on receipt of both ECVNA and MVRNA Authorisation requests be amended to reflect the BSC requirements, i.e. to be based on Effective Dates, as specified in the Balancing and Settlement Code.","−",null,null,"−","Rejected"]
[534,"Disregard Contract Trading Party during Credit Checking","ELEXON","2001-05-22","This CP supersedes NCR391. The Transmission Company acting as a Contract Trading Party is not required to lodge credit cover with the FAA. ECVAA does however include the Transmission Company in the credit checking process. The ECVAA system credit checking process functionality needs to be amended to exclude the Transmission Company from the Indebtedness calculations. This functionality amendment may require associated amendment to the ECVAA specification documentation and Operational documentation.","The ECVAA system credit checking process functionality needs to be amended to exclude the Transmission Company from the Indebtedness calculations. This functionality amendment may require associated amendment to the ECVAA specification documentation and Operational documentation. It should be noted that in the interim, Workaround W019 is in place to ensure that whilst the Transmission Company is included in the Indebtedness calculations, that it does not breach its credit limit.","−",null,null,"−","Rejected"]
[533,"Clarification of methods for requesting reports under BSCP41","ELEXON","2001-05-22","Changes to BSCP41 to clarify the process for requesting reports and publication of an updated list of available reports. This Change Proposal replaces NCR363","Currently there are two methods for requesting reports under BSCP41; firstly to request reports defined as being available to “Any Party on Request” and secondly confidential reports i.e. reports classified as being available to the “Relevant Party”. To clarify the process it is proposed that the procedure is broken down into 3 areas:\n1) Amendments to a Parties or Party Agents Standard Reports; 2) Reports Available to “Any Party on Request”; 3) “Relevant Party” Reports Made Available to Another Party.","−",null,null,"−","Rejected"]
[532,"SAA-I014: Denominator Value in Residual Cashflow Reallocation","ELEXON","2001-05-22","The Total System Period Credited Energy Volume data item (N0229) in SAA-I014 was originally intended to report on the denominator value of the Residual Cashflow Reallocation Proportion (RCRP) calculation. The denominator value has subsequently been changed and incorporated in the relevant SAA system calculation. However, the change has not been made to the data item in the relevant data flow and therefore the SAA-I014 does not contain the requisite denominator value. This CP supersedes NCR352","A consultation exercise in January 2001, determined that the preferred resolution was the replacement of the data item. Therefore it is proposed that the Total System Period Credited Energy Volume (Σia QCEiaj) data item be replaced accordingly: A new data item should be created for the newly calculated denominator value, i.e. Data Item ‘RCRP Denominator Value’, calculated as Σa {Σ+ i (QCEaij) + Σ- i (–QCEaij)}. This new data item should replace Data item N0229 (Total System Period Credited Energy Volume) in Group SSD ‘System period Data’ in all variations of the SAA-I014 report (i.e. all subflows).","−",null,null,"Implemented "]
[531,"Incorrect Reference in BSCP 507","ELEXON","2001-05-22","There is a discrepancy in BSCP507. Section 3.1 of BSCP 507 refers to the Supplier Volume Allocation System - Supplier/Supplier Agent Standing Data Change Form as BSCP507/01, however, section 4.2 of the BSCP has this form erroneously labelled as BSCP507/012. This CP has been raised from NCR346.","Section 4.2 should be amended accordingly to read BSCP507/01 with reference to the Supplier Volume Allocation System – Supplier / Supplier Agent Standing Data Change Form.","−",null,null,"−","Rejected"]
[530,"Reporting of CALF Values to ELEXON","ELEXON","2001-05-22","BSCC do not currently receive CALF values back from the CRA, after they have been submitted.  Therefore the BSCC cannot confirm that the CALF values provided have been registered correctly by the CRA.   This increases the risk that an error in process of registering a CALF value in CRA will not be detected. Modify Flow CRA-I020 (R0201), which is sent to BSCC Ltd and the SO, as follows: in group 'BM Unit Registration' (BR3), add data item 'Credit Assessment Loss Factor', mandatory, at the end of the group. To uphold the integrity of Settlements. This CP has been raised to supersede NCR341.","Modify Flow CRA-I020 (R0201), which is sent to BSCC Ltd and the SO, as follows: In group ‘BM Unit Registration’ (BR3), add data item ‘Credit Assessment Loss Factor’, mandatory, at the end of the group.","−",null,null,"−","Rejected"]
[529,"Entry of Negative CALF Values into CRA","ELEXON","2001-05-22","Currently the screen used by the Logica Consortium does not allow for negative CALF values to be entered into CRA, even though negative CALF values may be received from ELEXON.  If this change is not made, the operator will not be able to record the correct CALF value for BM Units with a negative CALF value.  This will mean that the CRA will report incorrect CALF values for these BM Units and calculate incorrectly their BM Unit Credit Assessment Import and Export Capabilities (BMCAICs and BMCAECs), which are issued to the SAA and ECVAA. Also, the diagram on page 73 of the CRA URS is not consistent with the table on page 72. This CP supersedes NCR337","1. Modify the screen used by the operator in the CRA for entering/changing Credit Allocation Load Factor (CALF) values so that negative values are permitted. 2. Furthermore, the User Requirement Specification of CRA(v2.2) should changed as follows: • Diagram on page 73, replace “SO (NGC)” (box on LHS) with “BSCCo Ltd”.","−",null,null,"Implemented "]
[528,"Inconsistency between BSCP15 and BSCP508","ELEXON","2001-05-22","Testing Problem Report PR0783 identified a discrepancy between BSCP15 and BSCP508: BSCP15 Section 3.5.5 states 'Where the BM Unit is an additional Supplier GSP Group BM Unit the CDCA shall notify the SVAA of the BM Unit' The flow is shown as being from CRA to SVAA. BSCP508 Section 3.10.1 states that CRA shall send BM Unit Data to MDDM. Investigation has shown that BSCP508 is correct in this respect and hence BSCP15 should be modified. This CP supersedes NCR331.","Modify BSCP15 in the following manner: 1. Modify the descriptive text of section 3.5.5 to replace ‘CDCA’ with ‘CRA’ 2. Modify the flow recipient from ‘SVAA’ to ‘MDDM’.","−",null,null,"Implemented "]
[527,"IDD Part 1 -  Documentation Errors and Inconsistencies","ELEXON","2001-05-22","14 documentation errors and inconsistencies have been identified in the IDD document and spreadsheet – Part 1.","Changes should be made to Part 1 of the IDD.","−",null,null,"Implemented "]
[526,"To bring Method of Communication required in line with IDD","ELEXON","2001-05-22","To bring the “METHOD” columns of the BSCPs identified in line with the IDD. This will further resolve issues 140 (PR 890 and PR 892) and 147 (PR 851), and will allow for daily (and other) reports to be used as acknowledgements.","To ensure the “METHOD” column reflects that methodology referenced in the IDD. These\nchanges are seen as non-urgent and will not impact the operation of these procedures.\nUpdate BSCP31: Registration details are submitted by BSCCo to CRA and Party via\nFax/Letter, step 3.1.10, needs to be amended to include electronic.\nUpdate BSCP31: De-registration details are submitted by BSCCo to CRA and Party via\nFax/Letter, step 3.2.3, needs to be amended to include electronic.\nUpdate BSCP31: De-registration details are sent out by CRA to BSCCo and Applicant,\nstep","−",null,null,"−","Withdraw"]
[525,"To bring Method of Communication required in line with IDD","ELEXON","2001-05-22","To bring the “METHOD” columns of the BSCPs identified in line with the IDD. This will further resolve issues 140 (PR 890 and PR 892) and 147 (PR 851), and will allow for daily (and other) reports to be used as acknowledgements.  A document is attached that details these acknowledgements. To ensure the “METHOD” column reflects that methodology referenced in the IDD.  These changes are seen as non-urgent and will not impact the operation of these procedures. BSCP20: Step 3.1.1 to be amended to include “Electronic”. So that the NETA IDD and the Code Subsidiary documents are consistent","To ensure the “METHOD” column reflects that methodology referenced in the IDD. These changes are seen as non-urgent and will not impact the operation of these procedures. BSCP20: Step 3.1.1 to be amended to include “Electronic”.","−",null,null,"−","Withdraw"]
[524,"To bring Method of Communication required in line with IDD","ELEXON","2001-05-22","To bring the “METHOD” columns of the BSCPs identified in line with the IDD. This will further resolve issues 140 (PR 890 and PR 892) and 147 (PR 851), and will allow for daily (and other) reports to be used as acknowledgements.  A document is attached that details these acknowledgements. To ensure the “METHOD” column reflects that methodology referenced in the IDD.  These changes are seen as non-urgent and will not impact the operation of these procedures. Update BSCP15: Step 3.1.6 remove reference to fax. Update BSCP15: Step 3.5.4 remove reference to fax. Update BSCP15: Step 3.6.4 remove reference to fax from step 3.6.3. Update BSCP15: Step 3.7.3 remove reference to fax/post. So that the NETA IDD and the Code Subsidiary documents are consistent","To ensure the “METHOD” column reflects that methodology referenced in the IDD. These changes are seen as non-urgent and will not impact the operation of these procedures. Update BSCP15: Step 3.1.6 remove reference to fax. Update BSCP15: Step 3.5.4 remove reference to fax. Update BSCP15: Step 3.6.4 remove reference to fax from step 3.6.3. Update BSCP15: Step 3.7.3 remove reference to fax/post.","−",null,null,"−","Withdraw"]
[523,"To bring Method of Communication required in line with IDD","ELEXON","2001-05-22","To bring the “METHOD” columns of the BSCPs identified in line with the IDD. This will further resolve issues 140 (PR 890 and PR 892) and 147 (PR 851), and will allow for daily (and other) reports to be used as acknowledgements.  A document is attached that details these acknowledgements. To ensure the “METHOD” column reflects that methodology referenced in the IDD.  These changes are seen as non-urgent and will not impact the operation of these procedures. Update BSCP07: Step 3.3.1 to be amended to include “Electronic”. Update BSCP07: Step 3.1.3 to be amended to remove “Originator”, as this step is ‘Internal’","To ensure the “METHOD” column reflects that methodology referenced in the IDD. These changes are seen as non-urgent and will not impact the operation of these procedures. Update BSCP07: Step 3.3.1 to be amended to include “Electronic”. Update BSCP07: Step 3.1.3 to be amended to remove “Originator”, as this step is ‘Internal’","−",null,null,"−","Withdraw"]
[522,"To bring Method of Communication required in line with IDD","ELEXON","2001-05-22","To bring the “METHOD” columns of the BSCPs identified in line with the IDD. This will further resolve issues 140 (PR 890 and PR 892) and 147 (PR 851), and will allow for daily (and other) reports to be used as acknowledgements.  A document is attached that details these acknowledgements. This CP has been raised to supersede NCR304 To ensure the “METHOD” column reflects that methodology referenced in the IDD.  These changes are seen as non-urgent and will not impact the operation of these procedures. Update BSCP28: remove reference to “Electronic” in step 3.1.9. So that the NETA IDD and the Code Subsidiary documents are consistent.","To ensure the “METHOD” column reflects that methodology referenced in the IDD. These changes are seen as non-urgent and will not impact the operation of these procedures. Update BSCP28 : remove reference to “Electronic” in step 3.1.9.","−",null,null,"−","Withdraw"]
[521,"Inconsistencies between BSCPs and  IDD","ELEXON","2001-05-22","To bring the “METHOD” columns of the BSCPs identified in line with the IDD.\nThis will further resolve issues 140 (PR 890 and PR 892) and 147 (PR 851), and will allow\nfor daily (and other) reports to be used as acknowledgements. ","3.2.4, needs to be amended to include electronic.","−",null,null,"Implemented "]
[520,"Credit Level Naming Inconsistency","ELEXON","2001-05-22","Resolve the inconsistency on the Credit Level naming convention between the ECVAA specifications/software and the Balancing and Settlement Code. The ECVAA system functionality should be amended to report a Level 1 credit default on breach of 80% Indebtedness and a Level 2 Credit Default on breach of 90% Indebtedness for a Participant. The ECVAA Specifications should be amended where appropriate to reflect this functionality and reporting change. The Balancing and Settlement Code Section M 3.2.1 states that a Level 1 Credit Default occurs when a Participant goes above 80% Indebtedness, Section M 3.3.1 states that a Level 2 Credit Default occurs when a Participant goes above 90% Indebtedness. The ECVAA System Specification (Issue 3.4 section 4.3) states that an ‘Indebtedness Level 1’ occurs when the Participant goes above 90%. The specification also refers to a ‘Level 2 system parameter","The ECVAA system functionality should be amended to report a Level 1 credit default on breach of 80% Indebtedness and a Level 2 Credit Default on breach of 90% Indebtedness for a Participant. The ECVAA Specifications should be amended where appropriate to reflect this functionality and reporting change.","−",null,null,"−","Rejected"]
[519,"Calculation by the ECVAA of a Trading Party’s ‘MEA’","ELEXON","2001-05-22","The ECVAA URS currently does not contain functionality required to meet the BSC obligations/functionality around the area of reducing credit cover. A modification to the Code has been progressed and implemented to reflect this. Therefore the ECVAA system functionality, associated specification documentation and affected Operational documentation (such as Operational Service Manuals) should be amended to reference the processing / functionality required to conform to the Balancing and Settlement Code.","CP0519 proposes amendments to the ECVAA system functionality, associated specification documentation and Operational documentation to support the amendment required to conform with the Balancing and Settlement Code obligations. It should be noted that there is a Workaround in place to enable conformance to Section M2.3 of the Balancing and Settlement Code, which should remain in place until this change is implemented.","−",null,null,"Implemented "]
[518,"Enhancements to the Non Half Hourly Balancing Mechanism","ELEXON","2001-05-22","This NCR proposes changes to process 2.2/3.2 “Non Half Hourly Balancing Mechanism Unit Standing Data Changes” which was introduced into BSCP507 “Stage 2 Settlement Standing Data Changes” for use by those Suppliers wishing to allocate Non Half Hourly (NHH) consumption to Balancing Mechanism (BM) Unit(s).","This CP proposes changes to process 2.2/3.2 \"Non Half Hourly Balancing Mechanism Unit Standing Data Changes\" which was introduced into BSCP507 \"Stage 2 Settlement Standing Data Changes\" for use by those Suppliers wishing to allocate Non Half Hourly (NHH) consumption to Balancing Mechanism (BM) Unit(s).","−","CPC00210",null,"Implemented "]
[517,"Multiple Ad-hoc runs to Settle Disputes","ELEXON","2001-05-22","In accordance with section W of the BSC, the facility is required to settle disputes through multiple ad-hoc runs, for a particular Settlement Date, both within the fourteen month period (pre-final Settlement) and beyond that up to a cut off point of three years (post-final Settlement).","An additional set of codes are required to represent the ad-hoc runs. The proposed codes\nwill primarily be used by the SAA and FAA systems, although they could be used by other\nBSC Parties, BSC Agents and Party Agents.","−",null,null,"−","Rejected"]
[516,"Amend EAC/AA Logical Design for the EAC/AA Release 7 Project","N/A","2001-05-18","The EAC/AA logical Design should be amended to ensure consistency with the changes to the EAC/AA software delivered for the EAC/AA Release 7 Project","See the description of the issue. ","−"]
[515,"Additional error handling for tolerance values","N/A","2001-05-18","Additional error handling for tolerance values","See the description of the issue. ","−"]
[514,"Amend EAC/AA System Management Guide for EAC/AA Release 7","N/A","2001-05-18","The EAC/AA system Management Guide should be amended to ensure consistency with the changes to the EAC/AA software delivered for the EAC/AA Release 7 Project.","See the description of the issue. ","−"]
[513,"Amend EAC/AA Operations guide for the EAC/AARelease7 project","N/A","2001-05-18","The EAC/AA Operations Guide should be amended to ensure consistency with the changes to the EAC/AA software delivered for the EAC/AA Release 7 Project.","See the description of the issue. ","−"]
[512,"Amend the EAC/AA s/w for upgrade to Oracle 8i","N/A","2001-05-18","Amend the EAC/AA s/w for upgrade to Oracle 8i (Relating to CR3000)","See the description of the issue. ","−"]
[511,"CVA Meter Status Reports","ELEXON","2001-05-11","Extend the IDD to include a new flow \"CVA Meter Status Reports\", sent from the CDCA to CVA Meter Operator Agents and Registrants.  The new data flow will provide a succinct summary of any potential faults with the metering equipment, similar to the Meter Status Reports provided by Logica ESIS prior to NETA, but enhanced to include a warning if the data collected from the primary and secondary data collectors disagree. This information is a requirement of BSCP 03 which is not currently met.","New data flow from CDCA to MOA and BSC Party (Registrant) providing details of any metering equipment where the data indicates a potential problem as detailed in BSCP 03 Section 1.6. i.e.. New data flow from CDCA to MOA and BSC Party (Registrant) providing details of any metering\nequipment where the data indicates a potential problem as detailed in BSCP 03 Section 1.6. i.e..","−",null,null,"Implemented "]
[510,"SAA and BMRA System Sell and Buy Price Default Rules","ELEXON","2001-05-09","The SAA and BMRA functionality for calculating System Sell Price and System Buy Price under default circumstances needs to be amended to conform to the defaulting rules defined in Section T of the Balancing and Settlement Code.","The system functionality within both BMRA and SAA should be amended with regards to the calculation of the System Buy and System Sell Prices under default circumstances by the provision of the requisite software functionality.","−",null,null,"2001-04-26","Approve"]
[509,"BSCP68 - Removal of Metering System Transfer restrictions","ELEXON","2001-05-04","ELEXON required to remove of Metering System Transfer restrictions. ","Proposed removal of restrictions in BSCP68 Section 1.1, which preclude SVA trading Suppliers from transferring the export from Third Party Generating Plant to the CVA trading arrangements. Amend BSCP68 Section 1.1 to remove the absolute restriction on the transfer of Third Party Generating Plant from SVA to CVA for Suppliers trading in SVA. Because of the manual nature of the process it is intended to limit the volume of \"Transfers in progress\" at any one time to: (a) no more than FIVE Transfers per Registrant; and (b) no more than TWENTY Transfers per SMRA. SVA Suppliers have claimed that they are disadvantaged by the current restrictions. There are no such restrictions contained within the Balancing and Settlement Code","−",null,null,"Implemented "]
[508,"Submission of registration details changes to BSCCo","ELEXON","2001-05-01","Under BSCP 65 section 3.2, a Party wishing to change registration details requests permission to do so from ELEXON before submitting BSCP 65 form 4.1 directly to CRA. The CRA are then required to check the data with ELEXON. The changes firstly remove the redundant step of applying to ELEXON for a form and secondly to insert a step requiring ELEXON to confirm that the changes can go ahead.","Change BSCP 65 section 3.2: a) Delete the first two steps of the process, that is: Party requests form from ELEXON; ELEXON send s form to Party. b) Add a new step: On receiving information on the change from the CRA, ELEXON confirms that the change is consistent with ELEXON’s knowledge of the Party’s circumstances and authorises the change.","−"]
[507,"Submission of registration details changes to BSCCo","ELEXON","2001-04-26","Under BSCP 65 section 3.2, a Party wishing to change registration details requests permission to do so from ELEXON before submitting BSCP 65 form 4.1 directly to CRA. The CRA are then required to confirm the validity of the change with ELEXON. These changes of registration data must come to BSCCo first before going to CRA.","Change BSCP 65 to reflect the new route.","−",null,null,"−","Rejected"]
[506,"Incorrect estimated settlement data","ELEXON","2001-04-23","Where an Outage occurs at NGC (either planned or unplanned), the latest received FPNs and BOD received will continue to be used as default by NGC and passed to BMRA, while Bid-Offer Acceptances will be taken by phone and recorded manually for subsequent use. The settlement calculations in BMRA and SAA will not operate correctly without Bid-Offer Acceptance data, resulting in incorrect estimated settlement data being reported by BMRA during NGC outages. Users of the BMRA service will be unaware that the data reported by the BMRA service is incorrect, although a warning message may be issued via BMRA for planned outages.","W023 under development as temporary workaround. Enduring solution to be determined.","−",null,null,"−","Rejected"]
[505,"Changes to the NGC BSAD Methodology Statement for Mod P3","ELEXON","2001-04-23","The new BSAD methodology requires additional information from the energy imbalance price calculation. To enable the cost of option fees paid by NGC to be reflected as a 'price adder', Price Cost Adjustments will be amended. W024 Assist ref 1008.","CP0505 proposes changes to the NGC BSAD Methodology Statement for Mod P3.","−",null,null,"−","Rejected"]
[504,"Logging Application","ELEXON","2001-12-23","This was done as an emergency fix. As a result of a defect identified during NETA Pre-Production Running an emergency fix will be applied later today to the Logging software. The defect affected Market Indicator Reports P0046001 and P0049001, as supplied to the PARMS team at ELEXON, and concerned the processing of null values in the BM Unit ID field of record type SPC, file type L022. ","The software skipped to the next field and treated that as the BM Unit ID, rather than accepting a null value. There has been no impact to any live reports. The software has been amended by the SVA Agent and tested and ELEXON have confirmed that the repeated PPR results have corrected the problem. This patch will take the Logging Application from V1.91 toV1.92.","−",null,null,"2001-04-20","Approve"]
[503,"Ability to change registration details for Party Agents","ELEXON","2001-04-18","The current version of BSCP71 allows for ECVNA or MVRNA to register in the first instance. It does not, however, allow for change of details or for de-registration. There is currently no process for changing registration details for ECVNA or MVRNA. One is required to support normal market activity.","CP0503 proposes to: add a process to BSCP71 to recognise registration changes; to allow de-registration as a sub-activity of registration change (by setting a particular effective to date.); and to provide a modified registration form which will allow appropriate information to be captured.","−",null,null,"2002-08-01","Approve"]
[502,"Correction of qualification procedures","ELEXON","2001-04-18","The qualification process as described in BSCP65, BSCP71 and BSCP531 assumes that the testing organisation is responsible for making a statement about the qualification status of the Party or Party Agent being tested. These BSCPs were written in advance of arranging the actual process and there is now a significant discrepancy between the process currently described and the process in use. In particular, ELEXON is responsible for making the statement about qualification status, based on tests done or waivers requested. ","This solution recognises that the new process description is longer than that which appeared in BSCP 65, BSCP71 and BSCP 531, and more forms are involved. The proposal is: 1. To create a new BSCP to capture the qualification process. This will address: arranging for tests to be carried out; accepting waiver requests; and reporting of qualification status. A number of new forms will be introduced. 2. To replace all references to qualification in BSCP65, BSCP71 and BSCP531 with a reference to the new BSCP. 3. To change the Communication Requirements Document to recognise the level of evidence reporting required by the process.","SVG: 36","CPC00395","SVG","Nov 04 Release","Approve"]
[501,"Alignment of NETA Business Process Model with baseline 3.2","ELEXON","2001-04-18","Align the NETA Business Process Model with baseline 3.2","Correct and republish the html and Casewise versions of the NETA business Process\nModel.","−",null,null,"Nov 04 Release"]

{"sheet":"Issues","index":2,"n_rows":78,"n_cols":36,"rows_kept":78,"merged":[[5,6,5,10],[5,11,5,15],[5,16,5,20],[5,21,5,25],[5,26,5,30],[5,31,5,35],[6,0,6,4],[6,6,7,6],[6,7,7,7],[6,8,7,8],[6,9,7,9],[6,10,7,10],[6,11,7,11],[6,12,7,12],[6,13,7,13],[6,14,7,14],[6,15,7,15],[6,16,7,16],[6,17,7,17],[6,18,7,18],[6,19,7,19],[6,20,7,20],[6,21,7,21],[6,22,7,22],[6,23,7,23],[6,24,7,24],[6,25,7,25],[6,26,7,26],[6,27,7,27],[6,28,7,28],[6,29,7,29],[6,30,7,30],[6,31,7,31],[6,32,7,32],[6,33,7,33],[6,34,7,34],[6,35,7,35],[8,0,8,5],[9,6,9,10],[10,6,10,10],[10,11,10,15],[10,16,10,20],[11,0,11,5]],"flags":["formulas_cached_only"]}
[]
[]
[{"$nulls":4},"BSC Change Register"]
[{"$nulls":4},"Issues"]
[]
[{"$nulls":6},"May",{"$nulls":4},"June",{"$nulls":4},"July",{"$nulls":4},"August",{"$nulls":4},"September",{"$nulls":4},"October"]
["Details",{"$nulls":4},"  Progression","1st - 5th","8th - 12th","15th - 19th","22nd-26th","29th - 31st","1st - 2nd","5th - 9th","12th - 16th","19th-23rd","26th - 30th","3rd - 7th","10th - 14th","17th - 21th","24th-28th","31th","1st - 4th","7th - 11th","14th - 18th","21at-25th","28th-31st","1st ","4th - 8th ","11th - 15th ","18th - 22nd","25th - 29th ","2nd - 6th","9th - 13th ","16th - 20th ","23th - 27nd","25th - 29th "]
["Issue","Title","Proposer","Date Raised","Description ","Status"]
["Open Issues"]
["Issue 68","Under-estimation of Demand capacity and credit cover Percentage","ELEXON","2017-03-28","Demand Capacity (DC) is a parameter that is declared for each BSC Season in accordance with BSC Section K. It is declared by a BSC Party in ‘good faith and as accurately as it reasonably can’ for each Balancing Mechanism Unit (BMU). \n\nCurrent performance in DC submission is poor with only 34 out of 131 Supplier declaring GC/DC for the BSC Winter 2016/17 Season. Further, the quality of DC estimations could be improved as under-statement of the parameter has resulted in £5.9m of CEI error. Regulation of the process is challenging due to the current BSC Issue 68 will look into Demand Capacity (DC) declarations for each Balancing Mechanism Unit (BMU), which are used, along with other parameters, to calculate the Credit Cover Percentage (CCP). The issue to be investigated is the under-requirement of Credit Cover and how to develop a solution to avoid inaccurate DC declarations which lead to this.ules which are ambiguous.","The Issue was raised on 28 March 2017 and the first Issue Group is schedules for 8 May 2017.",{"$nulls":8},"PAB",null,null,"Panel"]
["Issue 69","Performance Assurance Framework Review","ELEXON","2017-03-30","Smart Metering will have profound impacts on wholesale electricity and the BSC, changing industry processes, providing unprecedented quantities and granularity of data, and presenting new assurance challenges.At its March 2017 meeting, the BSC Panel approved the scope and delivery approach of the PAF review, which has been divided into the following four work streams.\nSmart Metering;\nRisk Evaluation Methodology (REM) and other PAF procedures;\nData Provision; and\nPerformance Assurance Techniques.\nThe current Performance Assurance Framework (PAF) provides for a flexible, integrated approach to the deployment of techniques. ELEXON and the Performance Assurance Board (PAB) have become aware of opportunities to further enhance the application of the risk-based PAF envisaged in P207, to address the challenges of a changing industry. In order to be able to address the four work streams, Elexon proposed to hold approximately two Workgroups for each of the four work streams.\nThe first PAF Issue Group meeting will be related to the smart Metering work stream. This work stream will focus on the immediate risks to Settlement presented by the mass roll-out of smart Meters. It will be investigated whether any targeted assurance work should be undertaken to assess and mitigate negative impacts on Settlement.\n","The Issue was raised 30 March 17. \n\nIn order to be able to address the four work streams, we proposed to hold approximately two Workgroups for each of the four work streams.\n\nThe first PAF Issue Group meeting will be related to the smart Metering work stream. This work stream will focus on the immediate risks to Settlement presented by the mass roll-out of smart Meters. It will be investigated whether any targeted assurance work should be undertaken to assess and mitigate negative impacts on Settlement.\n\nThe first PAF Issue Group meeting relating to the smart Metering work stream was held on 25 April 2017 and focused on smart Metering.  The meeting was run as an interactive workshop, with the objective to create a smart Metering risk register and consider the lessons learned from SMETS1 and P272.\n\nThe second meeting is scheduled for the 24 May 2017. This meeting will focus on risk mitigation and PAF changes.",{"$nulls":16},"Panel"]
["Closed Issues"]
["Issue 67","Appropriate Meter Timeswitch Code for Smart Meters","SSE","2017-01-19","SSE have identified that the Meter Timeswitch Codes available are not appropriate for Smart Meters, especially considering that a SMETS compliant Smart Meter can be operated in credit or prepayment mode and change configuration. SSE are looking to raise this as an issue so that there can be an industry agreement on what the correct MTC is for a SMETS compliant meter that will be recognised by Supplier, MOP, DNO, DC and Settlements. We’re considering the option of introducing a limited number of MTCs for SMETS compliant Smart Meters. Create new MTCs that could be used for SMETS1 or SMETS2 compliant Smart Meters. They should be supported across the country, they should indicate that a meter can be operated in both credit and prepayment mode and they should indicate that the meter is programmable. It should also be identifiable through the MTC whether there are any associated MPANs (in order to identify sites with two meters / dual element meters). Time Pattern Regime IDs should not be identifiable through the MTC as Smart Metering opens up a vast array of options with Time of Use tariffs of which there simply may not be enough free MTCs to cope with. In order to support the above, a new MTC Meter Type ID and MTC Meter Type Description may need to be introduced that indicates a meter is a SMETS1/2 compliant Smart Meter. A new MTC Payment Type ID and MTC Payment Type Description which indicates a Smart Meter capable of being in either credit or prepayment mode may also be required.","Closed 13 April 2017"]
["Issue 66","Responsibility for repairs of Dual Function Meters with different Suppliers for Import and Export","Ecotricity","2017-01-19","There is currently an issue present with Dual Function Meters where a fault has occurred on that meter, but there are different suppliers for the Import and Export function of that meter.Under the existing rules, both suppliers are jointly and severely liable for the meter if it becomes faulty, with the Import supplier having the right to appoint the Meter Operating Agent (MOA) for the meter and the Export supplier expected to appoint the same MOA. A potential solution that we would appreciate being discussed during the Issue meetings cover more than just the BSC code, but the electricity retail market as a whole and would involve the following: -The Import Supplier being primarily responsible for repairs of faulty meters -A flow/process existing for Export suppliers to notify the Import Supplier of the fault -Explore the possibility for the Export supplier to contribute to the costs of the fault resolution, potentially via invoicing, splitting the costs 50:50. ","Closed 13 April 2017"]
["Issue 65","LLF Value Threshold Limitations","ELEXON","2017-01-17","An LDSO (NPG) submitted values for the annual 2017/18 audit which exceeded the threshold levels within central systems and our internal validation system. The proposed solutions are dependent on the result of the SVG paper. We will provide the SVG Committee with two potential solutions. Change the systems to allow values (greater than 10 (>10)) to be loaded, validated and used within central systems; or Amend BSCP128 to include threshold limitations, which do not currently exist within the code and default the site to. ELEXONs preferred proposal is to amend BSCP128 so we can stop future levels of this magnitude from being submitted.  The first Issue Group took place on Tuesday 7 March. The second Issue Group was held on 4 May 2017. The Issue 65 Final Report was tabled at the Panel meeting on 8 June 2017. ","Closed 8 June 2017"]
["Issue 64","Defining default price when NIV equals zero and when there is no priced action left after NIV tagging","ELEXON","2016-07-21","Currently, when Net Imbalance Volume (NIV) equals zero or when there is no priced action left in the stack to set the Replacement Price, the Market Index Price (MIP) is used. The MIP is defined by the Market Index Definition Statement (MIDS). The data is provided by two Market Index Data Providers (MIDPs), namely APX and N2EX. Before 5 November 2015 and the implementation of P305 ‘Electricity Balancing Significant Code Review Developments’, the MIP was used every Settlement Period as Reverse Price. This was to set either the System Sell Price (SSP) or System Buy Price (SBP) depending on the system’s length. \nP305 introduced a single Imbalance Price system solely based on the actions taken by National Grid to balance the network, as well as including demand control actions. The MIP is therefore not used as much as it used to be and the Imbalance Price calculation has changed significantly. \nWhen considering the matter, the Issue Group could contemplate the following options:\n• Keep the MIP as the default price for the two scenarios (No change)\n• Keep the MIP but recommend changes to the parameters of the MIDS to the ISG that reflect the change implemented by Modification P305 (Different timebands, Products, ILT…)\n• Use other default options such as the Imbalance Price of the previous Settlement Period, set the price to zero, base the price on an average of  recent Settlement Periods\n• Use an alternative index that is available for free "," Closed on 19/01/2017"]
["Issue 62","Amending the BSC arrangements to allow ELEXON to tender for the Uniform Network Code Gas Performance Assurance Framework Administrator (PAFA) role","ScottishPower Energy Retail","2015-11-02","Under the gas Uniform Network Code (UNC) there are two Modifications seeking to introduce performance assurance arrangements into the gas market for the first time. The P330 proposers believes that should these changes be approved ELEXON should have the opportunity to partake in any tender process for the Performance Assurance operator. The BSC currently prohibits this. The Issue 62 Proposer believes that ELEXON has significant experience and understanding of performance assurance techniques in the energy industry and has transferable skills and knowledge that would potentially meet the criteria for the appointment of the PAFA, should Ofgem approve MOD506. The Proposer would therefore like to explore the potential for the BSC arrangements to be changed to allow ELEXON to bid for the gas PAFA contract. \n"," Closed on 14/04/2016"]
["Issue 61","Changes to Gate Closure for Energy Contract Volume Notifications","EDF Energy","2015-10-28","Issue 61 looked at allowing Energy Contract Volume Notifications (ECVNs) and Metered Volume Reallocation Notifications (MVRNs) to be submitted after Gate Closure, up to a new notification submission deadline. This would decouple the timings of these notifications from those required under the Grid Code (such as Physical Notifications), the deadline for which would remain unchanged. The Proposer considers that allowing ECVNs and MVRNs to be submitted after Gate Closure would increase liquidity in the market.","Closed on 10/03/2016"]
["Issue 60","Interfaces between the European Balancing Project TERRE and the current GB market arrangements","National Grid","2015-06-08","Project Trans-European Replacement Reserves Exchange (TERRE) aims to harmonise the Transmission System Operator dispatch of Replacement Reserve across seven TSO areas from GB to Greece. It will do this by introducing common TERRE Products, which would be akin to products such as BSC Bid-Offers or Short Term Operating Reserve (STOR) submissions. National Grid is expected to utilise TERRE Products for energy balancing in GB from TERRE go-live, which is currently scheduled for summer 2017. As all current GB balancing products feed into the BSC calculations of imbalance prices and volumes, the Proposer considers that the relevant TERRE Products should do so too, as soon as they start to be used as part of GB balancing. This will require changes to the GB market arrangements (BSC and/or Balancing Services arrangements). The Issue 60 report was tabled at the Panel meeting on 12 May 16. The Panel noted that Issue 60 is now closed and that National Grid will raise a Modification in time for the June 2016 Panel meeting.","Closed on 12/05/2016"]
["Issue 59","Consideration of the PARMS and Supplier Charge changes introduced by P272 and P300.","ELEXON","2014-10-31","BSC Modifications P272 'Mandatory Half Hourly Settlement for Profile Classes 5-8' and P300 ‘Introduction of new Measurement Classes to support Half Hourly DCUSA Tariff Changes (DCP179)’, which have been approved for implementation on 1 April 2016 and 5 November 2015 respectively, introduce changes to the Performance Assurance Reporting and Monitoring System (PARMS) and Supplier Charges. Whilst the P272 and P300 Workgroups developed these changes, they recognised that further development would potentially be needed and should be considered by appropriate experts. They therefore recommended that an Issue Group be convened to explore these should either or both Modifications be approved. Now that both Modifications have been approved, ELEXON is raising this Issue to explore the areas identified in the Issue Form to determine if any further changes are required. "," Closed on 11/03/2014"]
["Issue 58","Obligation to estimate missing or correct defective Reactive Energy measurements from CVA metering systems","UK Power Networks","2014-09-02","Existing obligations for data provided from Central Volume Allocation (CVA) metering systems require only the estimation of missing or substitution of defective Active Energy measurements. The estimation of Reactive Energy measurements is excluded from the scope of Data Estimation and Substitution for CVA under BSCP03.\n\nTo enable Distributors to fully comply with their approved charging methodology obligations, it is proposed that Data Collectors should estimate Reactive Energy on a half hourly basis where no actual readings are available and should estimate accurate values of Reactive Energy on a half hourly basis where the actual readings are proven or strongly suspected to be in error.\n\nA similar change was made in 2010 for Supplier Volume Allocation (SVA) metering systems under CP1303 ‘Requirement on Half Hourly Data Collectors to Estimate Missing Reactive Power Demand Values’. This Issue will look at extending this solution to CVA metering systems.\n\nAs well as CVA metering systems embedded within Distribution Systems which are subject to Distribution Use of System (DUoS) charges, this Issue will also look at enhancing the accuracy of data available to National Grid as the Total System becomes more actively managed at all levels. It will also consider the estimation and correction of Reactive Energy measurements at other CVA metering systems between, into and out of Transmission and Distribution Systems more generally.","Closed on 12/03/2014"]
["Issue 57","Should Half-Hourly Settlement be mandatory for certain Unmetered Supplies customers?","ELEXON","2014-05-22","SVG is supportive of ELEXON raising an Issue to look at minimum requirements for HH UMS.","Closed on 101/10/2014"]
["Issue 56 ","Treatment of the new SBR and DSBR services in the imbalance price","National Grid","2014-05-08","This Issue looks to consider how to reflect the new Supplementary Balancing Reserve (SBR) and Demand Side Balancing Reserve (DSBR) services in the imbalance price.","Closed on 101/12/2014"]
["Issue 55","Review of the approach to the calculation and application of GSP Group Correction Scaling Weights","ELEXON","2014-02-14","A paper was taken to SVG in November and December about HH GSP Group Correction Factors. Issue 55 seeks to look at the appropriate means of amending the Code in order for such HH GSP group Correction factors to occur. A resultant Modification would need to be progressed in advance of April 2015 (i.e. implementation as part of the February 2015 Release).","Closed on 08/05/2014"]
["Issue 54","Discrepancies between the points of measurement required in the BSC and the CoPs and the physical points of connection","ELEXON","2014-02-06","There are currently discrepancies between where the Balancing and Settlement Code (BSC) requires measurements of energy for Settlement purposes to be made and where the Codes of Practice (CoPs) require overall accuracy to be maintained (the Defined Metering Points (DMP)). This could result in many applications for Metering Dispensations where the actual points of connection do not coincide with the DMP. In addition, the DMP for Interconnectors is very specific and not up to date.","Closed on 12/06/2014"]
["Issue 53","Reforming the Change of Supplier meter read process for smart electricity meters","EDF Energy","2013-12-09","The existing Non Half Hourly (NHH) Change of Supplier (CoS) process is complicated, relying on multiple information flows being sent between new and old Suppliers and Supplier Agents. Due to the number of flows of data being sent the process is prone to error. When the data flows are not sent or cannot be processed by the recipient, delays occur which can result in inaccurate data entering Settlement. The costs of resolving these delays and process errors are borne by Suppliers, Supplier Agents and ultimately the consumer.\n\nOfgem’s CoS Project, a work stream within its ‘Promoting smarter energy markets’ work programme, has the objective of delivering a “fast and reliable and cost effective Change of Supplier (CoS) process that will facilitate competition and build consumer confidence”. Ofgem has engaged with a range of stakeholders through its Change of Supplier Expert Group (CoSEG) and identified a number of reform options, in light of the advent of the Data Communications Company (DCC) and smart meter rollout. Such reforms include reducing the reliance of the CoS process on data transfers.\n\nOfgem has written an open letter to the Panel highlighting and welcoming a new Issue to look at these process reforms. Ofgem believes these reforms should be progressed now through existing change processes. Issue 53 has been raised to look at these reforms.\n\nIssue 53 Report was tabled at the 20 Mar 2014 Panel meeting, where it was noted that a Modification was required to take the changes forward.","Closed on 14/12/2013"]
["Issue 52","Billing for Data Transfer costs and the 'Total Cost of Ownership' for using a replacement solution to send DTS Flows","BSC Panel","2013-08-08","Issue 52 seeks to consider two areas of the Data Transfer Service (DTS), relating to whether an alternative mechanism can be used to deliver DTS Flows and how these costs are charged to BSC Parties.","Closed on 14/11/2013"]
["Issue 51","Multiple MOAs and Third Party Access","ELEXON","2013-07-02","Following SVG’s decision to reject CP1378 at its meeting on 2 July 2013, Issue 51 has been raised to continue the work started by the CP1378 Workgroup.\nBefore tackling the concerns over competition in metering, Issue 51 will look at addressing the robustness of the current end-to-end process, the associated risks and the control framework that needs to be established.","Closed on 01/09/2014"]
["Issue 50","Customer Appointed Agents","Npower","2013-06-26","This issue seeks to address concerns  where a Customer appoints a Third Party Agent rather than using the Suppliers own appointed agents. The proposer believes customer appointed agents may give rise to issues around BSC obligations, requirements and performance standards as they have reduced control over what they do as the customer has chosen them. The issue is looking to address this through changes to the qualification process and/or the BSC around changing Supplier obligations where a customer appointed agent is involved and increase the obligations on an agent if they have been chosen by a customer.","Closed on 01/09/2014"]
["Issue 49","Change of Measurement Class (CoMC) process for Advanced Meters","ELEXON","2013-06-24","Electricity supply standard licence condition 12 requires that by 6 April 2014 Suppliers must not supply electricity at any Metering Point in Profile Classes 5 to 8 other than through an Advanced Meter. From that date, the Change of Measurement Class (CoMC) process from Non Half Hourly (NHH) to Half Hourly (HH) is likely to involve a NHH Meter which is already HH capable. Whilst the current BSCP processes make some allowances for a CoMC with no change of Meter, they do not fully embrace the possibility that a CoMC can take place without the need for a site visit by the MOA. ELEXON has been asked to review the CoMC process by the Profiling and Settlement Review Group (PSRG) to ensure that the complexity (real or perceived) of the CoMC process does not act as a barrier to elective HH Settlement.","Closed on 01/02/2014"]
["Issue 48","SMETS & Codes of Practice (COPs)","ELEXON","2013-06-05","The BSC currently requires all Metering Equipment to comply with the Codes of Practice (CoP). However, smart Meters will only need to comply with smart metering equipment technical specifications (SMETS) and will not need to additionally comply with the CoPs.\n\nELEXON has already carried out a gap analysis on the CoPs and SMETS, but the findings need further consideration. Therefore an Issue Group will be convened to consider what changes are necessary to the BSC, CoPs or other Code Subsidiary Documents.","Closed on 12/09/2013"]
["Issue 47","GB Implementation of the European Transparency Regulation ","National Grid","2013-04-26","The European Regulation on submission and publication of data in electricity markets, commonly known as the 'Transparency Regulation', requires primary data owners to submit information to the Transmission System Operator, or a third party acting as a data provider, for publication on a central information platform. \n \nThe aim of Issue 47 is to consider the implementation of the Transparency Regulation, assess what modifications are required to implement it, and facilitate the effective progression of such modifications.","Closed on 11/07/2013"]
["Issue 46","Non Half Hourly Interoperability ","ELEXON","2013-04-04","ELEXON has investigated issues around interoperability in the Non Half Hourly (NHH) market, considering what lessons can be learnt from the Half Hourly (HH) market. \n\nELEXON believes that NHH processes could be strengthened, for example, by introducing protocol testing for advanced Meters in Profile Classes 5 to 8 or raising a change to clarify the rules for Outstation Protocol approvals where HH Metering Equipment is used for NHH Metering Systems.  ","Closed on 12/12/2013"]
["Issue 45","Introduction of Change of Supply Agreed Read Principle to correct all errors in Settlements","British Gas","2012-07-16","The Proposer identifies issues arising from MAP CP 0135, which was approved by the MRA Development Board (MDB) in June 2012, with an implementation date of February 2013. This change will introduce new principles into MRA Agreed Principle (MAP) 08 relating to Change of Supplier Agreed Reads. Under these new principles, the old Supplier will now have an obligation to use reasonable steps to correct any error in Settlement. The Proposer identifies that, where a dispute has arisen between Suppliers as to the correct number of dials that should be used for calculating energy used for Settlement purposes, there are currently no mechanics that exist within the BSC to allow Suppliers and their agents to correct Settlement data as required by these new principles.","Closed on 01/01/2013"]
["Issue 44","Balancing Mechanism Pricing","National Grid","2012-04-20","The Proposer identifies issues with the rules for Bid-Offer Data Prices in the Balancing Mechanism that can result in inefficient pricing and/or reduced flexibility to meet the challenges of future system operation.  These issues are at their most significant for multi-shaft Combined Cycle Gas Turbine (CCGT) Modules and Cascade Hydro Schemes, but also affect other generators.","Closed on 01/10/2012"]
["Issue 43","On-site generation during planned outages","E.ON","2011-09-09","During a planned outage a Distributor and customer can agree the provision of on-site generation.  This Standing Issue highlights possible implications for Settlement accuracy as well as for Suppliers.","Closed on 01/02/2012"]
["Issue 42","Black Start Generator – Defining a ‘Local Shutdown’","National Grid","2011-05-04","The P231 Workgroup previously highlighted that an instruction to a single Black Start Station (e.g. during a localised shutdown) could result in the suspension of normal BSC market operations.  National Grid has raised this Standing Issue to facilitate further industry discussion of this issue, and whether any changes are needed to the BSC and/or Grid Code.\nYou can find the Issue form as submitted by the Proposer, along with a further attachment containing additional information on the ELEXON website.","Closed on 01/08/2011"]
["Issue 41","Improving the Speed and Accuracy of Data Flows","E.ON","2011-04-28","Performance Assurance Techniques look to detect non-compliance with the timeliness / quality of flows and ensure rectification of non-compliances. However, it often proves difficult to audit and enforce the quality of the data flows. Whilst data flows sent according to agreed timescales may appear compliant, if these flows are inaccurate or incomplete it can result in long and costly delays whilst any issues are resolved. Issue 41 has been raised by E.ON UK to investigate how best to improve the quality of certain SVA data flows and to mitigate the issues that poor quality of such data flows cause.","Closed on 01/10/2011"]
["Issue 40","Review of ELEXON Governance and Funding Arrangements for New Business Opportunities","E.ON","2011-03-29","BSCCo is unable to pursue new business development opportunities as it is precluded from doing so under Section C 1.2.2 of the code.","Closed on 01/09/2011"]
["Issue 39","Unrecorded Units identified by Revenue Protection Services","E.ON","2010-09-24","In October 2009 a party to the Distribution Connection and Use of System Agreement (DCUSA) raised DCUSA Change Proposal DCP 054 ‘Revenue Protection/Unrecorded Units into Settlements’. The DCP 054 Working Group was set up to consider this Change Proposal, and continues to hold regular meetings. DCP 054 is in the ‘definition’ phase of progression.\nThe DCP 054 Working Group has recognised that obligations relating to how unrecorded units are estimated and submitted into Settlement could be included in the DCUSA. However, the requirements for the subsequent processing of these units fall within the scope of the BSC. There is no single clear solution for processing unrecorded units in Settlement under the BSC. On behalf of the DCP 054 Working Group, E.ON UK raised Standing Issue 39 ‘Processing Unrecorded Units identified by Revenue Protection Services’ to allow various options to be considered.","Closed on 01/02/2011"]
["Issue 38","Potential Improvements to Credit Checking Rules to Support High Levels of Embedded Generation in North Scotland","BSC Panel","2009-10-08","There is a defect in the method used by BSC credit checking processes to estimate how much energy Suppliers have used. This defect only becomes material if the amount of embedded generation in the GSP Group is nearly as large as the amount of demand. In September the North Scotland GSP Group came close to this for the first time. ","Closed on 01/12/2009"]
["Issue 37","Boundary Point Metering and BM Unit Issues in Section K.","BSC Panel","2009-05-14","The Issue relates to Section K of the BSC in which three areas of concern have been identified and highlighted by the ISG.\nCombined Cycle Gas Turbine (CCGT) Modules: In most cases both generating units associated with CCGT Modules are coupled together before connecting to the Transmission System and metering is installed at the Boundary Point which facilitates the BMU requirements. However if the generating units are of licensable size then additional metering is required for each generator even though the CCGT Module remains a single BMU in both cases.\nPower Park Modules (PPMs): Under certain circumstances additional metering is specified which may exceed the BMU requirements. This is particularly relevant for off shore wind farms where currently the BSC requires that all Boundary Points should have metering installed (typically at the connection of each string of turbines). Lack of provision for the transfer of generators from one BMU into another by virtue of switching through alternative routes to the Total System. This can be problematic if it becomes necessary for PPM operators to re-route generator outputs in the event of a cable or generator fault.","Closed on 01/07/2009"]
["Issue 36","Party Failure and Default","BSC Panel","2008-11-18","As a result of the recent defaults under the BSC and the resultant debts that all Parties are being exposed to, the BSC Panel has asked that an Issues Group considers the processes and timings for dealing with defaulting and failing Parties. The Panel is keen to understand if the industry believes there are any improvements that could reduce the potential debt. \nQuestions that should be considered include:\n1) Does the Code allow the Panel default powers to be triggered sufficiently early?\n2) Are there any additional actions that should be undertaken relating specifically to the various mechanisms for a Party 'exiting' the arrangements (e.g. actions specific to entering into administration, trade sale, etc.)?\n3) Is it appropriate to treat ECVNS and MVRNS differently? (Currently Trade sale and SoLR will automatically clear MVRNs and BOAs because they are BMU based, however the Panel is required to agree to clear ECVNs).\n4) Should we cash out volumes for failed Parties at a neutral price?\n5) Any further lessons to be learnt from recent failures?","Closed on 01/02/2009"]
["Issue 35","Timing of Gate Closure and Related Matters","Utilita ","2008-09-08","Based on the Issue 30 discussion, Utilita believes either advancement of Gate Closure or the deadline for submission of contract notifications could have a beneficial impact for reducing imbalance risk. Panel observations invited. \nQuestions posed:\n- Implications of shifting GC to 30 mins? Feasibility?\n- Impacts on Balancing and imbalance, including on both central and participant systems; Trading through APX & Settlement; SO interactions and balancing efficiency  \n- Would 45 or 15 mins be better or worse? \n- Can contract notification be shifted on its own and what are the implications? \n- Impact on quality of reverse price and spread?","Closed on  Apr-09"]
["Issue 34","Distribution Losses","Scottish Power","2008-04-29","Scottish Power networks has raised a concern regarding the variability of losses on their networks (their two networks are geographically separate). The Issue seeks to understand whether there are any Settlement anomalies contributing to the perceived discrepancies and if any broad analysis could be undertaken to investigate. More information on this issue can be found on the ELEXON website: Issue 34 - Distribution Losses","Closed on  Jun-08"]
["Issue 33","Fuel Security Code guidance","BSC Panel","2008-02-14","Further to the publication of a revised Fuel Security Code the BSC Panel raised P221 ‘Amendments to the BSC to reflect the revised Fuel Security Code (FSC)’. P221 simply ensures the BSC is consistent with the FSC and has been recommended for approval by the Panel. As part of the consultation for P221 the Panel received feedback that a standing Issue group should be formed to consider the FSC guidance (which published alongside the revised FSC) and the letter sent from BERR to Ofgem regarding queries raised in relation to the revised FSC. Respondents suggested that clarification may be necessary (either formally within the BSC or in the form of guidance from ELEXON and/or Ofgem) regarding:\na) Cost Recovery Processes; b) Interim Claims Processes; c) Communication of Fuel Security Period; d) Presentation of Claims; and e) Role of BSC Panel. \nThe BSC Panel therefore agreed to raise a new Issue to consider the FSC Guidance and BERR letter to ELEXON. The Fuel Security Code guidance can be found on the BERR website: \nhttp://www.dti.gov.uk/energy/reliability/downstream/page30313.html","Closed on 01/07/2008"]
["Issue 32","Black Start","National Grid","2007-11-27","As a result of a recent Black Start exercise, a number of learning points and process improvements have been identified that are relevant to ELEXON’s role and the successful suspension and recommencement of market arrangements as part of a Black Start.  In particular, the following areas were identified where work could be undertaken to ensure that any Black Start progressed smoothly from a BSC perspective:\n1. The arrangements for the formal declaration of the start of a Black Start under the BSC and calculation of the Imbalance Price.\n2. Appropriate arrangements, processes and timetables to successfully reinstate the market following a Black Start. Consideration should be given to developing criteria that the Panel can use to determine reinstatement of the market as well as the outline processes and arrangements to cover timescales, data and audit requirements, liaison with participants and National Grid, alignment with Grid Code arrangements and ‘run in’ to going live.\n3. ELEXON’s business continuity requirements specifically related to its role during a Black Start. Suggest consideration is given to\nWe suggest that for all three areas above, consideration should be given by the Issue group as how best to establish arrangements to expedite the BSC processes during a Black Start and also to ensure that participants will understand how this should work with the overall aims ensuring timely progression of BSC processes during a Black Start, good co-ordination with other industry and government bodies and in particular with Grid Code Black Start arrangements and how best to minimise industry uncertainty and queries to ELEXON during a Black Start.","Closed on 01/07/2008"]
["Issue 31","Provision of Annualised Advance and Estimated Annual Consumption Data to LDSO","Electricity Network Company","2007-11-27","Currently Annualised Advance and Estimated Annual Consumption Data is provided by Data Collectors to Suppliers and Non Half Hourly Data Aggregators through use of the DTC data flow D0019.  Modification Proposal P43 was raised by Western Power in January 2002 proposing that these should be provided to LDSOs.  This proposal was rejected.  At the time one of the key reasons for rejection was the lack of support.  However, it appeared to be acknowledged that this was an issue that could be revisited at a future date if circumstances changed. We believe circumstances have changed.\nAt the time of the proposal business separation was still being undertaken and business attention was focussed elsewhere.  However, all LDSOs are now operating as completely separate entities and no longer receive site specific consumption information in respect of customers trading under the super customer mechanism.  Therefore, it is appropriate to review the value that such information has to LDSOs. New LDSOs have entered the market.  Typically, such distributors connect their networks to the distribution systems of the ex-PES LDSOs.  Ex PES DNOs and IDNOs are exploring solutions that avoid the use of boundary metering to ascertain use of system.  One potential solution involves the IDNO providing aggregates of settlement data to the ex-PES LDSO for the purpose of billing DUoS.  This would in essence replicate the current mechanism for billing of DUoS to suppliers.  By IDNOs providing the data to the LDSO no changes to the BSC systems and products are required.  However one of the concerns raised by DNOs is that they need to understand maximum demands on IDNO connections on a site by site basis for network planning and operation reasons.  The solution proposed is for the DTC dataflow D0019 to be provided by the data collector to the relevant LDSO. For more information please refer to Standing Modification Group Issues page on the ELEXON Website.","Closed on  Feb-08 "]
["Issue 30","Cash Out Review ","Utilita ","2007-11-02","A new standing issue has been raised to investigate the broader concepts highlighted in the recent Cash Out Review. The Issue 30 Group will be asked to explore the following questions:\n• Is dual cash-out pricing still appropriate versus single pricing? \n• Are large spreads necessary to provide incentives to balance? \n• Does a large spread in cashout prices generate unnecessary levels of RCRC to the detriment of smaller players? \n• Is there merit in adoption of a single energy price (net of system and energy plus actions) supported by a small symmetric spread? \n• How can BSAD and cash-out be integrated and brought under single governance? \n• Would the assessment of the merits of these issues be impacted by a reduction in Gate Closure from one hour? \n• Is it possible or desirable to restrict the Balancing Mechanism to energy providers? Are there other mechanisms for providing a cleaner separation between energy and system balances?","Closed on  Apr-08 "]
["Issue 29","Profile Administrator (PrA) Model","BSC Panel","2007-08-23","There are a number of issues relating to data collection and recruitment with the existing PrA Model. The data collection issues include lack of available space for new metering equipment, incomplete GSM signal coverage and liability issues. Additionally, there are issues around the lack of diversity and regional coverage for potential PrA sample participants. In order to resolve these issues an alternative PrA Model may be required. A new model may require a modification of the BSC in order to make the requirements mandatory for Suppliers. A ‘Straw Man’ PrA Model has been put forward in order that the feasibility and desirability of an alternative PrA Model can be discussed.","Closed on 01/01/2008"]
["Issue 28","Further Consideration on Section P","BSC Panel","2007-05-14","The Panel raised Issue 28 on 10 May 2007 following concerns arising as a result of Modification Proposal P210.  The Settlement Standing Modification Group (SSMG) and any additional experts should discuss whether Modification to the Code is required in the area of Dual Notification and other points arising from the post P210 process and from the Trading Disputes Committee (TDC).\nThe five issues initially identified are shown below.  It is acknowledged that further issues may be uncovered by progression of Issue 28.\n• Dual Notification\n• Process for replacing one notification Agent with another\n• Handling of negative CALF by MVRN refusal / rejection process\n• Handling of overwrite notifications by refusal / rejection process.\n• Inability to correct Settlement arising from erroneous placement into Credit Default","Closed on 01/08/2007"]
["Issue 27","Funds Administration","Scottish Power","2007-04-23","The BSC review has identified a number of Issues relating to Funds Administration. We believe the Issues and potential solutions described in section 3 of the BSC Review should be submitted to the Settlement Standing Modification Group for industry discussion. The Group can then ascertain if a Modification (or Modifications) should be raised to progress any potential solutions. The BSC Review for 2006/7 considered the funds administration aspects of the Code. This BSC review identified the following issues with the current funds arrangements:\n• Small Value Transactions;\n• Processing of Transactions;\n• Current banking practice not reflected;\n• VAT Reporting;\n• BSC Party Standing Data;\n• Recovery of Credit Cover; and\n• Lodging Funds\nMore information can be found on the following Panel Papers  BSC Review 2006/2007 Funds Administration Report  and Funds Administration : Conclusions and Recommendations","Closed on 01/07/2007"]
["Issue 26","Issues arising from ELEXON/ PAB interpretation","Npower","2007-11-17","A question has been raised over the obligations of transferee and transferor Suppliers arising from a transfer of Supplier ID. This issue seeks to explore what obligations should be due to each Party arising from such an event and whether the Code is being applied correctly and further whether greater clarification is required within the Code for processes and obligations arising from these events. ","Closed on "]
["Issue 25","Governance issues related to PAB determination","Npower","2006-11-17","A recent matter determined by the Performance Assurance Board (PAB) gives rise to the following issues, which Npower Limited requests to be considered by a Standing Modification Group (probably the GSMG):\n1) A determination under paragraph 4.1.1 of Annex S-1, involving interpretation of the Code, has the potential to change the meaning of the Code and thereby effectively circumvent the Modification Process, putting Parties in breach of the Code in respect of matters for which they reasonably believed they were compliant.\n2) There does not appear to be a process for appeal of PAB decisions, except in respect of Certification/Accreditation (or post P197, Qualification), other than judicial review.  The cost, effort and time required for the latter would appear to be disproportionate for all but the most major issues.\n3) For a decision where PAB has discretion, is it appropriate that PAB should hear any appeal on that decision (as opposed to a query)?  If not, who should be the appeal body?\n4) It does not seem appropriate that PAB should act as the appeal body in respect of a matter where a previous decision of PAB is being challenged on the grounds of being inconsistent with the Code (i.e. potentially ‘ultra vires’).  In this case, who should be the appeal body?\n5) The BSC ‘issue’ process does not in itself provide an adequate mechanism to play the role of an appeal process, since it does not result in a decision.  Furthermore, it cannot be assumed that it will always be necessary to make a Modification to the Code in order to resolve an issue, if it is an interpretation or compliance matter.\nIt may also be appropriate to draw these issues to the attention of the Modification Group considering Modification Proposal P207","Closed on 01/06/2007"]
["Issue 24","Impact of BSC Reactive Power Charging","Gaz de France","2006-06-20","As described in recent SVG papers (SVG62/08, SVG63/11 and SVG64/07), Section K of the BSC requires a licensed Supplier (not the Licence Exempt Generator) to take responsibility for Reactive Power absorbed by Licence Exempt Generating Plant.  This is leading to anomalies in Distribution Use of System (DUoS) charging for sites such as wind farms, with the Supplier being charged for Reactive Power flows which (in the view of the Parties concerned) would be better charged to the Licence Exempt Generator.  As Reactive Energy is not settled under the BSC, it is not clear that there is any requirement for the BSC to be so prescriptive about who takes responsibility for Reactive Power flows.  The issue has been raised to investigate options for making Section K less prescriptive.","Closed on May-07"]
["Issue 23","Apparent Tendency for EAC values to under-estimate consumption","Central Networks","2006-06-07","The Non Half Hourly settlement process relies heavily on estimates of annual consumption (EACs), particularly at SF and early reconciliation stages.  This use of EACs is based on the assumption that they are a reasonable estimate of consumption.  However, this assumption appears to be flawed, because analysis (carried out by Distributors and ELEXON) suggests that EAC values are, on average, lower than actual consumption. This discrepancy appears to be driven by the backward looking nature of EACs, and their failure to capture growth in demand over time.  This has a number of implications for both trading parties and DSOs:\n• Total NHH uncorrected energy tends to increase across settlement runs \n• The degree of correction in the NHH market is larger than necessary \n• Suppliers have a perverse incentive not to read meters / suppliers that read meters more frequently are effectively penalised \n• DUoS bills (based on uncorrected consumption) are lower than they should be \n• Error becomes fixed at RF whenever EACs have not been replaced by actual meter readings \nIn view of the above I believe the time is right to review of the EAC methodology with a view to improving the accuracy of consumption estimates.  As discussed this would best be done through a settlement issue and I therefore formally request that an issue should be raised and pursued.","Closed on 01/10/2006"]
["Issue 22","Indebtedness","SmartestEnergy","2006-01-18","Smartest perceive that we have to put up credit way in excess of our real exposure. This occurs for two reasons1) as a consolidator our base BMU units are net exporters, but the CEI part of the calculation only takes consideration of the DCs, not our GCs2) the II part of the calculation does not adequately cater for large portfolio changes, as it is using estimates not actual data. This second point is nothing new and is almost certainly the main reason behind the conclusion of the ISG Panel Paper 100/009 that the indebtedness calculation is least suitable for suppliers. An option here is to raise a modification to investigate further and implement changes following on from this paper (so long as our specific issue above is also addressed) We are of the view that manual submission of GCs and DCs is inefficient -- monies spent policing the arrangement could be spent on automating it in some way. We are also of the view that the excess credit of £250m industry-wide comes about as a result of a fear of being named publicly and this issue should be addressed. I am mindful of the fact that there have been many mods to tinker with the calculation in the past and that large ones have failed on the grounds of cost. However, credit is a rather topical issue at the moment and we suspect there is appetite for an even wider review of the credit arrangements. We wonder whether the thresholds or period over which the calculation is made should be debated","Closed on 01/08/2006"]
["Issue 21","Scope of Profile Administration","BSC Panel","2006-12-08","Issue 21 seeks to initiate industry discussion of the following potential issues relating to the scope of the Profile Administrator service:(1)  The problems experienced by the Profile Administrator in recruiting customers into the load research sample; and (2) The reliability of existing logging equipment which is owned by ELEXON. Potential solutions to (1) would be either to transfer responsibility for the sample recruitment to Suppliers (which would require a modification to the BSC); or For ELEXON to pursue other ways of recruiting customers (which would not require a Modification Proposal). Potential solutions to (2) would be either: To use the same metering equipment for billing, settlement and load research (which would place responsibility for the equipment on Suppliers and would require a modification to the BSC); or For ELEXON to replace the existing logging equipment with separate metering equipment to that used by Suppliers (which would not require a Modification Proposal). It is believed that a Modification in this area may improve the efficiency of the Balancing and Settlement arrangements and could therefore be raised by the Panel under section F2.1.1(d) of the Code.","Closed on 01/03/2006"]
["Issue 20","Fuel Security Code","Gaz de France","2005-10-26","The DTI have recently published the draft changes to the Fuel Security Code for industry consultation.  A modification will be required to amend the Balancing and Settlement Code to reflect the changes to the FSC, and it is likely that the timescales for progressing this modification will be limited.  It is proposed that a Standing Issue be raised to allow industry consideration of the changes required to the BSC and to ensure that any potential issues with the drafting of the BSC changes are addressed prior to such a modification being raised.  The intention is not for this Standing Issue to consider the merits of the changes to the FSC (views on the FSC changes can be provided to the DTI by responding to the consultation on the draft FSC changes) and should be limited to consideration of the impact the changes with have on BSC processes.  It is suggested that this Standing Issue be considered by the Pricing Standing Modification Group.","Closed on 01/10/2007"]
["Issue 19","PARMS the way forward","Centrica","2005-09-21","Further to the recent issue of the \"PARMS - The Way Forward\" consultation document on 15th September, we wish to formally raise an Issue to enable industry participants to meet, review and debate the available options to progress the PARMS implementation collectively to ensure that any solution implemented is robust.  We firmly believe that with the escalating costs and the further delay to the catch up of Supplier Charges, affected industry participants should agree the most appropriate course of action.  \nWe would recommend that an initial meeting is convened with the focus of the Issue Group to include, but not be restricted to an overview of the current issues and materiality of the PARMS errors; and a review of the available options, including their associated development costs and benefits.","2005-11-01"]
["Issue 18","Sleeper bids","Opus Energy","2005-08-11","During the discussions on P171-173 it was generally recognised that there were wider issues associated with so-called sleeper bids in circumstances where balancing actions are taken outside of the normal operation of the market. Ofgem echoed these concerns in its P173 and P175 decision letters, referring to the potential to distort competition.\nMore light was shed on this matter at NGC’s interim operational forum on 3 August.  In a presentation now posted on NGC’s website, NGC concluded that there were a substantial number of BMU bids at “abnormal prices”, and many of these were from non-nuclear plant.  NGC data also shows the incidence of posting high sleeper bids is now greater in the light of decisions on P173 and P175.  The conclusion reached by NGC was that there is “fairly substantial industry risks” arising from these circumstances, which might be triggered by high demand scenarios or transmission constraints.  It is clear that the ability of generators to post bids up to the theoretical maximum of £99,999 needs examination with a view to identification of appropriate rectifying modification proposals.  One option for such change might be impose a requirement on all participants (the issue applies in principle to all offers and bids) that offers and bids must be related to their reasonable cost."," Nov-05 "]
["Issue 17","Review of Electricity Market information","National Grid","2005-05-04","National Grid is currently developing proposals to improve information flows between Users and National Grid under the Grid Code.  Issue 17 outlines the potential impact of the Grid Code proposals on the BSC and BMRS, and seeks to initiate discussion regarding the potential benefits of these proposals (and any other proposals relating to BMRS data publication that the Standing Group may wish to develop) on market signals.","2005-09-01"]
["Issue 16","Credit Default and the Default provisions in Section H of the BSC","British Gas Trading","2005-04-20","Issue 16 was raised in order to consider whether the current Code provisions for dealing with persistent or recurring Level 1 or 2 Credit Default provide industry participants with an appropriate level of protection. In particular, whether the existing provisions whereby a Party is placed in Section H default following a defined period of either Level 1 or 2 Credit Default are sufficient.","2005-05-01"]
["Issue 15","Review of Trading Query Deadlines","EDF Energy","2005-04-19","Since the introduction of P107, we believe that Suppliers have been severely disadvantaged where an error with HH data becomes apparent outside of the settlement deadlines and where the party had no ability to highlight the error through normal validation processes. P131 has further exacerbated the issue, by preventing the supplier from correcting even 20 months of the error as only data within the Settlement window of 14 months will be altered.","2005-05-01"]
["Issue 14","Vacant sites and ‘Shut Down’ meters","Powergen","2005-04-04","Issue 14 claims that there is an inaccuracy in Settlement since many vacant, but energised sites are settling on non zero estimated consumption values due to the fact that Data Collectors are unable to access the sites and Suppliers are unable to obtain Customer Own Reads.  This leads to an over-accounting of  uncorrected energy in Settlement"]
["Issue 13","Codes of Practice applicable to Metering Systems","Gaz de France","2004-11-22","The Code requires Metering Equipment to comply with the relevant Code of Practice (CoP) current at the time of first registration (L 3.2.2). However, a number of Metering Systems have been installed for a time prior to registration and the CoP to which they were installed had lapsed.  As a consequence, a number of Metering Systems are found unnecessarily non compliant during technical audits.","2005-01-01"]
["Issue 12","Timescales for Withdrawal from the BSC","Uskmouth Power Company Limited","2004-09-21","The current BSC withdrawal process requires companies to remain as BSC Parties until following the Final Reconciliation Run (RF).  To improve the efficiency of this process, and to limit the costs and risks for all parties, Uskmouth Power Company Limited is considering raising a Modification Proposal to enable Parties who have settled all of their trading debts as best they are able by the 2nd Reconciliation Run (R2) to withdraw from the Code - leaving a cash deposit with BSCCo to cover their future liabilities.  This would be a voluntary ability, which could be utilised by Parties who are non-physical traders or are responsible for CVA-registered meters. Issue 12 sets out a number of areas which would potentially be covered by such a Modification Proposal, and seeks the views of the SSMG regarding these issues prior to drafting a Proposal.","2004-10-01"]
["Issue 11","Performance targets and Monitoring","Centrica","2004-09-02","The current Settlement target of 97% became effective with the introduction of the 1998 Trading Arrangements to ensure the equability of Settlements.  This target does not ensure that equability is delivered for two prime reasons, firstly, fluctuations between actual and estimates is minimal and secondly, incorrect skew factors can be contained within the deemed actual performance. The current performance levels for Suppliers to achieve 97% is an inappropriate target and does not drive the appropriate incentives to improve data quality and encourage participants to ensure accurate data enters Settlements, instead, it diverts attention from the real issues.\nTo address this issue, we believe that potentially two steps need to be taken.  Firstly to amend the target of 97% to performance within an agreed tolerance of market average, therefore maintaining the deemed status quo of Settlement equability.  Secondly, a longer term initiative needs to be considered to identify more appropriate measures of equability. In addition, an appropriate supporting monitoring framework should be in place, to enable the market to monitor data quality and operational performance on an equitable and impartial basis to ensure that equitability of Settlements is actually achieved.","2004-12-01"]
["Issue 10","Implementation Dates","NGT","2004-08-24","NGT would like to raise the whole issue of 'Implementation Dates' as a Standing Issue for consideration by the GSMG - specifically, whether the BSC is inconsistent with the Transmission Licence in that the current construction of Implementation Dates may lead to Authority decisions being 'timed out' if decision cut-off points are passed.","2004-10-01"]
["Issue 9 ","Review of aspects of the Modification Process","Bizz Energy","2004-07-21","The Proposer argues that – although generally the Modification Process works well – Section F contains some shortcomings including the inability to withdraw a Modification after it has been presented to the Panel, the inability to recall and amend legal text with the Authority, and the requirement for ‘housekeeping’ changes to follow the full Modification Procedures.\nThe Proposer has raised Issue 9 to allow a standing group to undertake a review of the Section F Modification Procedures – building on the ‘issues register’ presented by ELEXON to the BSC Panel as paper 75/014, and any efficiency lessons to be learned from other industry code governance structures.","2004-10-01"]
["Issue 8","Apparent Inconsistency between requirements for rectifying NHH Meter reading history anomalies and the BSC","Npower","2004-06-22","The Issue was first presented to the Supplier Volume Allocation Group on 1 June 2004 in paper SVG/40/006.  The SVG paper identified an inconsistency between methods currently being used for deeming Meter readings and the provisions of the Balancing and Settlement Code (the Code), Annex S2.  The issue was also raised by the BSC Auditor in the BSC Audit Report, statement of significant matters ‘Deemed reads calculated in incorrect circumstances’.","2004-08-01"]
["Issue 7","Potential anomaly in respect of Bid Offer Acceptance (BOA) volume","British Gas Trading","2004-04-14","An anomaly may exist when a Party operates with or re-declares its MEL to a lower level than the submitted FPN.  The re-submission of the MEL to this lower level will be a representation of the BMU performance meaning the FPN is not representative of the BMU’s operating level.  If the System Operator was then to issue a BOA, it will be from the MEL all the while the MEL<FPN, and we would expect the volume associated with that BOA be calculated from the appropriate level.  However, we believe that the credited volume is based upon the now redundant FPN and not the MEL, which now reflects the BMU’s running pattern.","2004-06-01"]
["Issue 6","Appropriateness of the current Supplier Charging Mechanism","Energywatch","2003-08-06","The Performance Assurance Framework 'supplier charges' technique should incentivise suppliers to attain the levels of data quality that are set out in the Balancing and Settlement Code (BSC).  The current means of calculating, capping and redistributing supplier charges may not be the most efficient or effective way of meeting this objective.\nIt would be useful to investigate the appropriateness of the current supplier charging mechanism as an incentive to improve data quality and also to explore whether an alternative incentive mechanism could be proposed that could be simpler and more transparent.","2003-11-01"]
["Issue 5","Treatment of Parties going directly into level 2  Credit Default","Powergen","2003-08-08","There is an issue in respect of how Parties should be treated if their Credit Cover Percentage goes directly to a level at which Level 2 Credit Default should be called.  It is unclear whether a Query Period exists in this circumstance and there is no provision for a Cure Period as there is for Level 1 Credit Default.  This means that Parties are sometimes unable to raise additional Credit Cover to avoid being put into Level 2 Credit Default, if the potential event of default occurs on a non business day","2003-08-01"]
[" Issue 4 ","Periodic reviews of the BSC","BSC Panel","2003-07-22","BSC Section C3.8.1(a) currently obliges BSCCo to carry out periodic reviews of the Code and its implementation and of operations under the Code in order to evaluate whether it continues to facilitate achievement of the Applicable BSC Objectives, and to do so in the most effective way. These reviews must take place at least once every 2 years and not more often than once every year. The GSMG is invited to consider whether there may be any merit in amending this provision, in order to assist ELEXON and the BSC Panel in considering whether to propose a modification that would seek to increase efficiency in the implementation and administration of the Code.","Withdrawn"]
["Issue 3","Credit cover for Interconnector users","EDF Trading","2003-02-26","Interconnector BM Units are less likely to act in accordance with their historical patterns than other kinds of BMUs due to volatility caused by pricing differences between England & Wales and the neighbouring system(s) and, in the case of the Anglo-French Interconnector, the ongoing auctioning of interconnector capacity.  This means that traditional CALF methodologies - which look at historical patterns – are often irrelevant to an Interconnector Users current position.","2003-08-01"]
["Issue 2","Credit Indebtedness Calculation during Holiday periods","Bizz Energy","2003-01-06","Where a supplier is purely (or dominantly) non-domestic then its actual demand can drop significantly (down to 1/3) during this period. Its contractual position will follow this drop. During the period between the delivery day and the II run (which can be more than 10 days during Christmas) the CALF calculation massively overstates the demand. This can rapidly tip such portfolios into credit shortfall at a time when banking services are not available.","2003-07-01"]
["Issue 1","Credit cover provisions for the BSC signatories withdrawing from the Market","Gaz de France","2003-01-02","Are there adequate provisions within the Code as currently drafted to ensure that signatories to the BSC, who elect to withdraw from the market in an orderly manner, must maintain adequate credit cover provision and ensure full payment of all bills, including ELEXON related charges, for a relevant period after they officially exit?","2003-07-01"]

{"sheet":"Releases","index":3,"n_rows":47,"n_cols":11,"rows_kept":47,"merged":[[1,1,1,10],[13,1,13,10],[26,1,26,10],[37,1,37,10],[41,1,41,10]],"flags":["formulas_cached_only"]}
[]
[null,"June 2017 BSC Release - 29 June 2017"]
[null,"Change Number","Title of Change","BSC Central Systems/Document only impacts","Date Raised","Current Status of Change","BSC Systems/Documents Impacted","BSC Parties Impacted","Party Agents Impacted","Industry Consultation Status","Ofgem/BSC Panel/Panel Committee Approval Status"]
[null,"P297","Receipt and Publication of New and Revised Dynamic Data items","System","2013-07-24","Pending Implementation","BMRA, SAA, BSC Sections (Q, V, X-2), NETA IDD Part 1, NETA IDD Part 2","Transmission Company","None","Completed","Confirmed (will be moved pending Ofgem consideration)"]
[null,"P321","Publication of Trading Unit Delivery Mode","System","2015-04-01","Pending Implementation","BMRA, SAA, SVAA, BSC Sections (S Annex S-2, T, V, X Annex X-2), BMRA Service Description, SAA Service Description, BMRA URS\nSAA URS, NETA IDD Part 1 document, NETA IDD Part 2 document","None","None","Completed","Confirmed"]
[null,"P329","Changes to REMIT inside information reporting","System","2015-11-25","Pending Implementation","BMRA, BSC Sections (Q, V, X, Annex X-1), BMRA Service Description, BMRA URS, NETA IDD Part 1","Generators, Interconnector Administrators, Interconnector Error Administrators, Interconnector User, Licence Exemptable Generators, LDSOs, Non Physical Traders, Suppliers and the Transmission Company","None","Completed","Confirmed"]
[null,"CP1469","Changes to support the implementation of the SRAG’s recommendations","Document","2016-07-19","Pending Implementation","BSCPs (502, 503, 514)","LDSOs, Suppliers","HHDAs, HHDCss, HHMOAs","Completed","Confirmed"]
[null,"CP1474","Updating the CoMC processes to facilitate the elective HH Settlement of SMETS Meters","Document","2016-10-14","Pending Implementation","BSCPs (501, 502, 504, 514, 533 Appendix B, 537 Appendix 1, 537 Appendix 2)","Suppliers, ","HHDCs, NHHDCs, HHMOAs, NHHMOAs","Completed","Confirmed"]
[null,"CP1475","Remove obligation to re-date final NHH Meter readings on CoMC","Document","2016-10-14","Pending Implementation","BSCP514","Suppliers","NHHDCs and NHHMOAs","Completed","Confirmed"]
[null,"CP1476","Facilitation of Incremental LLFs","Document","2016-10-27","Pending Implementation","BSCP128 Appendix 7","LDSOs","None","Completed","Confirmed"]
[null,"CP1477","Updates to BSCP537 Appendix 1 as a result of P283","Document","2016-11-07","Pending Implementation","BSCP537 Appendix 1","Suppliers and Distribubtors","CVA MOAs and HHMOAs","Completed","Confirmed"]
[null,"CP1486","Removing example Advice Notes, Backing Sheets and Confirmation Notices from BSCP301","Document","2017-03-17","Assessment Procedure","BSCP301","Generators, Suppliers, ","N/A","Completed","Confirmed"]
[]
[null,"November 2017 BSC Release - 2 November 2017"]
[null,"Change Number","Title of Change","BSC Central Systems/Document only impacts","Date Raised","Current Status of Change","BSC Systems/Documents Impacted","BSC Parties Impacted","Party Agents Impacted","Industry Consultation Status","Ofgem/BSC Panel/Panel Committee Approval Status"]
[null,"P335","Inclusion of Non-BM STOR costs and volumes in the indicative cashout price","Document","2016-02-19","Pending Implementation","BSC Section Q","Transmission Company","None","Completed","Confirmed"]
[null,"P336","Fuel types on the BMRS","System","2016-02-29","Pending Implementation","BMRA, ","Transmission Company","N/A","Completed","Confirmed"]
[null,"P342","Change to Gate Closure for Energy Contract Volume Notifications","System","2016-05-25","Pending Implementation","ECVAA, BSC Sections (H, M, P, Annex X-1)","Interconnector User, Licence Exemptable Generators, Non Physical Traders, Suppliers","ECVNAs, MVRNAs","Completed","Confirmed"]
[null,"CP1478","Automate the loading of the DF Matrix","System","2016-11-22","Pending Implementation","SVA and SVAA URS","None","None","Completed","Confirmed"]
[null,"CP1479","Updates to the Defined Metering Points in Codes of Practice 1, 2, 3, 5 and 10","Document","2016-11-23","Pending Implementation","CoPs (1, 2, 3, 5 and 10)\n","Generators, LDSOs and the Transmission Company","CVA MOAs","Completed","Confirmed"]
[null,"CP1480","Creation of a new authorisation category for corrections to BOA related data","System","2016-11-28","Assessment Procedure","CRA, BSCPs (18, 38) ","Generators, Suppliers, Transmission Company","None","Completed ","Pending"]
[null,"CP1483","Changes to BSCP550 - Shared Metering Arrangements","Document","2017-01-18","Assessment Procedure","BSCP550","LDSOs, Suppliers","SMRA, HHDC, HHDA, HHMOA","Completed","Pending"]
[null,"CP1484","Introduction of Additional SVAA Validation at SVA Run time","System","2017-02-08","Pending Implementation","SVAA, BSCPs (503, 508), SVAA URS, SVAA Data Catalogue Volume 1","None","HHDA, NHHDA","Completed ","Confirmed"]
[null,"CP1485","Validation of power transformer and cable/line loss adjustments","Document","2017-03-13","Pending Implementation","BSCP32, CoPs (1, 2, 3, 5)","TAA and Suppliers ","CVA MOA","Completed","Confirmed"]
[null,"CP1488","Align the NETA IDD spreadsheets with the live implementation of the SAA-I014 flow","Document","2017-06-07","Assessment Procedure","NETA IDD Part 1 spreadsheet, NETA IDD Part 2 spreadsheet","None","None","N/A","Pending"]
[]
[null,"February 2018 BSC Release - 22 February 2018"]
[null,"Change Number","Title of Change","BSC Central Systems/Document only impacts","Date Raised","Current Status of Change","BSC Systems/Documents Impacted","BSC Parties Impacted","Party Agents Impacted","Industry Consultation Status","Ofgem/BSC Panel/Panel Committee Approval Status"]
[null,"P348","Provision of gross BM Unit data for TNUoS charging","System","2016-07-01","With Authority","SVAA, BSC Sections (S, Annex S-2, V)","Suppliers and The Transmission Company","HHDA (Option 1) ","Complete","Pending"]
[null,"P349","Facilitating Embedded Generation Triad Avoidance Standstill","System","2016-07-04","With Authority","SVAA, BSC Sections (K, V, X Annex X-2)","Suppliers and The Transmission Company","HHDA (Option 3)","Complete","Pending"]
[null,"CP1482","Upgrade of NHHDA and EAC/AA systems from Oracle 11g to version 12c ","System","2016-12-21","Pending Implementation","EAC/AA, NHHDA,","None","NHHDA, NHHDC ","Complete","Confirmed"]
[null,"CP1487","Remove the exclusion of Change of Measurement Classes in BSCP533 Appendix B","Document","2017-05-17","CP Consultation","BSCP533 Appendix B","None","None","In Progress","Pending"]
[null,"CP1489","Amendments to BSCP128 to align with BSCP68 timescales for LLF submissions for BM Units transferring from SMRS to CMRS and vice versa","Document","2017-06-07","Assessment Procedure","BSCP128","LDSO","None","N/A","Pending"]
[null,"CP1490","Changes to BSCP27 and TAA Service Descriptions to remove constraints to service improvement.","Document","2017-06-14","Assessment Procedure","BSCP27, CVA TAA SD, SVA TAA SD","None","None","N/A","Pending"]
[null,"CP1491","Lack of clarification surrounding the timeliness of Proving Tests and documentation for CVA MOA in BSCP02","Document","1506/2017","Assessment Procedure","BSCP02","None","CVA MOA","N/A","Pending"]
[null,"CP1492","Causes and treatment of large Line Loss Factors","Document","2017-06-21","Assessment Procedure","BSCP128, BSCP128 Appendix 1, BSCP128 Appendix 3, BSCP128 appendix 10","LDSO","None","N/A","Pending"]
[]
[null,"Standalone Releases - 1 April 2018"]
[null,"Change Number","Title of Change","BSC Central Systems/Document only impacts","Date Raised","Current Status of Change","BSC Systems/Documents Impacted","BSC Parties Impacted","Party Agents Impacted","Industry Consultation Status","Ofgem/BSC Panel/Panel Committee Approval Status"]
[null,"P350","Introduction of a seasonal Zonal Transmission Losses scheme","System","2016-07-04","Pending Implementation","CDCA, CRA, SAA, BSC Sections (E, H, T, V, X Annex X-1, X Annex X-2), BSCPs (01, 11, 15, 25), CDCA Service Description, CRA Service Description, SAA Service Description, TLFA Service Description, CDCA URS, CRA URS, SAA URS, NETA IDD Part 2 Word & spreadsheet documents, Reporting Catalogue, Load Flow Model Specification, Load Periods (LPs) and Sample Settlement Periods (SSPs) Methodology","Generators, DNOs, Suppliers, Tranmission Company","None","Complete","Confirmed"]
[]
[null,"TBC Release Date"]
[null,"Change Number","Title of Change","BSC Central Systems/Document only impacts","Date Raised","Current Status of Change","BSC Systems/Documents Impacted","BSC Parties Impacted","Party Agents Impacted","Industry Consultation Status","Ofgem/BSC Panel/Panel Committee Approval Status"]
[null,"P332","Revisions to the Supplier Hub Principle","System","2016-01-28","Assessment Procedure","TBC","Suppliers","HH Data Aggregators, HH Data Collectors, Meter Administrators, HH Meter Operator Agents, NHH Meter Operator Agents, ","Not Completed","Pending"]
[null,"P344","Project TERRE implementation into GB market arrangements","System","2016-06-01","Assessment Procedure","BMRA, CRA, ECVAA, FAA, SAA, SVAA, BSC Sections (A, D, G, H, K, M, N, O, P, Q, R, S, Annex S-2, T, U, V, Annex X-1, Annex X-2), BSCPs (15, 18, 38, 65, 71, 201, 301, 503, 507, 508, two new BSCPs)","Generators, Interconnector Administrators, Interconnector Error Administrators, Interconnector User, Licence Exemptable Generators, Licenced Distribution System Operators, Non Physical Traders, Suppliers and the Transmission Company, ","Half Hourly Data Aggregators","The first of two Industry Consultations has been completed","Pending"]
[null,"P354","Use of ABSVD for non-BM Balancing Services at the metered (MPAN) level","System","2017-01-11","Assessment Procedure","BMRA, SAA, SVAA, Section Q","Suppliers and Transmission Company ","HHDA","Not Completed","Pending"]
[null,"P355","Introduction of a BM Lite Balancing Mechanism","System","2017-06-21","IWA","SAA, FAA, BSC Sections (A, D, G, H, K, M, N, Q, T, U, V, X-1, X-2)\n","Generators, Interconnector Administrators, Interconnector Error Administrators, Interconnector User, Licence Exemptable Generators, Licenced Distribution System Operators, Non Physical Traders, Suppliers,Transmission Company, non-BM Parties ","None","Not Completed","Pending"]

{"sheet":"CP IA Timetable 2016-17","index":4,"n_rows":35,"n_cols":8,"rows_kept":35,"merged":[[1,1,1,7],[3,1,4,1],[3,2,3,4],[3,5,3,7],[5,1,6,1],[5,2,6,2],[5,3,6,3],[5,4,6,4],[5,7,6,7],[7,1,8,1],[7,2,8,2],[7,3,8,3],[7,4,8,4],[7,7,8,7],[9,1,10,1],[9,2,10,2],[9,3,10,3],[9,4,10,4],[9,7,10,7],[11,1,12,1],[11,2,12,2],[11,3,12,3],[11,4,12,4],[11,7,12,7],[13,1,14,1],[13,2,14,2],[13,3,14,3],[13,4,14,4],[13,7,14,7],[15,1,16,1],[15,2,16,2],[15,3,16,3],[15,4,16,4],[15,7,16,7],[17,1,18,1],[17,2,18,2],[17,3,18,3],[17,4,18,4],[17,7,18,7],[19,1,20,1],[19,2,20,2],[19,3,20,3],[19,4,20,4],[19,7,20,7],[21,1,22,1],[21,2,22,2],[21,3,22,3],[21,4,22,4],[21,7,22,7],[23,1,24,1],[23,2,24,2],[23,3,24,3],[23,4,24,4],[23,7,24,7],[25,1,26,1],[25,2,26,2],[25,3,26,3],[25,4,26,4],[25,7,26,7],[27,1,28,1],[27,2,28,2],[27,3,28,3],[27,4,28,4],[27,7,28,7],[29,1,30,1],[29,2,30,2],[29,3,30,3],[29,4,30,4],[29,7,30,7],[32,1,32,3],[32,4,34,7],[33,1,33,3],[34,1,34,3]],"flags":["formulas_cached_only"]}
[]
[null,"Change Proposal Impact Assessment Timetable 2016-2017"]
[]
[null,"Submission Deadline (finalised CP)","CPC Consultation",null,null,"Committee Decision"]
[null,null,"Issued","Responses Due","Responses Published","Paper Day","Meeting Date","Decisions Published"]
[null,"2016-10-10","2016-11-07","2016-12-02","2016-12-09","2016-12-05","2016-12-13","2017-01-10"]
[{"$nulls":5},"2016-12-19","2017-01-03"]
[null,"2016-11-07","2016-12-12","2017-01-06","2017-01-13","2017-01-16","2017-01-24","2017-02-07"]
[{"$nulls":5},"2017-01-23","2017-01-31"]
[null,"2016-11-28","2017-01-09","2017-02-03","2017-02-10","2017-02-13","2017-02-21","2017-03-07"]
[{"$nulls":5},"2017-02-20","2017-02-28"]
[null,"2017-01-09","2017-02-06","2017-03-03","2017-03-10","2017-03-20","2017-03-28","2017-04-11"]
[{"$nulls":5},"2017-03-27","2017-04-04"]
[null,"2017-02-06","2017-03-06","2017-03-31","2017-04-07","2017-04-17","2017-04-25","2017-05-09"]
[{"$nulls":5},"2017-04-24","2017-05-02"]
[null,"2017-03-13","2017-04-10","2017-05-05","2017-05-12","2017-05-15","2017-05-23","2017-06-06"]
[{"$nulls":5},"2017-05-22","2017-05-30"]
[null,"2017-04-10","2017-05-08","2017-06-02","2017-06-09","2017-06-19","2017-06-27","2017-07-11"]
[{"$nulls":5},"2017-06-26","2017-07-04"]
[null,"2017-05-08","2017-06-05","2017-06-30","2017-07-07","2017-07-17","2017-07-25","2017-08-08"]
[{"$nulls":5},"2017-07-24","2017-08-01"]
[null,"2017-06-12","2017-07-10","2017-08-04","2017-08-11","2017-08-14","2017-08-22","2017-09-12"]
[{"$nulls":5},"2017-08-29","2017-09-05"]
[null,"2017-07-10","2017-08-07","2017-09-01","2017-09-08","2017-09-18","2017-09-26","2017-10-10"]
[{"$nulls":5},"2017-09-25","2017-10-03"]
[null,"2017-08-07","2017-09-11","2017-10-06","2017-10-13","2017-10-16","2016-10-24","2017-11-07"]
[{"$nulls":5},"2017-10-23","2017-10-31"]
[null,"2017-09-11","2017-10-09","2017-11-03","2017-11-10","2017-11-20","2017-11-28","2017-12-12"]
[{"$nulls":5},"2017-11-27","2017-12-05"]
[null,"2017-10-09","2017-11-06","2017-12-01","2017-12-08","2017-12-04","2017-12-12","2018-01-09"]
[{"$nulls":5},"2017-12-18","2018-01-02"]
[]
[null,"Final dates for June 2017 Release",null,null,"Please note: The dates indicated should be taken as guidance as, due to the varying size and scope of CPs, ELEXON cannot guarantee that changes submitted by these dates will be included in that specific batch or presented to that specific ISG/SVG meeting."]
[null,"Final dates for November 2017 Release"]
[null,"Final dates for February 2018 Release"]