Electricity Information Exchange Protocols (EIEP)

Transcription

1 The Authority is currently updating the numbering and formatting in this document and an updated document will be released soon. Electricity Information Exchange Protocols (EIEP) Functional Specification Unregulated EIEPs 4 to 11 December 2013 Version 10

2 Version Release date EIEP Ref Description 1 st draft 10/05/11 all SDFG discussion document 2nd draft June 11 SDFG discussion document, amendments from May meeting 3 rd draft July 11 all Amendments from June meeting, revised EIEP5 & 6 and dictionary update 4 th draft 1 August EIEP1-3 Amendments from July meeting and Dictionary update 5 th draft September 11 all Amendments from August meeting including new split version of EIEP6 6 th draft 28 September all Amendments from September meeting and inclusion of new EIEP5 7 th draft 11 October 11 all SDFG responses to draft communicated by . 8 h draft 29 February 12 EIEP12 Minor variations to wording to align with Authority web site published version 8A draft 4 May 12 all Submission responses minor corrections 8B G July 2012 all Revisions from SDFG meetings. drafts November th draft 5/02/13 all Draft for release for consultation 9A - draft 30/08/13 all Submission (January 13 Consultation paper) responses and amendments from August 13 meeting November 2013 EIEPs 4-11 Merged set of unregulated EIEPs following mandating of EIEPs 1, 2 and 3. Sender format field decreased from 50 to 20 characters. 2

3 Functional specification for unregulated EIEPs 4 to 11 Glossary of abbreviations and terms Act Electricity Industry Act 2010 AMI Authority Advanced Metering Infrastructure Electricity Authority Code Electricity Industry Participation Code 2010 CSV EIEP FTP GXP GIP ICP MA NSP RM POC Registry SDFG UFE UoSA Comma Separated Values Electricity Information Exchange Protocol File Transfer Protocol Grid exit point Grid injection point Installation Control Point Market Administrator Network supply point Reconciliation Manager Point of connection National database that contains information on every point of connection on a network to or from a site for which electricity is supplied or generated. Standing Data Formats Group Unaccounted For Electricity Use of System Agreement YY

4 1. EIEP 4 Customer information Title: EIEP 4 Customer information Version: 10 Application: Participants: This protocol applies to all traders to provide specific customer information to distributors. Incremental customer detail changes will result in a triggered report to be sent to the distributor. Trader/Distributor Code references: Dependencies: The use of system agreement between the distributor and the trader may also set out requirements relating to the information that must be provided in this file that the distributor or the trader must comply with. Description of when this protocol applies: This protocol is used by traders to provide distributors with a snap-shot of the trader s customer base at a specific point in time or to provide distributors with incremental changes in customer information as held by the trader for the purposes as agreed between traders and distributors. Distributors will use this information to verify or update their records. Business requirements 1. The distributor and each trader must agree on the file transport mechanism by which the trader or distributor will provide information and the destination address. Non-manual interfaces use electronic file transfer either via File Transfer Protocol (FTP) or Secure File Transfer Protocol (SFTP) connectivity. In the case of FTP a security mechanism must be used to protect confidentiality. Whatever method is agreed that method must be in a format approved and published by the Authority. 2. Where information is required to be transferred using , the contents must be delivered in a secure manner and password protected. 3. This protocol will be used in the timeframes as and when agreed between parties. 4. An agent may provide data on behalf of the relevant reconciliation participant, in which case the header for EIEP 4 will identify the reconciliation participant. The appointment of an agent must be a permission function of the responsible reconciliation participant and receiving participants must allow for agents in their systems. 5..A trader or distributor must use codes that are: (a) Stipulated in this document, or (b) Approved and published by the Electricity Authority; or (c) determined in the registry and reconciliation functional specifications 6. Information provided in the file will be consistent with the terminology used in the Glossary of Standard Terms 4

5 Functional specification for unregulated EIEPs 4 to 11 published by the Authority. 7. The file must contain all mandatory information, failure to provide the required information will result in the file being deemed as incomplete. 8. Information is to be provided in accordance with the following status codes unless otherwise specified: O Optional M Mandatory where applicable C Conditional - Mandatory if available and required by recipient, otherwise optional To assist in understanding where these apply when files can be communicated both ways between participants, the relevant status code is given in the assigned column either Trader to Distributor or Distributor to Trader 9. For address information the postal address is to be populated with the billing address including PO Box numbers and RD numbers). If the Trader uses the physical installation address as the billing address, then this is to be populated to the postal address fields. When an international address is required the zip codes is to be applied in the post address post code field. 10. Parties will need to agree whether the file is to be either: (a) a snapshot, which comprises of full customer information as of an agreed date; or (b) an incremental file that provides information that has been amended or added since the last incremental or snapshot version was provided. Incremental files should be denoted as file type X. 11. If the trader or distributor becomes aware of a format error or the file is incomplete, that party must advise the other party as soon as practical after becoming aware of the issue If no agreement can be reached as to whether the file is to be a partial or full replacement for the correction of the error as noted above, then a full replacement file is required. 13. Recipients of EIEP4 files must be capable of receiving I (initial), R (complete replacement) and X (partial replacement) files. General requirements 1. This specification is based on the requirements of the Code as at January If there are any conflicts between this document and the Code, the Code will take precedence. 2. In general, all participants must provide the recipient with: i. accurate information for all points of connection at which they are responsible for the current consumption period; ii. when available, revised information for all points of connection at which they have purchased or sold electricity during any previous consumption period; iii. any additional information requested in respect of any consumption period. 3. A number of data transfers are required between participants in order for the EIEP process to take place. These data flows if not previously agreed between participants are to be those recommended by the Authority. At all times they must take place in a secure and predictable manner. 4. It is the responsibility of participants to meet the principles of the Privacy Act when exchanging customer details. 5

6 Data inputs Event data Format Trader to Validation Rules Distributor: Mandatory/ Optional/ Conditional Header record type Char 3 M HDR indicates the row is a header record type File type Char 7 M Customer Information Listing - CUSIN Version of EIEP Num 3.1 M Version of EIEP protocol that is being used for this file. Sender Char 20 M Name of sending party. Participant identifier to be used if the sender is a participant. Sent on behalf of Char 4 C Participant identifier of party on whose behalf consumption data is provided. Recipient Participant identifier Char 4 M Valid recipient participant identifier Report run date DD/MM/YYYY M Date the report is run Report run time HH:MM:SS M Time the report is run Unique File identifier Char 15 M Number that uniquely identifies the file Number of detail records NUM 8 M Total number of DET records in report Report period start date DD/MM/YYYY M Report run start date (inclusive) Report period end date DD/MM/YYYY M Report run end date (inclusive) Utility type Char 1 M G (Gas) or E (Electricity) File status Char 1 M I = Initial or R = Replacement or X = Replace only those ICPs contained in this replacement file Event data Format Trader to Validation Rules Distributor: Mandatory/ Optional/ Conditional Detail record type Char 3 M DET indicates the row is a detail record. ICP identifier Char 15 M ICP identifier means a unique identifier for an ICP created by a distributor in accordance with clause 1 of Schedule

7 Functional specification for unregulated EIEPs 4 to 11 Customer name Char 100 M Legal name or the name of the customer. Multiple names to be concatenated into one field 7

8 Phone Number Home Char 15 C Home land line phone Number Phone Number Work Char 15 C Number person can be contacted at during business hours. Phone Number Mobile Char 15 C Cell phone number Fax number Char 15 C Fax number address Char 50 C address Postal free form Char 30 C All postal fields can be Null. But are mandatory if available Postal address unit Char 25 C Sub dwelling number; Level of sub dwelling Postal address num Char 25 C Number issued by government agency or local government authority that identifies a point or location on a street for postal purposes. Postal address street Char 30 C Official road name issued by government agency or local government authority. Postal Box/RD Char 30 C Number assigned a postal delivery box or rural delivery number. Postal address suburb Char 30 C A bounded locality within a city, town or shire principally of urban character. Postal address town Char 30 C An officially recognised and named population centre, defined within a geographic boundary. Postal address postcode Char 30 C The post code assigned by NZ post (zip code if outside NZ). Postal address country Char 30 C The country for postal information Event date DD/MM/YYYY M In relation to an ICP, means the date on which an arrangement between a customer and a trader for the supply of electricity at the ICP comes into effect Disconnection restriction Char 1 C Y for YES or N for No for Medically Dependent customers or other critical disconnection restrictions. Medical restriction type Char3 C MDN if medical dependent customer notified. MDV if medical dependent customer verified. Customer no. Num 15 C Trader s customer number. (the identifier that the trader assigns to the customer which remains the same across all the connections for the customer) Consumer no Num 15 C Trader s consumer number defined as the trader s unique ID that links the premises and the 8

9 Functional specification for unregulated EIEPs 4 to 11 consumer. If not available then use null. Customer Title Char 20 C Separated customer title details Surname Char 100 C Separated customer surname details (populate with separated company name(s) if customer includes a company) First name Char 100 C Separated customer first name details Finalled date DD/MM/YYYY C In relation to a ICP, means the date on which an arrangement between a customer and a trader for the supply of electricity at the ICP was terminated. For use in incremental files only. Protocol specifications: 1. The information is to be provided as a comma delimited text file. Commas are therefore prohibited within fields. For customer names that require separation a tilde character (~) should be used. This is the only provision for the use of a tilde character. 2. Each formatted file will consist of one or more records, with each record being a single line of text as defined in the business rules. Records are to be delimited with one of the following: (a) a carriage return character and a line feed character combination (ASCII characters 13 and 10) commonly used in Windows based programs, or (b) a line feed character (ASCII character 10) commonly used in Unix based programs, or (c) a carriage return character (ASCII character 13) commonly used in Mac based programs. 3. Data fields within files are defined using the attributes in the table following these specifications. 4. Matching of file names, code list values, etc, are to be case insensitive. 5. Each data file will contain only one header but may contain any number of detail records. 6. The first record of a file contains Header information followed by zero or more detail lines. 7. The following file naming convention is to be used with this file: Sender + Utility Type + Recipient + File Type + Report Month + Report Run Date + UniqueID# (e.g. hhmm run time, or ICP but limited to Char(60)) with an extension of.txt and with the components concatenated using the underscore character, to assist readability. e.g. TRUS_E_UNET_ CUSIN_200007_ _1232.TXT [Char4_Char1_Char4_ Char7_yyyymm_yyyymmdd_UniqueID.TXT] Data outputs: 9

10 9.2 Table of codes used in EIEP List of attributes to define data fields used in EIEP4 Logical format Data type Rules Example INT (n) Integer ASCII representation of an integer number (ie no decimals), no leading zeros, no spaces, a leading - if negative (no sign if positive), with 1 to n digits. Numbers only: ASCII characters 48 to 57, and 45 where INT (4) applicable. NUM (n.d) Decimal ASCII representation of a decimal number (ie a rational number), no spaces, a leading - if negative (no sign if positive), with up n digits including up to (n minus d) digits to the left of the decimal place, and up to d digits to the right of the decimal place. NUM (6.2) For integers, the decimal point is not required. NUM (6.3) A decimal point on its own must not be used to represent zero (use 0 ) Trailing zeros are optional. 8 No leading zeros other than when the number starts with 0. Numbers only: ASCII characters 48 to 57, and 45/46 where applicable. CHAR (n) Text Up to n characters (ASCII characters 32 to 43 and 45 to 126 only). As commas (ASCII character 44) are used as field separators, they must not be used within the field data (it is recommended that any commas found in source data be changed to a semi-colon (ASCII character 59) when files are created. Fields must not contain any leading or trailing spaces. The quick brown fox DATE Date ASCII format with: Year represented as: YYYY for century and year Month represented as: MM to display leading zero Day represented as DD to display leading zero ASCII format for any separators used TIME Time ASCII in 24 hour format Hour represented as HH with leading zeros Minutes represented as MM with leading zeros Seconds represented as SS with leading zeros ASCII format for any separators used YYYYMMDD e.g DD/MM/YYYY e.g. 16/02/2005 HH:MM:SS e.g. 13:15:01 HH:MM e.g. 13:15 10

11 Functional specification for unregulated EIEPs 4 to 11 Logical format Data type Rules Example Note: both NZST and NZDT will be used and will be indicated as necessary DATETIME Date/Time ASCII format with same rules as both Date and Time Data Types YYYYMMDDHHMMSS e.g NULL Null Field contains no data ASCII character set used in EIEP4 Character ASCII 32 Space 33! 34 " 35 # 36 $ 37 % 38 & 39 ' 40 ( 41 ) 42 * / : 59 ; 60 < 61 = 62 > Character ASCII 65 A 66 B 67 C 68 D 69 E 70 F 71 G 72 H 73 I 74 J 75 K 76 L 77 M 78 N 79 O 80 P 81 Q 82 R 83 S 84 T 85 U 86 V 87 W 88 X 89 Y 90 Z 91 [ 92 \ 93 ] 94 ^ 95 _ Character ASCII 97 a 98 b 99 c 100 d 101 e 102 f 103 g 104 h 105 i 106 j 107 k 108 l 109 m 110 n 111 o 112 p 113 q 114 r 115 s 116 t 117 u 118 v 119 w 120 x 121 y 122 z 123 { } 126 ~ 101

12 63? 96 ` 100

13 Functional specification for unregulated EIEPs 4 to EIEP 5 Service interruptions 2.1 EIEP 5 is comprised of two files; EIEP 5A is applicable for planned service interruptions to traders. EIEP 5B is applicable for unplanned service interruptions to traders EIEP 5A Planned Service Interruptions Title: EIEP 5A Planned Service Interruptions Version: 10 Application: Participants: This protocol applies to all distributors to provide information to traders relevant for planned service interruptions. Distributor/Trader Code references: Dependencies: The use of system agreement between the distributor and the trader may also set out requirements relating to the information that must be provided in this file that the distributor or the trader must comply with. Description of when this protocol applies: This protocol is used by distributors to advise traders the information relevant to planned service interruptions. The file may be used by traders to record details of planned service interruptions within their customer information systems. Business requirements: 1. The distributor and trader must agree on the file transport mechanism by which the trader or distributor will provide information and the destination address.. Non-manual interfaces use electronic file transfer either via File Transfer Protocol (FTP) or Secure File Transfer Protocol (SFTP) connectivity. In the case of FTP a security mechanism must be used to protect confidentiality. Whatever method is agreed that method must be in a format approved and published by the Authority. 2. Where information is required to be transferred using , the contents must be delivered in a secure manner and password protected. 3. This protocol will be used in the timeframes when required as agreed between parties. 4. An agent may provide data on behalf of the relevant reconciliation participant, in which case the header will identify the reconciliation participant. The appointment of an agent must be a permission function of the responsible reconciliation participant and receiving participants must allow for agents in their systems. 5. A trader or distributor must only use codes that are (a) Stipulated in this document; 101

14 (b) Approved and published by the Electricity Authority; or (c) determined in the registry and reconciliation functional specifications. 6. Information provided in the file will be consistent with the terminology used in the Glossary of Standard Terms published by the Authority. 7. The file must contain all mandatory information, failure to provide the required information will result in the file being deemed as incomplete. 8. Information is to be provided in accordance with the following status codes unless otherwise specified: O M C Optional Mandatory where applicable Conditional - Mandatory if available and required by recipient, otherwise optional To assist in understanding where these apply when files can be communicated both ways between participants, the relevant status code is given in the assigned column either Trader to Distributor or Distributor to Trader. 9. This protocol provides for both single event and multiple event service interruptions. For single event service interruptions, the distributor provides a single off-time and a single on-time on the same day for a list of affected installation control points (ICPs). 10. For multiple event service interruptions where the power is to be interrupted on consecutive or nearconsecutive days the distributor will provide a list of affected ICPs and the appropriate dates and off/on times. 11. The protocol can also be used to advise of a previously notified planned outage being rescheduled or cancelled by means of the appropriate communication type code in the file. 12. This file is to be used by distributors to give traders prior warning that a planned service interruption will affect designated ICPs in a particular area on a given date or dates, including the power off/power on times. There is also provision for alternative date or dates if the planned service interruption cannot take place on the original start date(s). 13. The distributor event field allows for more than one entry. 14. The distributor event number must include the original event number in the distributor event number field if rescheduling or cancelling a file. There is to be one file per change and the communication type code will determine what that change is. 15. The recipient is to ensure that they apply the files in the order that they are received, with the latest information being the most current. 16. Where, in accordance with the use of system agreement, traders are required to provide advance notification to customers of a planned service interruption the planned service interruption file will be used as a source file for a mail merge. 17. If the trader or distributor becomes aware of a format error or the file is incomplete, that party must advise the other party as soon as practical after becoming aware of the issue If no agreement can be reached as to whether the file is to be a partial or full replacement for the correction of the error as noted above, then a full replacement file is required. General requirements 1. This specification is based on the requirements of the Code as at January If there are any conflicts 100

15 Functional specification for unregulated EIEPs 4 to 11 between this document and the Code, the Code will take precedence. 2. In general, all participants must provide the recipient with: i. accurate information for all points of connection at which they are responsible for the current consumption period; ii. when available, revised information for all points of connection at which they have purchased or sold electricity during any previous consumption period; iii. any additional information requested in respect of any consumption period. 3. A number of data transfers are required between participants in order for the EIEP process to take place. These data flows if not previously agreed between participants are to be those recommended by the Authority. At all times they must take place in a secure and predictable manner. 4. It is the responsibility of participants to meet the principles of the Privacy Act when exchanging customer details. Data inputs: Event data Format Distributor to Trader: Mandatory/ Optional/ Conditional Validation Rules Header record type Char 3 M HDR indicates the row is a header record type File type Char 7 M Planned Service Interruption PLINT Version of EIEP Num 3.1 M Version of EIEP protocol that is being used for this file. Sender Char 20 M Name of sending party. Participant identifier to be used if the sender is a participant. Sent on behalf of Char 4 C Participant identifier of party on whose behalf data is provided. Recipient Participant identifier Char 4 M Valid recipient participant identifier Report run date DD/MM/YYYY M Date the report is run Report run time HH:MM:SS M Time the report is run Unique File identifier Char 15 M Number that uniquely identifies the file Number of detail records Num 8 M Total number of records in report Communication Type Char 3 M As per table of Planned Outage Communication Type Codes Report period start date DD/MM/YYYY M Report run start date (inclusive) Report period end date DD/MM/YYYY M Report run end date (inclusive) Utility type Char 1 M G (Gas) or E (Electricity) 15

16 Event data Format Distributor to Trader: Mandatory/ Optional/ Conditional Validation Rules Detail record type Char 3 M DET indicates the row is a detail record. ICP identifier Char 15 M ICP identifier means a unique identifier for an ICP created by a distributor in accordance with clause 1 of Schedule 11.1 Feeder Char 20 C Transformer and feeder number if available. Street/area affected Char 255 M Best description of locality affected Interruption reason Char 50 M Reason for planned interruption Number of interruptions notified Distributor event number Interruption 1 start date Interruption 1 restore date Interruption 1 start time Interruption 1 expected or actual restore time Interruption 1 alternative date Interruption 2 start date Interruption 2 restore date Interruption 2 start time Num 1 M Number of planned interruptions notified (up to a maximum of 5) Char 15 M Distributor s unique reference number for service interruption DD/MM/YYYY M Date first interruption to commence DD/MM/YYYY M Most accurate indication of date when power will be restored for first interruption HH:MM M Start time for first interruption HH:MM M Most accurate indication of time when power will be restored for first interruption DD/MM/YYYY C Alternative date if first planned interruption cannot proceed on proposed start date. Can be Null DD/MM/YYYY C Date second interruption to commence DD/MM/YYYY C Most accurate indication of date when power will be restored for second interruption HH:MM C Start time for second interruption 16

17 Functional specification for unregulated EIEPs 4 to 11 Interruption 2 expected or actual restore time Interruption 2 alternative date Interruption 3 start date Interruption 3 restore date Interruption 3 start time Interruption 3 expected or actual restore time Interruption 3 alternative date Interruption 4 start date Interruption 4 restore date Interruption 4 start time Interruption 4 expected or actual restore time Interruption 4 alternative date Interruption 5 start date Interruption 5 restore date Interruption 5 start time Interruption 5 expected or actual restore time HH:MM C Most accurate indication of time when power will be restored for second interruption DD/MM/YYYY C Alternative date if second planned interruption cannot proceed on proposed start date. Can be Null DD/MM/YYYY C Date third interruption to commence DD/MM/YYYY C Most accurate indication of date when power will be restored for third interruption HH:MM C Start time for third interruption HH:MM C Most accurate indication of time when power will be restored for third interruption DD/MM/YYYY C Alternative date if third planned interruption cannot proceed on proposed start date. Can be Null DD/MM/YYYY C Date fourth interruption to commence DD/MM/YYYY C Most accurate indication of date when power will be restored for fourth interruption HH:MM C Start time for fourth interruption HH:MM C Most accurate indication of time when power will be restored for fourth interruption DD/MM/YYYY C Alternative date if fourth planned interruption cannot proceed on proposed start date. Can be Null DD/MM/YYYY C Date fifth interruption to commence DD/MM/YYYY C Most accurate indication of date when power will be restored for fifth interruption HH:MM C Start time for fifth interruption HH:MM C Most accurate indication of time when power will be restored for fifth interruption 17

18 Interruption 5 alternative date DD/MM/YYYY C Alternative date if fifth planned interruption cannot proceed on proposed start date. Can be Null 18

19 Functional specification for unregulated EIEPs 4 to 11 Protocol specifications: 1. The information is to be provided as a comma delimited text file. Commas are therefore prohibited within fields. 2. Each formatted file will consist of one or more records, with each record being a single line of text as defined in the business rules. Records are to be delimited with one of the following: (a) (b) (c) a carriage return character and a line feed character combination (ASCII characters 13 and 10) commonly used in Windows based programs, or a line feed character (ASCII character 10) commonly used in Unix based programs, or a carriage return character (ASCII character 13) commonly used in Mac based programs. 3. Data fields within files are defined using the attributes in the table following these specifications. 4. Matching of file names, code list values, etc, are to be case insensitive. 5. Each data file will contain only one header by may contain any number of detail records. 6. The first record of a file contains Header information followed by zero or more detail lines. 7. The following file naming convention is to be used with this file: Sender + Utility Type + Recipient + File Type + Report Month + Report Run Date + UniqueID# (e.g. hhmm run time, or ICP but limited to Char(60)) with an extension of.txt and with the components concatenated using the underscore character, to assist readability. e.g. TRUS_E_UNET_ PLINT_200007_ _1232.TXT [Char4_Char1_Char4_ Char7_yyyymm_yyyymmdd_UniqueID.TXT] Data outputs: 19

20 10.2 Table of codes used in EIEP5A List of attributes to define data fields as used in EIEP5A. Logical Format Data type Rules Example INT (n) Integer ASCII representation of an integer number (ie no decimals), no leading zeros, no spaces, a leading - if negative (no sign if positive), with 1 to n digits. Numbers only: ASCII characters 48 to 57, and 45 where applicable. INT (4) NUM (n.d) Decimal ASCII representation of a decimal number (ie a rational number), no spaces, a leading - if negative (no sign if positive), with up n digits including up to (n minus d) digits to the left of the decimal place, and up to d digits to the right of the decimal place. NUM (6.2) For integers, the decimal point is not required. A decimal point on its own must not be used to represent zero (use 0 ) NUM (6.3) Trailing zeros are optional. 8 20

21 Functional specification for unregulated EIEPs 4 to 11 Logical Format Data type Rules Example No leading zeros other than when the number starts with 0. Numbers only: ASCII characters 48 to 57, and 45/46 where applicable. CHAR (n) Text Up to n characters (ASCII characters 32 to 43 and 45 to 126 only). As commas (ASCII character 44) are used as field separators, they must not be used within the field data (it is recommended that any commas found in source data be changed to a semi-colon (ASCII character 59) when files are created. Where customer names require separation, a tilde character (~) should be used. Fields must not contain any leading or trailing spaces. The quick brown fox DATE Date ASCII format with: Year represented as: YYYY for century and year Month represented as: MM to display leading zero Day represented as DD to display leading zero ASCII format for any separators used TIME Time ASCII in 24 hour format Hour represented as HH with leading zeros Minutes represented as MM with leading zeros Seconds represented as SS with leading zeros ASCII format for any separators used Note: both NZST and NZDT will be used and will be indicated as necessary YYYYMMDD e.g DD/MM/YYYY e.g. 16/02/2005 HH:MM:SS e.g. 13:15:01 HH:MM e.g. 13:15 DATETIME Date/Time ASCII format with same rules as both Date and Time Data Types YYYYMMDDHHMMSS e.g NULL Null Field contains no data ASCII character set for use within fields of EIEP5A. Character ASCII 32 Space 33! 34 " 35 # 36 $ Character ASCII 65 A 66 B 67 C 68 D 69 E 21 Character ASCII 97 a 98 b 99 c 100 d 101 e 102 f

22 37 % 22

23 Functional specification for unregulated EIEPs 4 to & 39 ' 40 ( 41 ) 42 * / : 59 ; 60 < 61 = 62 > 63? 70 F 71 G 72 H 73 I 74 J 75 K 76 L 77 M 78 N 79 O 80 P 81 Q 82 R 83 S 84 T 85 U 86 V 87 W 88 X 89 Y 90 Z 91 [ 92 \ 93 ] 94 ^ 95 _ 96 ` 103 g 104 h 105 i 106 j 107 k 108 l 109 m 110 n 111 o 112 p 113 q 114 r 115 s 116 t 117 u 118 v 119 w 120 x 121 y 122 z 123 { } Table 2 Communication types for use in EIEP 5A Communication type PLS Description Planned Service Interruption - Initial Advice PLR Planned Service Interruption - Rescheduled PLC Planned Service Interruption - Cancellation 23

24 10.4 EIEP 5B Unplanned Service interruptions Title: EIEP 5B Unplanned Service Interruptions Version: 10 Application: Participants: This protocol applies to all distributors to provide information to traders for unplanned service interruptions. Distributor/Trader Code references: Dependencies: The use of system agreement between the distributor and the trader may also set out requirements relating to the information that must be provided in this file that the distributor or the trader must comply with. Description of when this protocol applies: This protocol is used by distributors to advise traders the information relevant to unplanned service interruptions. The file may be used by traders to record details of unplanned service interruptions within their customer information systems. Business requirements: 1. The distributor and each trader must agree on the file transport mechanism by which the trader or distributor will provide information and the destination address. Non-manual interfaces use electronic file transfer either via File Transfer Protocol (FTP) or Secure File Transfer Protocol (SFTP) connectivity. In the case of FTP a security mechanism must be used to protect confidentiality. Whatever method is agreed that method must be in a format approved and published by the Authority. 2. Where information is required to be transferred using , the contents must be delivered in a secure manner and password protected. 3. This protocol will be used in the timeframes when required as agreed between parties. 4. An agent may provide data on behalf of the trader, in which case the header will identify the relevant parties. The appointment of an agent must be a permission function of the responsible reconciliation participant and receiving participants must allow for agents in their systems. 5. Only codes that are stipulated in this document, or are Electricity Authority approved published codes, or are codes determined in the registry and reconciliation functional specifications are to be used 6. Information provided in the file will be consistent with the terminology used in the Glossary of Standard Terms published by the Authority. 7. The file must contain all mandatory information, failure to provide the required information will result in 24

25 Functional specification for unregulated EIEPs 4 to 11 the file being deemed as incomplete. 8. Information is to be provided in accordance with the following status codes unless otherwise specified: O Optional M Mandatory where applicable C Conditional - Mandatory if available and required by recipient, otherwise optional To assist in understanding where these apply when files can be communicated both ways between participants, the relevant status code is given in the assigned column either Trader to Distributor or Distributor to Trader 9. The format file can be used for initial advice of unplanned interruptions to supply, updates on the interruption to supply, and for advice when the supply has been restored. 10. For unplanned service interruptions this file can be used by distributors to notify traders that an interruption to the power supply in a particular area has occurred. A list of the ICPs affected should be included if available. 11. This protocol can also be used for status updates on unplanned service interruptions. Should a group of ICPs be restored earlier, or should a handful be restored later, any update should be sent using the same event number. 12. The recipient is to ensure that they apply the files in the order that they are received, with the latest information being the most current. 13. The distributor even field allows for more than one entry. 14. The distributor event number must include the original event number in the distributor event number field if rescheduling or cancelling a file. There is to be one file per change and the communication type code will determine what that change is. 15. For log jobs if the designation is N, the distributor is requesting that the trader not send any further notification through regarding any fault calls the trader receives unless it is for safety or emergency reasons, or additional details have been provided that may be useful to locate service interruption restoration. 16. If the trader or distributor becomes aware of a format error or the file is incomplete, that party must advise the other party as soon as practical after becoming aware of the issue If no agreement can be reached as to whether the file is to be a partial or full replacement for the correction of the error as noted above, then a full replacement file is required. General requirements 1. This specification is based on the requirements of the Code as at January If there are any conflicts between this document and the Code, the Code will take precedence. 2. In general, all participants must provide the recipient with: i. accurate information for all points of connection at which they are responsible for the current consumption period; ii. when available, revised information for all points of connection at which they have purchased or sold electricity during any previous consumption period; iii. any additional information requested in respect of any consumption period. 3. A number of data transfers are required between participants in order for the EIEP process to take place. 25

26 These data flows if not previously agreed between participants are to be those recommended by the Authority. At all times they must take place in a secure and predictable manner. 4. It is the responsibility of participants to meet the principles of the Privacy Act when exchanging customer details. Data Inputs: Event data Format Distributor to Trader: Mandatory/ Optional/ Conditional Validation Rules Header record type Char 3 M HDR indicates the row is a header record type File type Char 7 M Unplanned Service Interruption UPINT Version of EIEP Num 3.1 M Version of EIEP protocol that is being used for this file. Sender Char 20 M Name of sending party. Participant identifier to be used if the sender is a participant. Sent on behalf of Char 4 C Participant identifier of party on Recipient Participant identifier whose behalf consumption data is provided. Char 4 M Valid recipient participant identifier Report run date DD/MM/YYYY M Date the report is run Report run time HH:MM:SS M Time the report is run Unique File identifier Char 15 M Number that uniquely identifies the file Number of detail records Num 8 M Total number of records in report Communication Type Char 3 M As per table of Unplanned Service Interruption Communication Type Codes Report period start date DD/MM/YYYY M Report run start date (inclusive) Report period end date DD/MM/YYYY M Report run end date (inclusive) Utility type Char 1 M Type of energy supply; G = Gas; or E = Electricity Event data Format Distributor to Validation Rule Trader: Mandatory/ optional Detail record type Char 3 M DET indicates the row is a detail record. 26

27 Functional specification for unregulated EIEPs 4 to 11 ICP identifier Char 15 M ICP identifier means a unique identifier for an ICP created by a distributor in accordance with clause 1 of Schedule 11.1 Feeder Char 20 O Transformer and feeder number if available. Street/area affected Char 255 M Best description of locality affected Log jobs Char 1 M Confirm if trader to advise of any new interruptions reported in same area. Interruption reason Char 50 M Description of cause of unplanned interruption to supply Distributor event number Char 15 C Distributor s unique reference number for unplanned service interruption Interruption start date DD/MM/YYYY M Date interruption commenced Interruption restore date DD/MM/YYYY M Most accurate indication of date when power will be restored Interruption start time HH:MM M Time interruption started Interruption expected or actual restore time HH:MM M Most accurate indication of time when power will be restored Protocol specifications: 1. The information is to be provided as a comma delimited text file. Commas are therefore prohibited within fields. 2. Each formatted file will consist of one or more records, with each record being a single line of text as defined in the business rules. Records are to be delimited with one of the following: (a) (b) (c) a carriage return character and a line feed character combination (ASCII characters 13 and 10) commonly used in Windows based programs, or a line feed character (ASCII character 10) commonly used in Unix based programs, or a carriage return character (ASCII character 13) commonly used in Mac based programs. 3. Data fields within files are defined using the attributes in the table following these specifications. 4. Matching of file names, code list values, etc, are to be case insensitive. 5. Each data file will contain only one header but can contain any number of detail records. 6. The first record of a file contains Header information followed by zero or more detail lines. 7. The following file naming convention is to be used with this file: Sender + Utility Type + Recipient + File Type + Report Month + Report Run Date + UniqueID# (e.g. hhmm run time, or ICP but limited to Char(60)) with an extension of.txt and with the components concatenated using the underscore character, to assist readability. e.g. TRUS_E_UNET_ UPINT_200007_ _1232.TXT [Char4_Char1_Char4_ Char7_yyyymm_yyyymmdd_UniqueID.TXT] Data outputs: 27

28 10.5 Table of codes used in EIEP5B List of attributes to define data fields as used in EIEP5B Logical Format Data type Rules Example INT (n) Integer ASCII representation of an integer number (ie no decimals), no leading zeros, no spaces, a leading - if negative (no sign if positive), with 1 to n digits. Numbers only: ASCII characters 48 to 57, and 45 where INT (4) applicable. NUM (n.d) Decimal ASCII representation of a decimal number (ie a rational number), no spaces, a leading - if negative (no sign if positive), with up n digits including up to (n minus d) digits to the left of the decimal place, and up to d digits to the right of the decimal place. NUM (6.2) For integers, the decimal point is not required. NUM (6.3) A decimal point on its own must not be used to represent zero (use 0 ) Trailing zeros are optional. 8 No leading zeros other than when the number starts with 0. Numbers only: ASCII characters 48 to 57, and 45/46 where applicable. CHAR (n) Text Up to n characters (ASCII characters 32 to 43 and 45 to 126 only). As commas (ASCII character 44) are used as field separators, they must not be used within the field data (it is recommended that any commas found in source data be changed to a semi-colon (ASCII character 59) when files are created. Fields must not contain any leading or trailing spaces. The quick brown fox DATE Date ASCII format with: Year represented as: YYYY for century and year Month represented as: MM to display leading zero Day represented as DD to display leading zero ASCII format for any separators used YYYYMMDD e.g DD/MM/YYYY e.g. 16/02/2005 TIME Time ASCII in 24 hour format Hour represented as HH with leading zeros Minutes represented as MM with leading zeros Seconds represented as SS with leading zeros ASCII format for any separators used Note: both NZST and NZDT will be used and will be indicated as necessary HH:MM:SS e.g. 13:15:01 HH:MM e.g. 13:15 28

29 Functional specification for unregulated EIEPs 4 to 11 Logical Format Data type Rules Example DATETIME Date/Time ASCII format with same rules as both Date and Time Data Types YYYYMMDDHHMMSS e.g NULL Null Field contains no data ASCII character set for use with fields of EIEP5B Character ASCII 32 Space 33! 34 " 35 # 36 $ 37 % 38 & 39 ' 40 ( 41 ) 42 * / : 59 ; 60 < 61 = 62 > 63? Character ASCII 65 A 66 B 67 C 68 D 69 E 70 F 71 G 72 H 73 I 74 J 75 K 76 L 77 M 78 N 79 O 80 P 81 Q 82 R 83 S 84 T 85 U 86 V 87 W 88 X 89 Y 90 Z 91 [ 92 \ 93 ] 94 ^ 95 _ 96 ` Character ASCII 97 a 98 b 99 c 100 d 101 e 102 f 103 g 104 h 105 i 106 j 107 k 108 l 109 m 110 n 111 o 112 p 113 q 114 r 115 s 116 t 117 u 118 v 119 w 120 x 121 y 122 z 123 { } 29

30 Table 3 Communication types for use in EIEP 5B Communication type UPI UPU UPR Description Unplanned Service Interruption - Initial Advice Unplanned Service Interruption - Update Unplanned Service Interruption - Supply Restored 30

31 Functional specification for unregulated EIEPs 4 to EIEP 6 Fault notification and service requests EIEP 6 is comprised of two files, EIEP 6A is applicable for reporting of customer faults to distributors, whereas EIEP 6B allows the transmission of both fault and works service requests to and from traders and their service providers (who in some cases may also be the distributor) EIEP 6A: Initiation file Title: EIEP 6A Fault notification initiation Version: 10 Application: Participants: This protocol applies to traders and distributors to provide information relating to faults. Trader/Distributor Code references: Dependencies: The use of system agreement between the distributor and the trader may also set out requirements relating to the information that must be provided in this file that the distributor or the trader must comply with. Description of when this protocol applies: This protocol format is to be forwarded by traders when notifying distributors of fault notifications and providing service providers fault detail information. The protocol is used by distributors to notify traders and service providers of fault detail information. Business requirements: 1. The distributor and each trader must agree on the file transport mechanism by which the trader or distributor will provide information and the destination address. Non-manual interfaces use electronic file transfer either 31

32 via File Transfer Protocol (FTP) or Secure File Transfer Protocol (SFTP) connectivity. In the case of FTP a security mechanism must be used to protect confidentiality. Whatever method is agreed that method must be in a format approved and published by the Authority. 2. Where information is required to be transferred using , the contents must be delivered in a secure manner and password protected. 3. This protocol will be used in the timeframes when required as agreed between parties. 4. An agent may provide data on behalf of the trader, in which case the header will identify the relevant parties. The appointment of an agent must be a permission function of the responsible reconciliation participant and receiving participants must allow for agents in their systems. 5. Only codes that are stipulated in this document, or are Electricity Authority approved published codes, or are codes determined in the registry and reconciliation functional specifications are to be used 6. Information provided in the file will be consistent with the terminology used in the Reference of Standard Terms published by the Authority. 7. The file must contain all mandatory information, failure to provide the required information will result in the file being deemed as incomplete. 8. Information is to be provided in accordance with the following status codes unless otherwise specified: O M C Optional Mandatory where applicable Conditional - Mandatory if available and required by recipient, otherwise optional To assist in understanding where these apply when files can be communicated both ways between participants, the relevant status code is given in the assigned column either Trader to Distributor or Distributor to Trader. 9. One file is to be sent for each service request. The benefit of single job files is that they are easier to track. 10. The file is not designed to be a complete account of all possible required information. 11. The Initiation file should include a Job Type Code based on the description of the fault given by the customer or the caller. 12. Status Update and Closure information from the distributor should include a Job Status update code to update the trader. One job or fault can have different status update codes, for example the initial response should be either Accepted (ie the service request is in the correct format and has been successfully entered into the distributor s system) or Rejected (please note that if a job is Rejected a Reason Code should also be given such as DUP if the job is a duplicate of one sent previously); INC (if the service request is incomplete). If a job is rejected as INC a new Service Request would need to be raised. 13. Job Closure Codes can be signified by including the appropriate Job status code (eg CM) and Additional Job Closure code (non-itemised) Information Codes (eg NWF). As an alternative to Job Closure Codes, itemised job closure codes, or full text descriptions -codes/descriptions can be used. For example Voltage Level (HV or LV); Charge Code; Asset/Equipment Description Code; Reason/Action Code. Job Closure (Equipment What Faulted Issue Remedy) As a minimum one of the three closure code options must be completed when the file is being returned to the trader. 32

33 Functional specification for unregulated EIEPs 4 to 11 General requirements 1. This specification is based on the requirements of the Code as at January If there are any conflicts between this document and the Code, the Code will take precedence. 2. In general, all participants must provide the recipient with: i. accurate information for all points of connection at which they are responsible for the current consumption period; ii. when available, revised information for all points of connection at which they have purchased or sold electricity during any previous consumption period; iii. any additional information requested in respect of any consumption period. 3. A number of data transfers are required between participants in order for the EIEP process to take place. These data flows if not previously agreed between participants are to be those recommended by the Authority. At all times they must take place in a secure and predictable manner. 4. It is the responsibility of participants to meet the principles of the Privacy Act when exchanging customer details. Data Inputs: 1. The first file to initiate the request is sent by the initiator (usually the trader) to the distributor or retail service provider. 2. The second and any subsequent files are for the recipient of the initiation file (usually the distributor or retail service provider) to provide fault status update and closure information to the trader. Event Data Format Trader to Validation Rule Distributor: Mandatory/ Optional/ Conditional Header record type Char 3 M HDR indicates the row is a header record File type Char 7 M File Type - SVFAULT Version of EIEP Num 3.1 M Version of EIEP protocol that is being used for this file. Sender Char 20 M Name of sending party. Participant identifier to be used if the sender is a participant. Sent on behalf of Char 4 C Participant identifier of party on whose behalf the file is being sent Recipient Participant Char 4 M Valid recipient Participant Identifier identifier Service Request Number Char 15 M Service Request (SR) number. Unique to a service request and sender. Job type code Char 5 M As per table of agreed Job Type codes as per tables following this EIEP. ICP identifier Char 15 M ICP identifier means a unique identifier for an ICP created by a distributor in accordance with clause 1 of Schedule 11.1 Network Participant Char 4 M Network participant identifier 33