MV-STAR. I/O Reference Guide

Transcription

1 T MV-STAR I/O Reference Guide

2 ii Identification TDR /04 MV-STAR Release Trademark Notice Itron is a registered trademark of Itron, Inc. Windows, Windows 95, Windows 98, Windows 2000, and Windows NT are registered trademarks of Microsoft Corporation. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape and Netscape Navigator are U.S. trademarks of Netscape Communications Corporation. Oracle is a registered U.S. trademark of Oracle Corporation, Redwood City, California. Sun, Sun Microsystems, and the Sun Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. The names wuftpd and wu-ftpd are trademarks of the WU-FTPD Development Group and the Washington University at St. Louis. This product includes software developed by the Apache Software Foundation ( Disclaimer of Warranties and Limitation of Liability There are no understandings, agreements, representations, or warranties, express or implied, including warranties of merchantability or fitness for a particular purpose, other than those specifically set out by any existing contract between the seller and buyer. Any such contract states the entire obligation of seller. The contents of this guide shall not become part of or modify any such prior or existing agreement. The information, recommendations, descriptions, and safety notations are based on Itron experience and judgment. This information should not be considered as all-inclusive or covering all cntingencies. If further information is required, Itron should be consulted. In no event will Itron be responsible to the user in contract, in tort (including negligence), strict liability or otherwise for any special, direct, indirect, incidental, or consequential damage or loss whatsoever; or claims against the user by its customers resulting form use of information, recommendations, descriptions, or safety notations. Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without permission of Itron. Copyright Itron All rights reserved Technical Support support@itron.com Website Fax Telephone (The technical support representative will ask for your product serial number located on the CD-ROM case.) The technical support representative may also ask you to provide some or all of the following information: Application Version number Error message text Error message log file Screen name Function performed prior to the problem

3 iii About This Document This document describes file formatting and standards used by the MV-STAR system for reports and files such as Request and Acknowledgement files, EDI reports, and loss equations. This is a generic guide; not all sites use all features of the MV-STAR core product. Revision History Date Chapter Description 06/01 Chapter 3 Loss Factor Equations Related Documents MV-STAR System Administration Guide MV-STAR User Guide Corrected equations in calculations 1-9 in the Transformer equations section. 06/01 Chapter 2 File Format Added Raw DTD Description to the XML File Format section. 07/01 Chapter 2 File Format Added MDEF file format. 07/01 Chapter 2 File Format Added MV-90 Master File format. 08/01 Chapter 2 File Format Added MV-90 Register Read Loader format. 12/01 Chapter 2 File Format Added PAD information (sections Coding Scope through Loading Interval Absolute PAD). 08/02 Chapter 1 EDI867 Specifications 06/04 Chapter 1 EDI867 Specifications 06/04 Appendix B Appendix C Added code 39 to MEA measurements information on page 32. Removed this chapter and incorporated EDI867 implementation to the File Formats chapter (which became Chapter 1). Added the following information to the XML File Format section: XML Enrollment XML Register Read XML Meter Information XML Loss Configuration XML Meter Point XML Physical Allocation Data XML Loss Added Appendix B which discusses Date Truncation. Added Appendix C which contains examples of files exported from or imported into MV-STAR. TDR /04

4 iv How This Document is Organized Chapter/Appendix Chapter 1 EDI867 Specifications Chapter 1 File Formats Chapter 3 Loss Factors Equation Appendix A Appendix B Appendix C Description A proposed interchange standard for EDI-867 implementation. Describes the formatting of MV-STAR files: Request File Formats Acknowledgement File Formats XML File Formats Describes Method 1 and Method 2 of loss equations. Contains third party acknowledgements. Describes date truncation. Lists examples of files exported from or imported into MV-STAR. Note: This document was designed to be distributed electronically and then printed on a laser printer on an as-needed basis. For this reason, the fonts and layout of this document have been chosen for optimal printing rather than for optimal viewing on-screen. To review this document on-screen, however, simply increase the magnification using the magnification box at the bottom of the window.

5 v Notes TDR /04

6 vi

7 Contents v FILE FORMATS... 1 Acknowledgement File Format... 2 Successful Parse Format... 2 Example successful parse format:... 2 Example Example Unsuccessful Parse Format... 3 Example Unsuccessful Parse Format... 4 Request File Format... 5 General Rules... 6 Example... 6 Request File Required Fields... 6 Password... 6 Report_type... 6 Request_reference... 7 Request File Report-Specific Fields... 7 EDI867REP... 8 meter_id... 8 meter_type... 9 start_datetime and end_datetime... 9 loss_flag... 9 version... 9 participant_role redundant_dtm_flag settlement_date associated_id EDI867 FILE REQUEST FORMAT EXAMPLE Register Report Request File XML File Special Handling Output Register Report Format EDI867 Specifications IESO EDI-867 Implementation Document Convention Loop Structure Element Structure Product Transfer and Resale Report ISA Interchange Control Header TDR /04

8 vi Element Summary GS Functional Group Header Semantics Comments Element Summary ST Transaction Set Header Semantics Element Summary BPT Beginning Segment for Product Transfer and Resale Semantics Element Summary N1 Name Syntax Comments Element Summary REF Reference Identification Comments Element Summary PTD Product Transfer and Resale Detail Syntax Comments Element Summary REF Reference Identification Comments Element Summary QTY Quantity Element Summary MEA Measurements Syntax Semantics Comments Element Summary REF Reference Identification Syntax Notes Element Summary DTM Date/Time Reference Syntax Comments Element Summary SE Transaction Set Trailer Comments Element Summary GE Functional Group Trailer Semantics Comments... 45

9 vii Element Summary IEA Interchange Control Trailer Element Summary MDEF File Format File Structure RCODE Meter (Recorder/Site) Header Record Layout Start and Stop Times DST Flag Channel Header Record Layout Start and Stop Times Interval Data Record Layout Channel Status (2 Bytes) Interval Status (2 Bytes) Trailer Record Layout Time Stamp MV-90 Register Read Loader Error Handling MV-90 Master File Format XML File Format Enrollment Interface Enrollment File Rules Register Read Loader Register Read Loader Rules Meter Information Loader Meter Information Loader Rules Loss Configuration Loader Loss Configuration Loader Rules Meter Point Loader Meter Point Loader Rules Physical Allocation Data (PAD) Loader Pad (Physical Allocation Data ) Loader Rules General Business Rules Loss Loader Loss Loader Rules General business rules INTERFACES Table Based Formats Generation Schedule Loader Database Model SCHEDULE_SET SCHEDULE_SET_MEMBER DISPATCH_INT IMO Master File Loader Database Model Generation Schedule Loader Rules TDR /04

10 viii Loading Participant Information Loading Participant Role Information Loading Delivery Points Loading Contract Information LOSS EQUATIONS General Import/Export Rules Transformer Equation Calculated Values Assumed Quantities Assumption Assumption Assumption Calculation Calculation Calculation Calculation Calculation Calculation Calculation Calculation Calculation Volt Ampere Equation APPENDIX A Third Party Acknowledgements The Apache Software License, Version APPENDIX B Date Truncation APPENDIX C Export/Import Files mvstartransaction.dtd ( loss and pad ) Loss File Example PAD File Example MVSTAR_ENROLLMENT.xsd Enrollment Example MVSTAR_SITE_REGISTRATION.xsd Meter Information File Example MVSTAR_REGISTER.xsd Register File Example MVSTAR_LOSS_CONFIGURATION.xsd Loss Configuration Example MVSTAR_METERPOINT.xsd Meter Point File Example

11 1 File Formats This chapter describes the formatting of files that are exported from, or imported into the MV-STAR system: Acknowledgement File Request File EDI 867 MV90 MDEF MV90 Register Read MV90 Master File XML Enrollment XML Register Read XML Meter Information XML Loss Configuration XML Meter Point XML Physical Allocation Data XML Loss

12 2 Acknowledgement File Format Acknowledgement File Format There are two file formats for acknowledgement files. The first format is used for requests or submissions that are parsed successfully; the second format is used when a request could not be parsed. The Acknowledgement file examples given are in response to Request files for meter data, PAD submissions as well as Losses submissions. The Event Symbol and the Event Message will change to appropriately reflect the status of the transaction. Successful Parse Format The file contains the information in fields as shown in the following table. A colon delimits the fields. The Type field indicates the maximum length of the data that the specified field can have. Name Type Description Event Symbol CHAR(20) Describes event Event Type CHAR(1) I informational, W warning, E error Event Message CHAR(900) Textual message describing what happened. Example successful parse format: TASK_START: I: Job SID , Job Type EDI867REP started, CONTEXT StarAppliction starting RUNPARAM: I: Retrieved parameter: start_datetime = RUNPARAM: I: Retrieved parameter: report_type = EDI867REP RUNPARAM: I: Retrieved parameter: debug = y EDI_INFO_SEGMENT: I: Segment < ST> processed. EDI_INFO_SEGMENT: I: Segment < BPT> processed. EDI_INFO_SEGMENT: I: Segment < N1> processed. IFACESUCCESS: I: Interface succeeded Example 1 TASK_START is the Event Symbol. I is the Event Type. In this case informational. Job Sid , Job Type EDI867REP started, CONTEXT StarApplication starting. This is the message describing that an EDI867 report was started by the STAR application.

13 Acknowledgement File Format 3 Example 2 IFACESUCCESS is the Event Symbol. I is the Event Type. Interface succeeded. This is the message. There are close to 1000 Event Symbols possible, Itron has made a conscious decision not to include them in this document. Note: The event message can contain colons(:) within it and in this case are not field delimiters. Unsuccessful Parse Format The following acknowledgement is produced when a submitted request can not be parsed. The request acknowledgement file is a plain ASCII text file with a filename of the form partid_ee.ack where partid is the Participant ID requesting the report and EE is a sequential number to guarantee file name uniqueness. The file contains the request information in the form of fields. All fields are mandatory, and a carriage return character delimits each field. The following table defines the fields. Name Type Description Participant ID CHAR(15) Participant Identification for Participant Request_Reference CHAR(30) Participant request reference Status CHAR(7) FAILURE Error Message CHAR(100) Textual message describing what happened TDR /04

14 4 Acknowledgement File Format Example Unsuccessful Parse Format Participant ID: AGROUP Request_Reference: REF001 Status: FAILURE Error Message: To Datetime: From Datetime: cannot be greater than: (minutes) In this example: The Participant ID is AGROUP The Request_Reference is REF001 The Status is FAILURE The Error Message indicates that the date range was erroneously specified. The format for Datetime is: YYYYMMDDHH24MI where YYYY is the year, MM the month, DD the day, HH24 the hour and MI the minute.

15 Request File Format 5 Request File Format MV-STAR request files enable market participants and other external systems to initiate report jobs in the MV-STAR system and receive the results of these reports without the intervention of an MV-STAR operator. Request files are typically used to permit market participants to request and receive reports on the data within the MV-STAR system. MV-STAR enforces standard data access restrictions for reports that are run via a request file. Request files from users without a participant ID and participant IDs without a participant password will be rejected by MV-STAR. If a participant successfully submits a request file, a job will be scheduled to produce the report. If the report executes successfully, the results, as well as an acknowledgement file, will be sent to the location specified within the MV-STAR system for that participant ID and that report. Typically, the destination for reports is set to a machine owned by the participant or a staging server external to the MV-STAR server but within the organization that administers MV-STAR, such as MV-WEB. If the report fails, an acknowledgement file will be sent to the user with details about why the report failed. The request file contains information that the MV-STAR system uses to identify the user and validate user access to the system. The request file also specifies the report that is being requested and the parameters that should be used by the report. Each line in an MV-STAR request file specifies a parameter name and value. Several parameters are necessary in every request file; other parameters vary from one report to another. The valid parameter names are described later in this document. The request file also may contain comment lines to aid the requester in identifying the request. Comment lines are ignored by the MV-STAR system. Each line in an MV-STAR request file specifies a parameter name and a parameter value or a comment. Comment lines begin with an octothorp (#) and are ignored by MV-STAR. Comments should not be placed on the same line as a name-value pair. All other lines specify a single parameter and its value. White space (tabs and spaces) will be stripped from each line. The parameter name must be formatted exactly as specified in this document, including spelling, case, and underscores. The parameter name is followed by an equal sign and the parameter value. The parameter value must be 100 characters or less. If any parameter value is longer than 100 characters, the request file will be rejected. If either the parameter name or the parameter value is not supplied, the request file will be rejected. The parameter value should be followed by a line feed or a carriage return, line feed pair. For example, lines in a request file that properly follow these rules look like the following: parameter_name1=parameter_value1 parameter_name2=parameter_value2 A sample of an actual request file is given in a later section. TDR /04

16 6 Request File Format General Rules The MV-STAR request file is a plain ASCII text document. The filename should have the form 'YYYYMMDDHH24MI_EE.REQ'. The YYYY, MM, DD, HH24, and MI are the year, month, day, hour, and minute, respectively, of the time when the file was generated. EE is a sequential number to guarantee file name uniqueness when a participant generates multiple request files at the same time. The sequence number may be set to 00 unless the participant is submitting multiple files at once. Example If a participant programmatically generates 3 request files at 3:45 P.M. on the second of January 2000, then their filenames would be _00.REQ, _01.REQ, and _02.REQ. Request File Required Fields The following table defines the fields that are required in all request files. These parameters are used by the MV-STAR system to process the request file. They include information to validate the participant, schedule the correct report, and identify the request in acknowledgment files. Parameter Name Max. Length Format (example) Required/Optional password 20 SCPASSWORD Required report_type 10 EDI867REP Required request_reference 30 REF001 Required Password The password field is the participant's password in MV-STAR. This password is maintained by the MV-STAR operators and can be set in the PARTPASS form, accessed by clicking the "Password " button on the Report Recipient screen. Report_type The report_type is a special value that indicates a job within MV-STAR. Currently the only report types that can be initiated via a request file is EDI867REP, which produces a report formatted according to the EDI867 standard and Register Report which is used for Register Reads only.

17 Request File Format 7 Request_reference The request_reference field is not used directly by the MV-STAR code. This value is included in the acknowledgement file that is sent in response to the request file. The participant can use this value to determine which acknowledgement files correspond to which request files. The requestor can fill the field with any string that fits the size limit. It is especially useful when a participant submits several request files and receives one or more acknowledgement files indicating a rejected request. Note: This field should not contain spaces. Request File Report-Specific Fields The remaining parameters are specific to each report_type. When submitting a request file, check the report-specific parameters for the appropriate report_type. TDR /04

18 8 Request File Format EDI867REP Parameter Name Max. Length Possible Values Required/Optional meter_id 20 Any valid Metering System ID in MV-STAR or any of the following strings: ALL ALLDP - the participant s Delivery Points only ALLSM - the participant s Summary Maps only ALLSP - all Service Points for the participant ALLMP - all Meter Points for the participant Required meter_type 1 I Required start_datetime 12 Any date in a YYYYMMDDHH24MI format end_datetime 12 Any date in a YYYYMMDDHH24MI format Required Required loss_flag 1 Y or N Optional version 16 Current, Current Validated, First, or YYYYMMDDHH24MI participant_role 4 Any valid Market Role in MV-STAR, such as MMP or LDC. Optional Optional redundant_dtm_flag 1 Y or N Optional settlement_date TBD To Be Determined Optional (not implemented) associated_id 15 Any valid participant id Optional meter_id The EDI867 report will include data for the specified meter_id. The meter_id can be the MV-STAR metering system ID for any metering system. The special value "ALL" indicates that the EDI867 report should gather data for all of the participant's meters.

19 Request File Format 9 meter_type The meter_type indicates the type of meter. "I" indicates interval meters and is currently the only supported meter_type. start_datetime and end_datetime The EDI867 report will include data during the time window between the starting date and time and the ending date and time specified by these parameters. The format of these fields can be expressed as YYYYMMDDHH24MI, where YYYY is the year, MM is the month, DD is the date, HH24 is the hour (on a 24 hour clock), and MI is the minute. The year, month, date, hour, and minute portions of the date are all numeric and padded on the left with zeroes if necessary. For example, 1:35 P.M. on Tuesday, January 2, 2001, would be expressed as , and midnight on Wednesday, January 3, 2001, would be expressed as loss_flag The loss_flag specifies whether the reading values in the EDI867 report should include losses when there is an option of whether to apply losses or not. If loss_flag is set to "Y", then losses will be included in the reading values whenever there are losses to apply. If the loss_flag is set to "N" or is not specified, the reading values will not include loss information if readings without losses are permitted by the market rules. If market rules dictate that losses must be applied to a particular metering system, then this flag will be ignored. version The version parameter indicates which version of the data should be included in the report. If the version is not specified, the report will default to the "Current" version. Since the MV-STAR system maintains multiple historical versions of meter reading data, several versions of each meter reading may be available. The version flag may be: One of the strings "Current", "Current Validated", or "First" (without the quotes) A date specified by the date format YYMMDDHH24MI that is used by the start_datetime and end_datetime parameters. For example, the version indicates September 1, 2000, at 1:00 P.M. If version is set to: "Current", the data that is active in MV-STAR at the time the report is run will be used. "Current Validated", the report will use the most recent version that has been accepted by the MV-90 system. "First", the report will use the first version of data loaded for the metering system. If the version specifies the date, then the data will be reported as though the report were run in MV-STAR on that date. That is, MV-STAR's historical record of the data on the specified date will be used. Note: Some metering systems only support a subset of the versions. A Meter Point supports all of the versions. Summary Metering Systems and Delivery Points only support the "Current" and "YYYYMMDDHH24MI" versions. If an invalid version is specified, the report will fail. TDR /04

20 10 Request File Format participant_role The EDI867 report only reports meter readings that the requestor can access through a contract. For example, a market participant to delivery point relationship, where a market participant may have multiple relationships with a delivery point. If the requestor sets the participant_role parameter, then the report will only show the reading values that the requestor can access via contracts of the specified market role. If the requestor does not specify a participant_role, then the report will use all of the requestor's contracts when determining whether the participant has access to view a particular meter reading. redundant_dtm_flag The EDI867 format permits the DTM field to be omitted when the time for an interval reading can be deduced from a previous DTM field and the interval size. Some information systems require a DTM field for every interval although these redundant DTM fields are not required by the EDI867 specification. If the redundant_dtm_parameter is set to "Y", then a DTM field will be included with every interval reading in the EDI867 report file. If this parameter is set to "N" or is not specified, then the EDI867 report will include a DTM field where it is required by the EDI867 format only. Note: Setting this flag to "Y" will result in significantly larger report files. settlement_date The settlement_date flag is not implemented in the current release of MV-STAR. When the settlement_date functionality is implemented, a new revision of this document will be released. associated_id The associated_id is the participant ID of the entity allowing access to this meter's data. For example, if a participant named Frodo were to hold a metered market participant relationship to a meter, he could allow Sam, another participant, to view it. In other words, Frodo would create an "association" on a given meter for Sam. In this case, Sam would submit a request file in which Sam would be the participant (and use Sam's password), while Frodo would be entered as the associated_id. Presuming that Sam has requested data from the time period covered by the association and for meters so covered, he will receive a report identical to that which Frodo would receive, having requested it as the metered market participant. EDI867 FILE REQUEST FORMAT EXAMPLE # This line is a comment line # The next three fields are required in all request files password=password report_type=edi867rep request_reference=ref001 # The following fields are specific to the EDI867REP report_type meter_id=all meter_type=i start_datetime= end_datetime=

21 Request File Format 11 version= participant_role=mmp # The loss_flag has been omitted since it is optional. redundant_dtm_flag=n Register Report The objective of this report is to output register reads XML format for a given request (.req) file. Request File The request file (.req) for a Register Report attributes are: This report is a standard MV-STAR request file oriented report. The file transfer is from CSS to MV-STAR The extension is.req. The content of the Register Report request file must be: Sample register read request file Password = CSSPWD (assigned by MV-STAR) Report type = REGREPORT (assigned by MV-STAR) Request reference = RRCSS01 (alpha-numeric - assigned by CSS) Exact field name (such as meter_id) Exact date format start_datetime= end_datetime= Meter ID = POD0001 Register type: TOTAL_KWH TOTAL_KVARH PEAK_KWH PEAK_KVAR In the request file, any combinations of the four register types are allowed. The four register types that MV-STAR supports are: TOTAL_KWH TOTAL_KVARH PEAK_KWH PEAK_KVAR TOTAL_KWH and TOTAL_KVARH are the consumption reads over a given time period. TDR /04

22 12 Request File Format PEAK_KWH and PEAK_KVAR are the maximum reads over the given time period. XML File The output file (XML) for a Register Report attributes are: The file transfer is from MV-STAR to an external system The file report format is XML Special Handling If there are more than one consumption reads for the given time period, the last read will be reported. If there are more than one peak reads for the given time period, the highest read will be reported. Output Register Report Format The header portion of the report is always the same. The text "RegRptTst" is always the same text value that appears in the REFERENCE_ID element. If no request_reference parameter is given (only possible when scheduling the report via the GUI), the CORELATION_ID begin/end tags will be present without any reference text between. The SCHEMA_VERSION element is MV-Star documentary info that indicates which XML schema version was used to produce the xml report. <?xml version="1.0" standalone="yes"?> <CORELATION_ID>RegRptTst</CORELATION_ID> <REGISTER_TRANSACTION> <SCHEMA_VERSION>1</SCHEMA_VERSION> This line of the report is only generated when the request_reference parameter is present. <REFERENCE_ID>RegRptTst</REFERENCE_ID> Beginning of meter data. If the meter id parameter specifies a valid delivery point meter, the REGISTER_SET element is produced. If the meter id is not a valid delivery point meter, an info log message " meter_id invalid for REGREPORT " is posted and the report skips the REGISTER_SET entirely and the job completes with "Interface succeeded". <REGISTER_SET MeterId="SS_METER1D"> For each register_type parameter in the request file, REGISTER elements are written in the report. Since the types are optional, there may be 0 to 4 REGISTER elements contained in the REGISTER_SET.

23 Request File Format 13 The "Type=" attribute will always be shown, however "Multiplier=" and "MaximumValue=" are optional and only appear when there is corresponding data in the data base. Each REGIS-TER element may or may not contain RELATIVE_READING information. If there is no reading data found within the date range stipulated by the start/end date parameters, the RELATIVE_READING line for its corresponding REGISTER element is omitted. <REGISTER Type="TOTAL_KWH" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read=" " ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> <REGISTER Type="PEAK_KW" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read="3.4425" ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> <REGISTER Type="TOTAL_KVARH" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read=" " ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> <REGISTER Type="PEAK_KVAR" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read="1.7352" ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> End of meter data. </REGISTER_SET> This is the report trailer indicating the conclusion of the report (always present). </REGISTER_TRANSACTION> TDR /04

24 14 EDI867 Specifications EDI867 Specifications This proposed interchange standard is based on the EDI-867 implementations already in use in other jurisdictions. This document represents the sub-set of the EDI-867 standard required for transferring interval meter reading data between parties in Ontario's deregulated electric market place. The general parameters for the EDI-867 transfer set for use in the utility industry were developed by the Utility Industry Working Group. Please see for the full EDI-867 specification. IESO EDI-867 Implementation The UIG EDI-867 specification, release 4010 recommends against the use of "ZZ" qualifier. "ZZ" is used to indicate mutually defined identifiers between trading partners. In general avoiding "ZZ" represents a best practice. Rather than create special identifiers, use ones that already exist and are maintained by a neutral third party. Nevertheless, the "ZZ" qualifier is used at several points in this implementation. Generally, when the "ZZ" qualifier is used it represents an identifier which is supplied by the IESO itself, and which market participants must follow in order to exchange data with the IESO. Fields and segments not in use in this implementation guide are not listed. Please note that element reference is positional. Thus, if an element is not included in a segment, element delimiters are still required. For example, if a segment includes the QQ101, QQ103 and QQ104 elements, the output will look like: QQ*Data for 101**Data for 103*Data for 104 Document Convention This document follows several conventions. In each segment description there are columns labeled, Req, Max Use, Repeat, Note, and Usage. These columns are as follows: Loop Structure Req Max Use Repeat Usage Indicates whether a field is Mandatory, Conditional or Optional within the general EDI-867 framework. Mandatory indicates the value is always required for a valid EDI-867. Conditional indicates a value may be required, being dependent on previous values or other conditions. Optional means the value is not required for a valid EDI-867, but may be used. Indicates the maximum number of times an element may be used with a given segment or loop. Indicates the maximum (e.g. 5) or minimum (e.g., > 1) number of times a loop must be present. Indicates the actual usage under this implementation. This field may be "used" or "must use". Must use indicates that the value must be present, regardless of whether it is optional in the broader EDI spec, for proper exchange of data with trading partners under this implementation. "Used" indicates that the value is used by trading partners in this implementation based on the conditions outlined within the specification.

25 EDI867 Specifications 15 Element Structure Req Indicates whether a field is Mandatory, Conditional or Optional within the general EDI-867 framework. Mandatory indicates the value is always required for a valid EDI-867. Conditional indicates a value may be required, being dependent on previous values or other conditions. Optional means the value is not required for a valid EDI-867, but may be used. Type Indicates the type of the value contained within the elements. Types include ID - specifically defined identifier, AN - alphanumeric string, DT - datetime string. Min/Max Usage Indicates the minimum and maximum number of characters within the field. Note: fixed length fields (fields where the maximum and minimum are the same) will be right padded with spaces to the end of the field. Indicates the actual usage under this implementation. This field may be "used" or "must use". "Must use" indicates that the value must be present, regardless of whether it is optional in the broader EDI spec, for proper exchange of data with trading partners under this implementation. "Used" indicates that the value is used by trading partners in this implementation based on the conditions outlined within the specification. 867 Product Transfer and Resale Report This proposed interchange standard contains the format and establishes the data contents of the Product Transfer and Resale Report Transaction Set (867) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to: (1) report information about product that has been transferred from one location to another; (2) report sales of product from one or more locations to an end customer; or (3) report sales of a product from one or more locations to an end customer, and demand beyond actual sales (lost orders). Report may be issued by either buyer or seller. This document describes the implementation to be used for the Ontario electric meter read data transfer. In the Ontario market, meter reading data will be provided by the IESO to market participants when they electronically request it. The format described in this document is the one which will be used to supply this data. Note: 2/010Each use of the PTD loop will represent one meter register (channel). Transaction Control Header Pos ID Segment Name Req Max Use Repeat Notes Usage ISA Interchange Control Header M 1 Must use GS Functional Group Header M 1 Must use TDR /04

26 16 EDI867 Specifications Heading Pos ID Segment Name Req Max Use Repeat Notes Usage 010 ST Transaction Set Header M 1 Must use 020 BPT Beginning Segment for Product Transfer and Resale M 1 Must use LOOP ID - N NI Name 0 3 Must use 120 REF Reference Identification 0 2 Must use Detail Pos ID Segment Name Req Max Use Repeat Notes Usage LOOP ID - QTY QTY Quantity 0 1 Must use 160 ME A Measurements 0 1 Used 190 REF Reference Identification 0 2 Used 210 DT M Date/Time Reference 0 2 Used LOOP ID - PTD PTD Product Transfer and Resale Detail M 1 N2/010 Must use 030 REF Reference Identification O 10 Used

27 EDI867 Specifications 17 Summary Pos ID Segment Name Req Max Use Repeat Notes Usage 030 SE Transaction Set Trailer M 1 Must use Transaction Control Trailer Pos ID Segment Name Req Max Use Repeat Notes Usage GE Functional Group Trailer M 1 Must use IEA Interchange Control Trailer M 1 Must use ISA Interchange Control Header To start and identify an interchange of zero or more functional groups and interchange-related control segments. The ISA segment explicitly uses fixed length fields. TDR /04

28 18 EDI867 Specifications Element Summary Ref ID Element Name Req Type Min/ Max Usage ISA01 I01 Authorization Information Qualifier Description: Code to identify the type of information in the Authorization Information field. M ID 2/2 Must use Code Name 00 No Authorization Information present. (No meaningful information in I02.) Note: No other codes are supported in this implementation at this time. ISA02 I02 Authorization Information Description: Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier. (I01) ISA03 I03 Security Information Qualifier Description: Code to identify the type of information in the Security Information field. M AN 10/10 Must use M ID 2/2 Must use Code Name 00 No Security Information present. (No meaningful information in I04.) Note: No other codes are supported in this implementation at this time. ISA04 I04 Security Information Description: This is used for identifying the security information about the interchange sender or the data in the interchange; the type of information is set by the Security Information Qualifier (I03). M AN 10/10 Must use

29 EDI867 Specifications 19 Ref ID Element Name Req Type Min/ Max Usage ISA05 I05 Interchange ID Qualifier Description: Qualifier to designate the system/method of code structure used to designate the sender or receiver ID element being qualified. M ID 2/2 Must use Code ZZ Name Mutually Defined Note: No other codes are supported in this implementation at this time. ISA06 I06 Interchange Sender ID Description: Identification code published by the sender for Other parties to use as the receiver ID to route data to them; the sender always codes this value in the sender ID element. ISA07 I05 Interchange ID Qualifier Description: Qualifier to designate the system/method of code structure used to designate the sender or receiver ID element being qualified. M AN 15/15 Must use M ID 2/2 Must use Code ZZ Name Mutually Defined Note: No other codes are supported in this implementation at this time. ISA08 I07 Interchange Receiver ID Description: Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them. ISA09 I08 Interchange Date Description: Date of the interchange. ISA10 I09 Interchange Time Description: Time of the interchange. M AN 15/15 Must use M DT 6/6 Must use M TM 4/4 Must use TDR /04

30 20 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage ISA11 I10 Interchange Control Standards Identifier Description: Code to identify the agency responsible for the control standard used by the message that is enclosed by the interchange header and trailer. M ID 1/1 Must use Code U Name US EDI Community of ASC X.12, TDCC, and UCS Note: No other codes are supported in this implementation at this time. ISA12 I11 Interchange Control Version Number Description: This version number covers the interchange control segments. M ID 5/5 Must use Code Name Draft Standards for Trial Use Approved for Publication by ASC X12 Procedures Review Board through October Note: No other codes are supported in this implementation at this time. ISA13 I12 Interchange Control Number Description: A control number assigned by the interchange sender. ISA14 I13 Acknowledgment Requested Description: Code sent by the sender to request an interchange acknowledgment (TA1). M NO 9/9 Must use M ID 1/1 Must use Code Name 0 No acknowledgement required. Note: No other codes are supported in this implementation at this time.

31 EDI867 Specifications 21 Ref ID Element Name Req Type Min/ Max Usage ISA15 I14 Usage Indicator Description: Code to indicate whether data enclosed by this Interchange envelope is test, production or information. M ID 1/1 Must use Code P T Name Production Data Test Data Note: No other codes are supported in this implementation at this time. ISA16 I15 Component Element Separator Description: The component element separator is a delimiter and not a data element, so "Type" is not applicable. This field provides the delimiter used to separate component data elements within a composite data structure; this value must be different than the data element separator and the segment terminator. The Component Element Separator will always be a colon in this implementation. Composite fields are not used in this implementation. M 1/1 Must use Example ISA^00^ ^00^ ^ZZ^THEIESO ^zz^ ^001213^1740^u^00401^ ^0^p^: GS Functional Group Header To indicate the beginning of a functional group and to provide control information. Semantics 1. GS04 is the group date. 2. GS05 is the group time. 3. The data interchange control number GS06 in this header must be identical to the same data element in the associated functional group trailer, GE02. TDR /04

32 22 EDI867 Specifications Comments A functional group of related transaction sets, within the scope of X12 standards, consists of a collection of similar transaction sets enclosed by a functional group header and a functional group trailer. Element Summary Ref ID Element Name Reg Type Min/Max Usage GS Functional Identifier Code Description: Code identifying a group of application related transaction sets. M ID 2/2 Must use Code PT Name Product Transfer and Resale Report (867) Note: No other codes are supported in this implementation at this time. GS Application Sender's Code Description: Code identifying party sending transmission; codes agreed to by trading partners. M AN 2/15 Must use GS Application Receiver's Code Description: Code identifying party receiving transmission. Codes agreed to by trading partners. GS Date Description: Date expressed as CCYYMMDD M AN 2/15 Must use M DT 8/8 Must use

33 EDI867 Specifications 23 Ref ID Element Name Reg Type Min/Max Usage GS Time Description: Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99) GS06 28 Group Control Number Description: Assigned number originated and maintained by the Sender GS Responsible Agency Code Description: Code used in conjunction with Data Element 480 to Identify the issuer of the standard. M TM 4/8 Must use M NO 1/9 Must use M ID 1/2 Must use Code X Name Accredited Standards Committee X12 Note: No other codes are supported in this implementation at this time. GS Version / Release / Industry Identifier Code Description: Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed. M AN 1/12 Must use TDR /04

34 24 EDI867 Specifications Ref ID Element Name Reg Type Min/Max Usage Code Name Draft Standards Approved for Publication by ASC X12 Procedures Review Board through October Note: No other codes are supported in this implementation at this time. Example GS*PT*THEIESO*000000* *1740*636*X* ST Transaction Set Header To indicate the start of a transaction set and to assign a control number. Semantics The transaction set identifier (ST01) used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set). Element Summary Ref ID Element Name Reg Type Min/ Max Usage ST Transaction Set Identifier Code Description: Code uniquely identifying a Transaction Set. M ID 3/3 Must use Code Name 867 Product Transfer and Resale Report

35 EDI867 Specifications 25 Ref ID Element Name Reg Type Min/ Max Usage ST Transaction Set Control Number Description: Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set. Note: This number is used to pair the Transaction Set Header with the Transaction Set Trailer. In EDI formats where multiple ST segments can occur, this control number is very important to maintaining the integrity of the file. In this EDI-867 implementation, only one ST loop is allowed per file. Because of this restriction this value will always be M AN 4/9 Must use Example ST*867*0001 BPT Beginning Segment for Product Transfer and Resale To indicate the beginning of the Product Transfer and Resale Report Transaction Set and transmit identifying data. Semantics 1. BPT02 identifies the report number. 2. BPT03 identifies the report date. Element Summary Ref ID Element Name Req Type Min/ Max Usage BPT Transaction Set Purpose Code Description: Code identifying purpose of transaction set. M ID 2/2 Must use Code Name 00 Original TDR /04

36 26 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage Description: Conveys original readings for the account being reported. Use for both Inbound and Outbound transactions 52 Response to Historical Inquiry Description: Response to a request for historical meter reading. Used for Outbound only. This will be used when the response to a request is anything other than current. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. BPT Reference Identification Description: Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier. It is a unique transaction identification number assigned by the originator of this transaction. Note: This number should be unique for every EDI-867 file produced by a given system. If trading partners are using multiple systems, this identifier may not be unique. BPT Date Description: Date expressed as CCYYMMDD. Transaction Creation Date BPT Report Type Code Description: Code indicating the title or contents of a document, report or supporting item. O AN 1/30 Used M DT 8/8 Must use O ID 2/2 Used Code C1 Name Cost Data Summary Description: Interval readings.

37 EDI867 Specifications 27 Ref ID Element Name Req Type Min/ Max Usage Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. BPT Reference information as defined in the 'Request Reference' field of the EDI request file Example BPT*00*636* *C1*****DATAREQUEST17 N1 Name Syntax To identify a party by type of organization, name, and code. 1. N103 is required. N102 is not used for processing purposes. Note: the UIG EDI-867 specification allows for either N102 or N103 to be used. This implementation requires N103 exclusively. 2. If either N103 or N104 are present, then the others are required. Comments 1. This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party. 2. Two N1 segments will be used in this implementation. One identifying the originator of the transaction, the other identifying the receiver of the transaction. This is specific to the Independent Electricity System Operator and differs from the UIG specification. TDR /04

38 28 EDI867 Specifications Element Summary Ref ID Element Name Req Type Min/ Max Usage N Entity Identifier Code Description: Code identifying an organizational entity, a physical location, property or an individual. M ID 2/3 Must use Code Name 55 Service Manager Description: Used to identify the party that manages meter data on behalf of another. Meter Service Provider (MSP) 8C EC SJ Consumer Service Provider (CSP) Description: Local Distribution Company (LDC) Exchanger Description: Used to identify the organization running the market. Service Provider Description: Market Participant (MP) Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. N Name Description: Free-form name, this name if used is only for clarity of the transaction. Not used in processing, not verified consistent with N104. This should be the full name of the participant. The IESO itself will be identified by "Independent Electricity System Operator". Note: This field is not used for processing by the IESO. It is not recommended that this field be used for processing by participants. C AN 1/60 Used

39 EDI867 Specifications 29 Ref ID Element Name Req Type Min/ Max Usage N Identification Code Qualifier Description: Code designating the system/method of code structure used for Identification Code (67). C ID 1/2 Must use Code ZZ Name Mutually Defined Description: The Business Associate ID assigned to the entity by the Independent Electricity System Operator. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. N Identification Code Description: Code identifying a party or other code. This will be the Business Associate ID of the participant as assigned by the IESO. The IESO itself will be identified by the code "THEIESO". N Entity Identifier Code Description: Code identifying an organizational entity, a physical location, property or an individual. C AN 2/80 Used O ID 2/3 Must use Code Name 40 Receiver Description: Entity to accept transmission 41 Submitter Description: Entity transmitting transaction set TDR /04