SMI Customer Transfer process

Transcription

1 Business Process and Procedures Workstream Role Requirements Paper SMI Customer Transfer process (BP10) Version Number: Status: Author: Version 0.1 Draft P Egger Date Published: 06 September 2010 File Name: 05_bppwg rrp smi customer transfer process paper v0.1 (initial).docx

2 [Table of s] Version History: Version Date Description of change Amended by v Sept 2010 Initial paper arising from discussions at workshop#18. Objective, Scope, Process Entities, Role Related Principles, Flowcharts, Attachments A, B and C. P Egger Typical RRP Preparation Process: Step# Process steps Progress Date 01 WGL provides skeleton RRP (the principles would be extracted from the Completed 06/09/10 process maps, there would be no flowchart, and there would be no Control Point Records 02 A workshop would be held on the principles and flowchart Completed Wkshop#18 03 WGL would update the RRP and republish the skeleton post-workshop Completed 06/09/10. (revised principles, new flowchart, skeleton CPR) 04 Working Group members (out-of-session) will: Review the principles, flowchart and CPR. Provide feedback on these sections. 05 WGL to update the Feedback Register based on the comments, and: Update the RRP based on the Secretariat response. Prepare a skeleton of Unique Needs for each entity and the NSMP Requirements. Publish the revised Feedback Register and RRP. 06 WG members to provide feedback on the reworked RRP 07 WGL to update the Feedback Register based on the comments, and Update the RRP based on the Secretariat response. Publish the revised Feedback Register and RRP. 08 A workshop is to be held on any priority suggestions (in the Feedback Register) that receive majority support or are specifically requested by a WG member 09 WGL to rework the RRP based on workshop outcomes and republish the RRP 10 A period of time is allowed for WG members to complete a detailed internal review of the RRP and provide Stakeholder feedback to WGL 11 WGL to revise the Feedback Register and the RRP with the stakeholder feedback comments and republish 12 A workshop is to be held on the Service Levels, Service Standards and any priority suggestions raised by WG members 13 WGL to update the RRP based on the workshop outcomes and reissue 14 A workshop is to be held once the resolution of the dependency information has been provided 15 WGL to update the RRP based on the workshop outcomes and reissue for final review ( final draft RRP ) 16 WG members to provide feedback on the final draft RRP 17 WGL to update the RRP based on the Stakeholder Feedback and reissue for final endorsement ( draft final RRP ) Page 2 of 29

3 18 A workshop is to be held to finalise endorsement of draft final PPR Legend: WGL: Blue Workshop: Dark red WG member review: Green WIP means Work In Progress Page 3 of 29

4 s: [Version History] 1. RRP No: 2. Long Title: 3. Short Title: 4. References: 5. Objective: 6. Scope: 7. SMI Functions: 8. Process Entities: 9. SMI visual context: 10. Limitations with existing NEM Procedures: 11. Role Functionality Tables: 12. Role Related Principles: 13. NSMP business process flowchart: 14. Current FRMP unique needs: 15. CSFP unique needs: 16. MDP unique needs: 17. Responsible Person unique needs: 18. DNSP unique needs: 19. Customer unique needs: 20. AEMO unique needs: 21. NSMP Requirements: 22. Infrastructure Performance Level: 23. Participant Service Levels: 24. Customer Service Standards: 25. Progress reporting: 26. Endorsement: Attachment A Flowchart Attachment B Control Point Records Attachment C Description of process steps within each entity The hyperlinks can be used to navigate to and from a chosen Line Item in the paper. 1. RRP No: NSMP BP 10 [back] 2. Long Title [back] NSMP Business Process customer transfer using the SMI 3. Short Title [back] SMI Customer Transfer process 4. References: [back] The following documents have been referred to in preparing the SMI Customer Transfer process: (a) SMI Functional Specification (draft v0.26, dated 22 April 2010); (b) NSSC Access and Contestability Policy Principles (draft v5, dated 21 April 2010); (c) Chapter 7 Rules changes (draft vxxx, dated xxx 2010); (d) (e) NSSC Load Management and Network Security protocol <<to be provided>> NSSC Communications and Data Security protocol <<to be provided>> (f) VIC AMI Process Model, as discussed and presented by WG members.[pe] Comment [PE1]: PE to locate specific Section of the Process Model that applies to this RRP Page 4 of 29

5 5. Objective: [back] The objective of the SMI Customer Transfer process is to manage the transfer of a NMI with assigned roles from one Retailer to another Retailer. 6. Scope: [back] (a) (b) The SMI Customer Transfer process includes (workshop#18, photo#10): (i) (ii) (iii) In-situ customer transfer (where the customer remains at the premise). Retrospective move-in customer transfer. Correction of a transfer in error (where a customer has been transferred in error). (iv) Role of MDP during customer transfer process. (v) Update of meter settings as a result of a new customer contract. The SMI Customer Transfer process does not include (workshop#18, photo#10): (i) (ii) 7. SMI Functions: [back] Move-in and move-out of a customer. Greenfield customer signup [initial signup] [new connection]. The SMI Customer Transfer process is supported by the following SMI functions: (a) (b) (c) (d) (e) (f) Function 7.1 Measurement and recording. Function 7.2 Remote Acquisition. Function 7.6 Load Management through a controlled load contactor or relay. Function 7.8 Supply Capacity Control Function 7.9 Home Area Network using Open Standard. Function 7.13 Meter Settings Reconfiguration. 8. Process entities: [back] The following entities are involved in the SMI Customer Transfer process: (a) Current FRMP; (b) Prospective FRMP (c) New FRMP (d) Local Retailer; (e) Responsible person; (f) DNSP; (g) Metering Data Provider; (h) Customer Service Function Provider; (i) (j) Customer; Smart Meter; (k) Market Systems; (l) MSATS; (m) AEMO. 9. SMI visual context: [back] The Schematic Diagram for that part of the SMI Customer Transfer process that occurs at the Smart Meter is shown in Diagram 9.1. Page 5 of 29

6 In the diagram, the red dotted boxes indicate the parts of the meter affected by this business process. The meter is shown with a Supply Contactor and the Meter Event Log (representing all meter Event Logs). and outbound commands for Meter Settings Reconfiguration are shown. Smart Meter Incoming power supply 7.7 switching supply contactor (ON, OFF) Supply Contactor 7.1 energy data (active, reactive) WWW Measurement element Register (data channels) A contactor 7.6 load management (dedicated load contactor) Export & Import Active and reactive Net energy Interval value Cumulative value premise general power supply Load control circuit to one appliance Smart Meter Communication Network 7.8 supply capacity limiting (normal, emergency) operation signals, messages, settings SMMS acknowledgements, setting status information, Event Log information 7.13 Meter Settings Reconfiguration 7.2 remote acquisition (pull) (active, reactive) 7.8 supply capacity commands & settings 7.12 Remote service checking 7.12 Remote service checking status (push) 7.9 HAN codes (registration, re-registration, deregistration) Acknowledgement of inbound command Meter Event Log Settings: 1 2 Supply contactor 3 Load contactor#1 4 5 Relay#1 6 7 Enabled parameters 2A relays On & OFF pulses 75% mode common 50% mode common 7.6 load management (1 or more relays) 7.20 Meter Communications: issue messages and commands Event Log information (pull) Acknowledgement, Slave HAN Device alarms 7.10 QOS & other event recording 7.9 Master HAN Device Acknowledgement, Slave HAN Device alarms Utility HAN Slave HAN Device Diagram 9.1: Schematic of Smart Meter functions that impact on the SMI Customer Transfer process This diagram provides part of the context to be considered when determining the unique needs of the Process Entities. 10. Limitations with existing NEM Procedures: [back] GRAPLs NSMP07, NSMP22 and NSMP23 detail the anticipated limitations when the SMI Customer Transfer process is applied to Smart metering Infrastructure. These documents are embedded against its title: NSMP07 Supply Contactor Operation [GRAPL07] NSMP22 Setup Conditions [GRAPL22] NSMP23 Operating Conditions [GRAPL23] 11. Role Functionality Tables: [back] The facilities and features in the SMI Functional Specification that support this business process are summarised as follows: Function 7.1 Measurement and recording. (i) (ii) Acculumated energy value (continuous measnrement); Interval energy value (30 minutes measurement). Function 7.2 Remote Acquisition. (i) (ii) Acculumated energy data (enable or disable); Interval energy data (enable or disable). Function 7.6 Load Management through a controlled load contactor or relay. Page 6 of 29

7 (i) (ii) (iii) (iv) (v) (vi) Modes of operation; Switch actions; Load control hierachy; Load switch settings; Boost fields; Demand Limit fields. Function 7.8 Supply Capacity Control (i) (ii) Capacity limits; Available settings. Function 7.9 Home Area Network using Open Standard. (i) (ii) (iii) HAN interface message type; Load control comand hierarchy; Load switch settings. Function 7.13 Meter Settings Reconfiguration. (i) (ii) (iii) (iv) (v) Settings for Single Phace Single Element meter; Settings for Single Phace Two Element meter; Settings for Three Phace Whole Current meter; Settings for Three Phace CT meter; Settings for Three Phace CT with Relay meter. This information is detailed in the spreadsheet SMI Customer Transfer role functionality tables. [Role Functionality Tables] 12. Role Related Principles: [back] The role related principles for the FRMP and the DNSP are as follows: FRMP: (a) Nil. DNSP: (a) Nil. Common: (a) (b) Meter setting changes can only be performed prospectively (workshop#18, photo#12). There is to be a mechanism to provide one of the following options (workshop#18, photo#12): a. A request for a change in settings can be sent as part of a Change Request. b. Settings can be sent as a separate request along with the transfer, and the CSFP would manage the transfer of the settings along with the Change Request. c. The new FRMP may send settings to the CSFP after the time of FRMP transfer. 13. NSMP business process flowchart: [back] The major points of interaction within and between entities for the SMI Customer Transfer process are shown in the flowchart contained in Attachment A. In particular, the flowchart shows the transactions that are external to an entity. It is these transactions that are of most interest in formulating new NEM procedures and in making changes to existing NEM procedures. Each of these transactions cross the interface between the sending entity and the receiving entity. Control points can be established at these interfaces to enable the details of the transaction at that point to be recorded. Control Point Records are the facility for recording this information. The Control Point Records for the SMI Customer Transfer process are contained in Attachment B. 14. Current FRMP unique needs: [back] <<to be determined>>. Page 7 of 29

8 15. CSFP unique needs: [back] <<to be determined>>. 16. MDP unique needs: [back] <<to be determined>>. 17. Responsible Person unique needs: [back] <<to be determined>>. 18. DNSP unique needs: [back] <<to be determined>>. 19. Customer unique needs: [back] <<to be determined>>. 20. AEMO unique needs: [back] <<to be determined>>. 21. NSMP Requirements: [back] <<to be determined>> TEST needs: The NSMP Requirements are to be tested against the following comments: Test 01: <<to be determined>> 22. Infrastructure Performance Levels: [back] There are no indicative Participant Service Levels for the SMI Customer Transfer process contained in the Functional Specification <<<BPPWG to prepare an acceptable Role related set of performacne levels>>> 23. Participant Service Levels: [back] There are no indicative Participant Service Levels for the SMI Customer Transfer process contained in the Functional Specification. <<<BPPWG to prepare an acceptable Role related set of service levels>>> 24. Customer Service Standards: [back] <<<Identify and record the service standards that are to apply to the services provided by a Role to its customer>>>. (Commence with acceptable standards identified by Roles and refine these standards through discussion with customer advocates.) 25. Progress reporting: [back] List the dates and version each time a progress report is provided to the NSSC, IEC/RMEC and/or AEMO. 26. Endorsement: [back] Record the entity that endorsed this paper (including date and version). Legend: Working Group Leader Workshop discussion WGL with assistance from WG members Page 8 of 29

9 Template comment - to be reworked Page 9 of 29

10 start start end notify end notify end end National Smart Metering Program ATTACHMENT A Flowchart [Back to Table of s] [Back to Item 13] AEMO SMI Customer Transfer flowchart in-situ & retrospective customer transfer Market Systems MSATS MSATS Market Systems Undefined MARKET SYSTEMS BP10.4 Provide Standing Data BP10.8 Customer transfer initiated BAU BAU BP10.20 Customer transfer completed BP10.22 Update settings MSATS / CATS process MSATS / CATS process CP#08 CP#10 CP#11 CUSTOMER BP10.1 Customer accepts new FRMP BP10.6 Customer agrees to contract Completion notification CP#01 CP#02 CURRENT FRMP NMI Discovery Confirm details with customer Change request sent to MSATS Negotiate contract Informed Consent Prospective FRMP BP10.23 Receive notification New FRMP Prospective FRMP BP10.02 Informed Consent received BP10.03 Confirm Standing Data BP10.05 Confirm contract details BP10.07 Transfer initiated BP10.a Yes SMI designated? BP10.b Are new settings required? Continue BP10.c Continue BP10.d Continue BP10.e No Is site Is special end read Retrospective energised? required? transfer? BP10.24 Receive notification New FRMP Prospective FRMP Special read Re-energise No BAU Yes BP10.09 Send request Yes SMI Re-en process Yes SMI Metering Data C,P,D process Yes Prospective FRMP BP10.13 Receive failure notification New FRMP CP#03 Responsible Person and DNSP In-situ customer transfer Retrospective move-in customer transfer MP(B) (C) Role of MDP flowchart MDP CP#04 Transfer complete CP#07 CP#09 CSFP Scenarios: 1. In-situ customer transfer 2. Retrospective move-in customer transfer 3. Customer transferred in error 4. Role of MDP during transfer process BP10.10 Receive request BP10.11 Validate request BP10.12 Notify validation failed No BP10.f Yes Was validation successful? BP10.14 Hold until transfer completed Yes BP10.g New FRMP? (B) Customer transferred in error flowchart No No BP10.h Transfer complete? Yes BP10.15 Send settings to meter CP#05 Retry BP10.18 Notify SMI failure No BP10.i Were settings updated? Yes BP10.19 Fault Resolution Process BP10.17 Acknowledgement message examined CP#06 BP10.21 Update settings SMART METER BP10.16 Meter settings configured BPPWG RRP SMI customer transfer flowchart v01 Page 1/3 Flowchart 1: SMI Customer Transfer in-situ & retrospective customer transfer AEMO SMI Customer Transfer flowchart customer transferred in error Market Systems Undefined MARKET SYSTEMS BP10.02 Provide Standing Data CP#01 CUSTOMER CURRENT FRMP Check settings old FRMP settings?? Check roles new FRMP Prospective FRMP BP10.a Yes Is transfer in error? No BP10.01 Check internal systems new FRMP new FRMP BP10.07 Receive failure notification NEW FRMP BP10.03 Send request CP#02 Responsible Person and DNSP Prospective settings (update meter settings as of today s date MP(B) MDP CP#03 BP10.06 Notify validation failed No CSFP Scenarios: 1. In-situ customer transfer 2. Retrospective move-in customer transfer 3. Customer transferred in error 4. Role of MDP during transfer process BP10.04 Receive request BP10.05 Validate request BP10.b Yes Was validation successful? BP10.c Yes Transfer error? No BP10.08 Confirm prospective date (B) In-situ flowchart (B) In-situ flowchart SMART METER BPPWG RRP SMI customer transfer flowchart v01 Page 2/3 Flowchart 2: SMI Customer Transfer customer transfer in error Page 10 of 29

11 end National Smart Metering Program AEMO SMI Customer Transfer flowchart Role of MDP in customer transfer Undefined MARKET SYSTEMS BAU Pending BAU MSATS BP10.02 CATS process Completed BAU MSATS BP10.02 CATS process Transfer complete CUSTOMER CURRENT FRMP BAU MDP activity (C) In-situ flowchart Confirm meter data is/will be available for transfer date NEW FRMP Responsible Person and DNSP CP#01 MP(B) MDP (C) In-situ process New MDP BP10.a Proposed transfer date? Yes BP10.01 Check internal systems No Daily routine read Special part day read SMI Metering Data C,P,D process CSFP Scenarios: 1. In-situ customer transfer 2. Retrospective move-in customer transfer 3. Customer transferred in error 4. Role of MDP during transfer process SMART METER BPPWG RRP SMI customer transfer flowchart v01 Page 3/3 Flowchart 3: SMI Customer Transfer role of MDP in customer transfer Noteworthy conditions for the SMI Customer Transfer process are: Constraints: <<to be assessed>>. Limitations: <<to be assessed>>.. Manual interventions: <<to be assessed>>.. Transitional considerations: <<to be assessed>>.. Page 11 of 29

12 ATTACHMENT B Control Point Records [Back to Table of s] [Back to Item 13] [Forward to Attachment C] The hyperlinks may be used to navigate to and from a selected Control Point Record. s of Attachment B for the SMI Customer Transfer in-situ & retrospective customer transfer: CP#01 Check Standing Data CP#02 Initiate transfer of Retailer for an in-situ customer CP#03 Send request CP#04 Notify validation failed CP#05 Settings sent to meter CP#06 Acknowledgement from meter CP#07 Notify of SMI failure CP#08 Customer transfer completed notification CP#09 Update settings in Market Systems CP#10 Retailer notified of completion of customer transfer CP#11 Retailer notified of completion of setting changes [Control Point Comparison] for the SMI Customer Transfer in-situ & retrospective customer transfer s of Attachment B for the SMI Customer Transfer customer transfer in error: CP#01 Checks Standing Data CP#02 Retailer sends request for meter settings changes to CSFP CP#03 Notify of validation failure [Control Point Comparison] for the SMI Customer Transfer customer transfer in error s of Attachment B for the SMI Customer Transfer role of MDP in customer transfer: CP#01 MDP sends response to MSATS [Control Point Comparison] for the SMI Customer Transfer role of MDP in customer transfer Page 12 of 29

13 CPR#01 in-situ & retrospective customer transfer [Back to Attachment B ] CP#01 Control Point transaction Check Standing Data WHO Sending Entity: Prospective FRMP WHO Receiving Entity: Market Systems WHAT: Objective Prospective FRMP to query Market Systems for information on meter settings and supporting details WHEN: Sending Timing NMI Meter serial number NMI status Metering installation classification Meter serial numbers Meter settings (as per Meter Settings Reconfiguration RRP) The Market Systems provide the prospective FRMP with readily available information on the meter settings Any time Multiple occasions per day Receiver Market Systems to be available at all times, with automatic turn-around of query timing WHERE: Location ID Electronically accessible Market Systems WHY: Explanation To obtain an independent check of the current FRMP held information HOW: Transaction sent by Market System communication facility transactions per day Transaction sent by Market System communication facility More than <<10>> transactions per day Page 13 of 29

14 CPR#02 in-situ & retrospective customer transfer [Back to Attachment B ] CP#02 Control Point transaction Initiate transfer of Retailer for an in-situ customer WHO Sending Entity: Prospective FRMP WHO Receiving Entity: MSATS WHAT: Objective To initiate a customer transfer in MSATS in accordance with the CATS rules and procedures. Transaction to include the following Information: NMI; Meter serial number; Relevant Change Request details, being: o??? <<<is this different to BAU?>>>. Acknowledgements: Handshake; Transaction (technical). MSATS receives the Change Request and commences the transfer process. WHEN: Sending Timing Anytime. Receiver timing Multiple occasions per day. Anytime WHERE: Location ID Electronically accessible Market Systems. WHY: Explanation To recognise the customer s choice in Retailer. HOW: Transaction sent via MSATS communication facility. transactions per day Acknowledgement sent via MSATS communication facility. More than <<50>> transactions per day on average. Page 14 of 29

15 CPR#03 in-situ & retrospective customer transfer [Back to Attachment B ] CP#03 Control Point transaction Send request WHO Sending Entity: Prospective FRMP WHO Receiving Entity: CSFP WHAT: Objective Prospective FRMP to send a request to the CSFP to change one or more settings in the meter. Transaction to include the following information: NMI; Meter serial number; Date and time to change the meter settings (as an option); The meter setting parameters to be changed. Acknowledgements: Handshake; Transaction (technical); Business (content). The CSFP receives the request. WHEN: Sending Timing Office hours on business days. Multiple occasions per day. Receiver Office hours on business days. timing WHERE: Location ID CSFP internal systems WHY: Explanation To enable the current FRMP to respond to the customer s request. HOW: Transaction sent by B2B transactions per day Acknowledgement sent by B2B More than <<10>> transactions per day on average. Page 15 of 29

16 CPR#04 new connection [Back to Attachment B ] CP#04 Control Point transaction Notify validation failed WHO Sending Entity: CSFP WHO Receiving Entity: Prospective FRMP WHAT: Objective CSFP to send a notice to prospective FRMP advising that the requested meter settings failed validation. NMI, Meter serial number; Reason code [+ additional description] for failure of validation. Acknowledgements: Handshake; Transaction (technical). The prospective FRMP is aware of the failure to validate the request. WHEN: Sending Timing As soon as the request is declared as failed. Multiple occasions per day. Receiver Failure reason to be provided within <<30>> mins after failure identified. timing WHERE: Location ID Prospective FRMP internal systems WHY: Explanation To allow the prospective FRMP to determine what additional course of action is to be undertaken. HOW: Transaction sent via B2B transactions per day Acknowledgement sent via B2B More than <<1>> transaction per day. Page 16 of 29

17 CPR#05 in-situ & retrospective customer transfer [Back to Attachment B ] CP#05 Control Point transaction Settings sent to meter WHO Sending Entity: CSFP WHO Receiving Entity: Smart Meter WHAT: Objective CSFP to send settings to Smart Meter to change its settings configuration (includes load control schedule). Command selected in SMMS. Nil The Smart Meter settings are changed. WHEN: Sending Timing Office hours on business days, subject to an agreed Service Level. Multiple occasions per day. Receiver Any time. timing WHERE: Location ID Command sent to Smart Meter at identified NMI WHY: HOW: Command sent via SMMS and SMCN transactions per day To program the settings in accordance with requests form the prospective FRMP. No acknowledgements sent to SMMS More than <<50>> transactions from SMMS per day. Page 17 of 29

18 CPR#06 in-situ & retrospective customer transfer [Back to Attachment B ] CP#06 Control Point transaction Acknowledgement from meter WHO Sending Entity: Smart Meter WHO Receiving Entity: CSFP WHAT: Objective Smart Meter to send an acknowledgement message to the CSFP. WHEN: Sending Timing NMI; Meter serial number; Command completed message with date & time stamp, if appropriate. Command failed message with date time stamp, number of remote retries and reasons for failure, if appropriate. Nil The CSFP can act on the information to either advise the prospective FRMP that the setting have been changed or retry in accordance with the Service Level. Any time. Multiple occasions per day Receiver Any time. timing WHERE: Location ID CSFP internal systems. WHY: To enable the CSFP to determine if the request was received and actioned by the Smart Meter. HOW: Message sent via SMCN to SMMS transactions per day No acknowledgements sent to Smart Meter More than <<50>> transaction per day. Page 18 of 29

19 CPR#07 in-situ & retrospective customer transfer [Back to Attachment B ] CP#07 Control Point transaction Notify of SMI failure WHO Sending Entity: CSFP WHO Receiving Entity: Prospective FRMP WHAT: Objective CSFP to send a notice to prospective FRMP advising of the failure to perform the meter setting change request. NMI; Meter serial number; Day and time of failure. Time range in which remote setting changes were attempted. retries before concluding a failure. Reason code [+ additional description] for failure (such as, comms issues, meter issues, network issues, emergency over ride operation, customer on life support, requested date is not allowed, meter not at this NMI) Advise options for completing the request (eg. SMI to be serviceable in <<4 hours>>) Acknowledgements: Handshake; Transaction (technical). The prospective FRMP is aware of the failure to perform the request. WHEN: Sending Timing As soon as the request is declared as failed. Multiple occasions per day. Receiver Failure reason to be provided within <<30>> mins after failure identified. timing WHERE: Location ID Prospective FRMP internal systems WHY: Explanation To allow the prospective FRMP to determine a new course of action HOW: Transaction sent via B2B commands per day Acknowledgement sent via B2B Less than <<1>> transaction per day. Page 19 of 29

20 CPR#08 in-situ & retrospective customer transfer [Back to Attachment B ] CP#08 Control Point transaction Customer transfer completed notification WHO Sending Entity: MSATS WHO Receiving Entity: CSFP WHAT: Objective MSATS to provide the CSFP with notification that customer transfer has been completed MSATS notification Nil The CSFP receives the advice WHEN: Sending Timing Anytime One occasion per day Receiver Anytime timing WHERE: Location ID CSFP internal systems WHY: Explanation To enable the CSFP to act on the meter setting changes requested by the prospective FRMP HOW: Transaction sent by MSATS communication facility transactions per day Not applicable More than <<50>> transactions per day Page 20 of 29

21 CPR#09 in-situ & retrospective customer transfer [Back to Attachment B ] CP#09 Control Point transaction Update settings in Market Systems WHO Sending Entity: CSFP WHO Receiving Entity: Market Ststems WHAT: Objective To update the Market Systems with the change in meter settings. WHEN: Sending Timing Transaction to include the following Information: NMI; Meter serial number; Settings that were changed. Acknowledgements: Handshake; Transaction (technical). The Market Systems have been updated to record the settings particular to the Smart Meter. Within <<1 hour>> of a successful acknowledgement from the meter. Multiple occasions per day. Receiver Any time timing WHERE: Location ID Electronically accessible Market Systems. WHY: Explanation To provide a common access point for checking the status of the meter settings configured in the meter, and for notifying appropriate entities that the settings have been modified. HOW: Transaction sent via Market Systems communication facility. transactions per day Acknowledgement sent via Market Systems communication facility. More than <<50>> transactions per day. Page 21 of 29

22 CPR#10 in-situ & retrospective customer transfer [Back to Attachment B ] CP#10 Control Point transaction Retailer notified of completion of customer transfer WHO Sending Entity: MSATS WHO Receiving Entity: New FRMP WHAT: Objective MSATS to provide the new FRMP with notification that customer transfer has been completed MSATS notification Nil The new FRMP receives the advice WHEN: Sending Timing Anytime One occasion per day Receiver Anytime timing WHERE: Location ID New FRMP internal systems WHY: Explanation To enable the new FRMP to update its internal systems and engage with the customer in the role as current FRMP HOW: Transaction sent by MSATS communication facility commands per day Not applicable More than <<50>> transactions per day Page 22 of 29

23 CPR#11 in-situ & retrospective customer transfer [Back to Attachment B ] CP#11 Control Point transaction Retailer notified of completion of setting changes WHO Sending Entity: Market Systems WHO Receiving Entity: New FRMP WHAT: Objective To provide a notice from the Market Systems to the new FRMP that the meter settings for a nominated NMI have been modified. WHEN: Sending Timing Notice to include the following information: NMI; Meter serial numbers; Meter settings change Code. Nil The new FRMP has been alerted to the change in meter settings in the Market Systems. Any time. Multiple occasions per day. Receiver Any time. timing WHERE: Location ID New FRMP internal systems. WHY: Explanation New FRMP can update its internal systems and be able to confirm operation of the new settings with the customer. HOW: Transaction sent via Market Systems communication facility. messages per day Nil More than <<50>> transactions per day. Page 23 of 29

24 CPR#01 customer transfer in error [Back to Attachment B ] CP#01 Control Point transaction Checks Standing Data WHO Sending Entity: New FRMP WHO Receiving Entity: Market Systems WHAT: Objective New FRMP to query Market Systems for information on meter settings and supporting details WHEN: Sending Timing NMI Meter serial number NMI status Metering installation classification Meter serial numbers Meter settings (as per Meter Settings Reconfiguration RRP) The Market Systems provide the new FRMP with readily available information on the meter settings Any time Multiple occasions per day Receiver Market Systems to be available at all times, with automatic turn-around of query timing WHERE: Location ID Electronically accessible Market Systems WHY: Explanation To obtain an independent check of the meter settings and associated information to determine if the customer has been transferred in error HOW: Transaction sent by Market System communication facility transactions per day Transaction sent by Market System communication facility More than <<10>> transactions per day Page 24 of 29

25 CPR#02 customer transfer in error [Back to Attachment B] CP#02 Control Point transaction Retailer sends request for meter settings changes to CSFP WHO Sending Entity: New FRMP WHO Receiving Entity: CSFP WHAT: Objective New FRMP to send a request to the CSFP to change one or more settings in the meter. Transaction to include the following information: NMI; Meter serial number; Prospective date and time to change the meter settings (as an option); The meter setting parameters to be changed. Acknowledgements: Handshake; Transaction (technical); Business (content). The CSFP receives the request. WHEN: Sending Timing Office hours on business days. Multiple occasions per day. Receiver Office hours on business days. timing WHERE: Location ID CSFP internal systems WHY: Explanation To enable the current FRMP to respond to the customer s request. HOW: Transaction sent by B2B transactions per day Acknowledgement sent by B2B More than <<1>> transactions per day on average. Page 25 of 29

26 CPR#03 customer transfer in error [Back to Attachment B] CP#03 Control Point transaction Notify of validation failure WHO Sending Entity: CSFP WHO Receiving Entity: Prospective FRMP WHAT: Objective CSFP to send a notice to new FRMP advising that the requested meter settings failed validation. NMI, Meter serial number; Reason code [+ additional description] for failure of validation. Acknowledgements: Handshake; Transaction (technical). The new FRMP is aware of the failure to validate the request. WHEN: Sending Timing As soon as the request is declared as failed. Multiple occasions per day. Receiver Failure reason to be provided within <<30>> mins after failure identified. timing WHERE: Location ID New FRMP internal systems WHY: Explanation To allow the new FRMP to determine what additional course of action is to be undertaken. HOW: Transaction sent via B2B transactions per day Acknowledgement sent via B2B More than <<1>> transaction per day. Page 26 of 29

27 CPR#01 role of MDP in customer transfer [Back to Attachment B] CP#01 Control Point transaction MDP sends response to MSATS WHO Sending Entity: MDP WHO Receiving Entity: MSATS WHAT: Objective MDP to send response to MSATS in accordance with the CATS rules and procedures. Transaction to include the following Information: NMI; Meter serial number; Relevant Change Request details, being: o??? <<<is this different to BAU?>>>. Acknowledgements: Handshake; Transaction (technical). MSATS receives the response and finalises the transfer process. WHEN: Sending Timing Any time. Multiple occasions per day. Receiver Any time timing WHERE: Location ID Electronically accessible Market Systems. WHY: Explanation To comply with the CATS rules and procedures. HOW: Transaction sent via MSATS communication facility. transactions per day Acknowledgement sent via MSATS communication facility. More than <<50>> transactions per day on average. Page 27 of 29

28 ATTACHMENT C Description of process steps within each entity [Back to Table of s] [Back to Attachment B] Description of process steps within each entity for the SMI Customer Transfer process in-situ & retrospective customer transfer: Ref # Flowchart name for step Description of step BP10.01 Customer accepts new FRMP Discussion between prospective FRMP and customer provides FRMP with an Informed Consent BP10.02 Informed Consent received Prospective FRMP receives Informed Consent BP10.03 Confirm Standing Data Prospective FRMP check Standing Data in its internal systems, and accesses Standing Data from the Market Systems to assist this task BP10.04 Provide Standing Data Market Systems provides known Standing Data BP10.05 Confirm contract details Prospective FRMP confirms contract details with the customer BP10.06 Customer agrees to contract Customer agrees to contract BP10.07 Transfer initiated Prospective FRMP initiates transfer of retailer in MSATS BP10.08 Customer transfer initiated MSATS initiates customer transfer using the CATS rules BP10.a SMI designated? Yes proceed to BP10.b No proceed to BAU BP10.b Are new settings required? Yes proceed to BP10.09 Continue proceed to BP10.c BP10.c Is site energised? Yes proceed to SMI Re-en process Continue proceed to BP10.d BP10.d Is special read required? Yes proceed to SMI Metering Data C,P,D process Continue proceed to BP10.e BP10.e Retrospective transfer? Yes proceed to BP10.10 No proceed to (A) Customer transferred in error flowchart BP10.09 Send request Prospective FRMP send settings request to the CSFP BP10.10 Receive request CSFP receives the settings change request BP10.11 Validate request The CSFP performs a technical validation (only) on the settings transaction BP10.f Was validation successful? Yes proceed to BP10.g No proceed to BP10.12 BP10.12 Notify validation failed The CSFP notifies the prospective FRMP of the validation failure BP10.13 Receive failure notification The prospective FRMP receives notification of the failure of either the validation routine or the SMI and determines what additional course of action is required BP10.g New FRMP? Yes proceed to BP10.14 No proceed to BP10.15 BP10.14 Hold until transfer completed The CSFP holds the change of settings request until it has received notification from MSATS that the transfer has been completed BP10.h Transfer complete? Yes proceed to BP10.15 No proceed to BP10.14 BP10.15 Send settings to meter The CSFP sends the setting change request to the Smart Meter BP10.16 Meter settings configured The Smart Meter receives the request and configures the settings BP10.17 Acknowledgement message The CSFP receives an acknowledgement message from the Smart Meter examined BP10.i Were settings updated? Yes proceed to BP10.21 No proceed to BP10.18 BP10.18 Notify SMI failure The CSFP notifies the prospective FRMP of the failure of the SMI BP10.19 Fault Resolution Process The CSFP undertakes a SMI fault investigation and resolution process BP10.20 Customer transfer completed MSATS completes the retailer transfer process and notifies both the CSFP and the prospective FRMP (now the new FRMP) BP10.21 Update settings The CSFP sends the changes settings to the Market Systems BP10.22 Update settings The Market Systems updates the relevant meter settings BP10.23 Receive notification The new FRMP receives notification from MSATS that the change in Page 28 of 29

29 retailer has been completed BP10.24 Receive notification The new FRMP receives notification from the Market Systems that the meter setting changes have been made Description of process steps within each entity for the SMI Customer Transfer process customer transfer in error: [Top of Attachment C] Ref # Flowchart name for step Description of step BP10.a Is transfer in error? Yes proceed to BP10.01 No end BP10.01 Check internal systems New FRMP check internal systems to clarify nature and details of error BP10.02 Provide Standing Data New FRMP check in Market Systems to obtain Standing Data to verify the data in its internal systems BP10.03 Send request The new FRMP sends a request for prospective meter setting changes to the CSFP BP10.04 Receive request The CSFP receives the meter setting change request from the new FRMP BP10.05 Validate request The CSFP validates the request BP10.b Was validation successful? Yes proceed to BP10.c No proceed to BP10.06 BP10.06 Notify validation failed The CSFP extracts the failure details and notifies the new FRMP of the validation failure BP10.07 Receive failure notification The new FRMP receives the validation failure notification BP10.d Is remote change available? Yes proceed to BP10.08 No proceed to (B) in in-situ & retrospective flowchart BP10.08 Confirm prospective date The CSFP confirms the prospective date and then follows the generic process of sending settings to the meter. Description of process steps within each entity for the SMI Customer Transfer process role of MDP in customer transfer: [Top of Attachment C] Ref # Flowchart name for step Description of step BP10.a Is transfer in error? Yes proceed to BP10.01 No end BP10.01 Check internal systems The MDP checks internal systems to determine if metering data has been obtained or will be provided by daily routine reads and informs MSATS BP10.02 CATS process MSATS receives the MDP input and changes the status of the process to completed Page 29 of 29