MV-STAR
Identification
MV-STAR Reference Guide
MV-STAR Reference Guide TDR-0017-004 06/04 MV-STAR Release 5.0.213.1
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 (http://www.apache.org/).
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-in-clusive 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 con-sequential 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 1997-2004 Itron
All rights reserved
Technical Support
E-mail [email protected]
Website http://eKnowledge.itron.com
Fax 919-876-8980
Telephone 1-800-789-0788 (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
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
Related Documents
MV-STAR System Administration Guide MV-STAR User Guide
Date Chapter Description
06/01 Chapter 3 Loss Factor
Equations 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 Added code 39 to MEA measurements information on page 32. 06/04 Chapter 1 EDI867
Specifications • 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
06/04 Appendix B Appendix C
• Added Appendix B which discusses Date Truncation.
How This Document is Organized
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.
Chapter/Appendix Description
Chapter 1 EDI867 Specifications
A proposed interchange standard for EDI-867 implementation.
Chapter 1 File Formats
Describes the formatting of MV-STAR files: • Request File Formats
• Acknowledgement File Formats • XML File Formats
Chapter 3 Loss Factors Equation
Describes Method 1 and Method 2 of loss equations.
Appendix A Contains third party acknowledgements.
Appendix B Describes date truncation.
Contents
F
ILEF
ORMATS... 1
Acknowledgement File Format ... 2
Successful Parse Format... 2
Example successful parse format: ... 2
Example 1... 2
Example 2... 3
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... 10
redundant_dtm_flag ... 10
settlement_date... 10
associated_id ... 10
EDI867 FILE REQUEST FORMAT EXAMPLE ... 10
Register Report... 11
Request File... 11
XML File... 12
Special Handling ... 12
Output Register Report Format ... 12
EDI867 Specifications ... 14
IESO EDI-867 Implementation ... 14
Element Summary ... 18
GS Functional Group Header ... 21
Semantics ... 21
Comments... 22
Element Summary ... 22
ST Transaction Set Header... 24
Semantics ... 24
Element Summary ... 24
BPT Beginning Segment for Product Transfer and Resale ... 25
Semantics ... 25
Element Summary ... 25
N1 Name... 27
Syntax... 27
Comments... 27
Element Summary ... 28
REF Reference Identification... 30
Comments... 30
Element Summary ... 30
PTD Product Transfer and Resale Detail ... 31
Syntax... 31
Comments... 31
Element Summary ... 32
REF Reference Identification... 33
Comments... 33
Element Summary ... 33
QTY Quantity... 35
Element Summary ... 35
MEA Measurements ... 37
Syntax... 37
Semantics ... 37
Comments... 37
Element Summary ... 38
REF Reference Identification... 41
Syntax... 41
Notes... 42
Element Summary ... 42
DTM Date/Time Reference ... 43
Syntax... 43
Comments... 43
Element Summary ... 43
SE Transaction Set Trailer... 45
Comments... 45
Element Summary ... 45
GE Functional Group Trailer... 45
Semantics ... 45
Element Summary ... 46
MDEF File Format ... 47
File Structure ... 47
RCODE ... 47
Meter (Recorder/Site) Header Record Layout ... 49
Start and Stop Times ... 49
DST Flag ... 50
Channel Header Record Layout ... 50
Start and Stop Times ... 52
Interval Data Record Layout ... 52
Channel Status (2 Bytes) ... 54
Interval Status (2 Bytes) ... 56
Trailer Record Layout ... 56
Time Stamp ... 57
MV-90 Register Read Loader... 58
Error Handling... 60
MV-90 Master File Format... 61
XML File Format... 62
Enrollment Interface... 62
Enrollment File Rules... 62
Register Read Loader ... 62
Register Read Loader Rules ... 63
Meter Information Loader ... 63
Meter Information Loader Rules... 63
Loss Configuration Loader... 64
Loss Configuration Loader Rules ... 64
Meter Point Loader... 65
Meter Point Loader Rules ... 65
Physical Allocation Data (PAD) Loader ... 66
Pad (Physical Allocation Data ) Loader Rules... 66
General Business Rules ... 66
Loss Loader ... 68
Loss Loader Rules ... 68
General business rules ... 68
I
NTERFACES... 69
Table Based Formats ... 70
Generation Schedule Loader ... 70
Database Model... 70
Loading Participant Information ... 73
Loading Participant Role Information... 74
Loading Delivery Points... 75
Loading Contract Information... 76
L
OSSE
QUATIONS... 77
General Import/Export Rules... 78
Transformer Equation... 79
Calculated Values ... 79
Assumed Quantities... 79
Assumption 1... 80
Assumption 2... 80
Assumption 3... 80
Calculation 1 ... 80
Calculation 2 ... 80
Calculation 3 ... 81
Calculation 4 ... 81
Calculation 5 ... 81
Calculation 6 ... 81
Calculation 7 ... 82
Calculation 8 ... 82
Calculation 9 ... 82
Volt Ampere Equation ... 83
A
PPENDIXA ... 85
Third Party Acknowledgements ... 85
The Apache Software License, Version 1.1 ... 85
A
PPENDIXB... 87
Date Truncation ... 87
A
PPENDIXC ... 89
Export/Import Files... 89
mvstartransaction.dtd ( loss and pad ) ... 90
Loss File Example ... 97
PAD File Example... 99
MVSTAR_ENROLLMENT.xsd ... 103
Enrollment Example... 107
MVSTAR_SITE_REGISTRATION.xsd... 111
Meter Information File Example ... 117
MVSTAR_REGISTER.xsd ... 122
Register File Example ... 124
MVSTAR_LOSS_CONFIGURATION.xsd ... 127
Loss Configuration Example ... 131
MVSTAR_METERPOINT.xsd... 137
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
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.
Example successful parse format:
TASK_START: I: Job SID 2006126, Job Type EDI867REP started, CONTEXT StarAppliction starting
RUNPARAM: I: Retrieved parameter: start_datetime = 200005010000 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 2006126, Job Type EDI867REP started, CONTEXT StarApplication starting. This is the message describing that an EDI867 report was started by the STAR application.
Name Type Description
Event Symbol CHAR(20) Describes event
Event Type CHAR(1) I – informational, W – warning, E – error
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
delimit-ers.
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
Example Unsuccessful Parse Format
Participant ID: AGROUP Request_Reference: REF001 Status: FAILURE
Error Message: To Datetime: 200011200000 - From Datetime: 200011010000 cannot be greater than: 20160 (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.
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.
Com-ments 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
spell-ing, 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
param-eter 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
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 200001021545_00.REQ,
200001021545_01.REQ, and 200001021545_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
val-idate the participant, schedule the correct report, and identify the request in acknowledgment
files.
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
for-matted according to the EDI867 standard and Register Report which is used for Register Reads
only.
Parameter Name Max. Length
Format (example) Required/Optional
password 20 SCPASSWORD Required
report_type 10 EDI867REP Required
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
indi-cating a rejected request.
Note: This field should not contain spaces.
Request File Report-Specific Fields
EDI867REP
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.
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
Required
end_datetime 12 Any date in a
YYYYMMDDHH24MI format Required loss_flag 1 Y or N Optional version 16 “Current”, ”Current Validated”, ”First”, or “YYYYMMDDHH24MI” Optional
participant_role 4 Any valid Market Role in
MV-STAR, such as MMP or LDC.
Optional
redundant_dtm_flag 1 Y or N Optional
settlement_date TBD To Be Determined Optional
(not implemented)
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
nec-essary. For example, 1:35 P.M. on Tuesday, January 2, 2001, would be expressed as
200101021335, and midnight on Wednesday, January 3, 2001, would be expressed as
200101040000.
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
ver-sions 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 200009011300
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
participant_role
The EDI867 report only reports meter readings that the requestor can access through a
con-tract. For example, a market participant to delivery point relationship, where a market
partici-pant 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
# 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=200005010000
–
end_datetime=200006010000
•
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 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.
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="670.22837" ReadDate="2001-07-11T07:28:00"
Fir-stReading="Y" RolloverCount="0"/>
</REGISTER>
<REGISTER Type="PEAK_KW" Multiplier="1.1" MaximumValue="1023">
<RELATIVE_READING Read="3.4425" ReadDate="2001-07-11T07:28:00"
Fir-stReading="Y" RolloverCount="0"/>
</REGISTER>
<REGISTER Type="TOTAL_KVARH" Multiplier="1.1" MaximumValue="1023">
<RELATIVE_READING Read="360.668696" ReadDate="2001-07-11T07:28:00"
Fir-stReading="Y" RolloverCount="0"/>
</REGISTER>
<REGISTER Type="PEAK_KVAR" Multiplier="1.1" MaximumValue="1023">
<RELATIVE_READING Read="1.7352" ReadDate="2001-07-11T07:28:00"
Fir-stReading="Y" RolloverCount="0"/>
</REGISTER>
End of meter data.
</REGISTER_SET>
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
www.uig.org
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
rep-resents 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 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.
Max Use Indicates the maximum number of times an element may be used with a given segment or loop.
Repeat Indicates the maximum (e.g. 5) or minimum (e.g., > 1) number of times a loop must be present.
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
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 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.
Usage 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.
Pos ID Segment Name Req Max
Use
Repeat Notes Usage
ISA Interchange Control
Header
Heading
Detail
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 - N1 5
080 NI Name 0 3 Must use
120 REF Reference Identification 0 2 Must use
Pos ID Segment Name Req Max
Use
Repeat Notes Usage
LOOP ID - QTY
1
110 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
1
010 PTD Product Transfer and Resale Detail
M 1 N2/010 Must use
Transaction Control Trailer
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.
Pos ID Segment Name Req Max
Use
Repeat Notes Usage
030 SE Transaction Set Trailer M 1 Must use
Pos ID Segment Name Req Max
Use
Repeat Notes Usage
GE Functional Group Trailer M 1 Must use
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)
M AN 10/10 Must use
ISA03 I03 Security Information Qualifier
Description: Code to identify the type
of information in the Security Information field.
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).
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 Name
ZZ 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.
M AN 15/15 Must use
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 ID 2/2 Must use
Code Name
ZZ 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.
M AN 15/15 Must use
ISA09 I08 Interchange Date
Description: Date of the interchange.
M DT 6/6 Must use
ISA10 I09 Interchange Time
Description: Time of the interchange.
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 Name U 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
401 401 Draft Standards for
Trial Use Approved for Publication by ASC X12 Procedures Review Board through October 1997.
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.
M NO 9/9 Must use
ISA14 I13 Acknowledgment Requested
Description: Code sent by the sender
to request an interchange acknowledgment (TA1). M ID 1/1 Must use Code Name 0 No acknowledgement required.
Note: No other codes are supported in
this implementation at this time.
Ref ID Element Name Req Type Min/
Max
Example
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.
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 Name
P Production Data
T 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
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
GS01 479 Functional Identifier Code
Description: Code identifying a
group of application related transaction sets.
M ID 2/2 Must
use
Code Name
PT Product Transfer and
Resale Report (867)
Note: No other codes are
supported in this implementation at this time.
GS02 142 Application Sender's Code
Description: Code identifying
party sending transmission; codes agreed to by trading partners.
M AN 2/15 Must
use
GS03 124 Application Receiver's Code
Description: Code identifying
party receiving transmission. Codes agreed to by trading partners.
M AN 2/15 Must
use
GS04 373 Date
Description: Date expressed as
CCYYMMDD
M DT 8/8 Must
GS05 337 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)
M TM 4/8 Must
use
GS06 28 Group Control Number
Description: Assigned number
originated and maintained by the Sender
M NO 1/9 Must
use
GS07 455 Responsible Agency Code
Description: Code used in
conjunction with Data Element 480 to Identify the issuer of the standard. M ID 1/2 Must use Code Name X Accredited Standards Committee X12
Note: No other codes are
supported in this implementation at this time.
GS08 480 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
M AN 1/12 Must
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
part-ners to select the appropriate transaction set definition (e.g., 810 selects the Invoice
Transac-tion Set).
Element Summary
Code Name 00401 0 Draft Standards Approved for Publication by ASC X12 Procedures Review Board through October 1997.Note: No other codes are
supported in this implementation at this time.
Example
GS*PT*THEIESO*000000*20001213*1740*636*X*0040101
Ref ID Element Name Reg Type Min/
Max
Usage
ST01 143 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
BPT Beginning Segment for Product Transfer and
Resale
To indicate the beginning of the Product Transfer and Resale Report Transaction Set and
trans-mit identifying data.
Semantics
1.
BPT02 identifies the report number.
2.
BPT03 identifies the report date.
Element Summary
ST02 329 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 0001.
M AN 4/9 Must use
Example
ST*867*0001
Ref ID Element Name Req Type Min/
Max
Usage
BPT01 353 Transaction Set Purpose Code
Description: Code identifying
M ID 2/2 Must
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.
BPT02 127 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.
O AN 1/30 Used
BPT03 373 Date
Description: Date expressed as
CCYYMMDD. Transaction Creation Date
M DT 8/8 Must
use
BPT04 755 Report Type Code
Description: Code indicating the title
or contents of a document, report or supporting item.
O ID 2/2 Used
Code Name
C1 Cost Data Summary
Description: Interval readings.
Ref ID Element Name Req Type Min/
Max
N1 Name
To identify a party by type of organization, name, and code.
Syntax
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.
Note:
No other codes are supported
in this implementation at this time.
The full UIG EDI-867
specification does allow for other
codes.
BPT09 127 Reference information as defined
in the 'Request Reference' field of the EDI request file
Example
Element Summary
Ref ID Element Name Req Type Min/
Max
Usage
N101 98 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 Consumer Service Provider (CSP) Description: Local Distribution Company (LDC) EC Exchanger Description: Used to
identify the organization running the market.
SJ 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.
N102 93 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.
N103 66 Identification Code Qualifier
Description: Code designating the
system/method of code structure used for Identification Code (67).
C ID 1/2 Must use
Code Name
ZZ 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.
N104 67 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".
C AN 2/80 Used
N106 98 Entity Identifier Code
Description: Code identifying an
organizational entity, a physical location, property or an individual.
Note: The UIG spec allows for the use of N2, N3, and N4 segments. These segments provide
additional information regarding address and location. These segments are not used in this
implementation.
REF Reference Identification
To specify identifying information.
Comments
Only one REF01 code is required.
Element Summary
Note: The entity providing the data
(in this case the IESO) will always be considered the Submitter. The entity receiving the data (in this case the participant) will always be considered the Receiver. Use of these codes may change with transactions between other trading partners.
Example
N1*EC*Independent Electricity System Operator*ZZ*THEIESO**41 N1*SJ*Big Electric Co*ZZ*000000**40
Ref ID Element Name Req Type Min/
Max
Usage
REF01 128 Reference Identification Qualifier
Description: Code qualifying the
Reference Identification
M ID 2/3 Must
use
Code Name
Ref ID Element Name Req Type Min/
Max
PTD Product Transfer and Resale Detail
Syntax
If either PTD04 or PTD05 is present, then the other is required.
Comments
Each PTD loop will represent a meter register, whether demand, monthly, or detailed interval
data.
LU Location Number
Description: The Metering
System identifier as assigned by the IESO.
Note: This reference is not
necessarily numeric. Alternatively, the world 'ALL' indicating that the transaction set should contain (each in separate PTD loops) all of the delivery data available to the requesting entity for the requesting period.
Note: No other codes are supported in
this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
REF02 127 Reference Identification
Description: This represents the
Metering System identifier or the word "ALL" for reports on all meters under contract for a given report request range. These IDs are assigned to points by the IESO.
C AN 1/30 Must
use
Example
Element Summary
Ref ID Element Name Req Type Min/
Max
Usage
PTD01 521 Product Transfer Type Code
Description: Code identifying the
type of product transfer
M ID 2/2 Must use Code Name PM Physical Meter Information Description: Individual meter installation.
Note: No other codes are supported
in this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
PTD04 128 Reference Identification Qualifier
Description: Code qualifying the
Reference Identification. The Reference Identification Qualifier will always be "OZ" for this implementation.
C ID 2/3 Used
Code Name
OZ Product Number
Note: No other codes are supported
in this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
PTD05 127 Reference Identification
Description: Reference
information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
C AN 1/30 Used
Code Name
REF Reference Identification
To specify identifying information.
Comments
At least three REF records are required for every PTD loop: LU, MT, and MG if metered
service - LU, MT, and SC if un-metered service.
Element Summary
Note: No other codes are supported
in this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
Example
PTD*PM***OZ*EL
Ref ID Element Name Req Type Min/
Max
Usage
REF01 128 Reference Identification Qualifier
Description: Code qualifying the
Reference Identification
M ID 2/3 Must use
Code Name
6W Sequence Number
Description: Optional
channel number. Only used when there is more than one channel on a meter measuring the same quantity (e.g. two KWh channels).
LU Location Number
MG Meter Number
Description: Required.
The physical meter serial number or seal number. MT Description: Required.
Used to identify the type of consumption measured by this meter and register. Defines the interval between measurements. See REF02 for examples.
Note: No other codes are supported in
this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
REF02 127 Reference Identification
Description: Reference information
as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
User Note 3: When REF01 is MT, the meter type is expressed as a five character field. The first two characters are the type of consumption, expressed as:
K3 - Kilovolt Amperes Reactive Hour KH - Kilowatt Hour
68 - Amperes (represented in Ampere Squared Hours)
70 - Volts (represented in Volt Squared Hours)
The next three-characters are the metering interval, expressed as: NNN = number of minutes; from 001 to 999 in factors or multiples of 5
C AN 1/30 Must use
Examples
KHMON Kilowatt hours used during the month. KH060 Hourly intervals data.
K1015Highest demand 15 min in which its time stamp in the QTY loop identifies the time that this 15 minute demand took place
REF03 352 Description:
Description: A free form description to clarify the related data elements and their content.
C AN 1/80 Used
Ref ID Element Name Req Type Min/
Max
QTY Quantity
To specify quantity information.
Element Summary
Example
REF*LU*1000000051 REF*MG*R077738 REF*MT*KH005
Ref ID Element Name Req Type Min/
Max
Usage
QTY01 673 Quantity Qualifier
Description: Code specifying the
type of quantity M ID 2/2 Must use Code Name 87 Quantity Received. Description: Used to
indicate power flow into the grid.
QD Quantity Delivered
Description: Used to indicate power flow out of the grid.
Note: No other codes are supported
in this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
QTY02 380 Quantity
Description: Numeric value of
quantity
C R 1/15 Must
355 Unit or Basis for Measurement Code
Description: Code specifying the
units in which a value is being expressed, or manner in which a measurement has been taken
M ID 2/2 Must
use
Code Name
68 Description: Amperes
squared hours. Note: If this value is reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 68 is non-standard.
70 Volts
Description: Volts
squared hours. Note: If this value is reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 70 is non-standard.
K3 Kilovolt Amperes
Reactive Hour (KVARH)
Description: The total
reactive energy delivered to the load, the product of reactive power (kVAR) and the length of time (hours). Reactive energy is energy that cannot perform any work.
KH Kilowatt Hour (KWH)
Description: The total real energy delivered to the load, the
accumulation of the product of real power (KW) and time in hours. Real energy is energy that can perform actual work.
Ref ID Element Name Req Type Min/
Max
MEA Measurements
To specify physical measurements or counts, including dimensions, tolerances, variances, and
weights.
Syntax
1.
At least one of MEA03, MEA05, MEA06 is required.
2.
If MEA07 is present, then at least one of MEA03, MEA05 or MEA06 is required.
Semantics
MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
Comments
1.
On the MEA record, the beginning and ending read are always provided for all KH and
K3 type measurements, except interval reads.
2.
On the MEA record, when interval reads are being provided the interval pulse count may
be provided in MEA06.
3.
MEA05 and MEA06 will not be used by the Independent Electricity System Operator.
4.
The first QTY loop must contain a MEA segment.
5.
It is not necessary to provide an MEA segment for each subsequent QTY loop. Add an
MEA segment only when the attributes of the measurement change.
Note: No other codes are supported
in this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
Example
Element Summary
Ref ID Element Name Req Type Min/
Max
Usage
MEA01 737 Measurement Reference ID Code
Description: Defines the quality of
the meter read defined in MEA05 & MEA06.
O ID 2/2 Used
Code Name
The following four codes are required for monthly usage reads to qualify fields five and six. Not used for interval reads.
AA Meter reading-beginning actual/ending actual AE Meter reading-beginning actual/ending estimated EA Meter reading-beginning estimated/ending actual EE Meter reading-beginning estimated/ending estimated
BO Meter Reading as Billed
Description: Used when
billing charges are based on contractual
agreements or pre-established usage and not on actual usage. Physical allocations will use this designation. (This field will not be used in data transfers from the Independent Electricity System Operator)
MA02 738 Measurement Qualifier
Description: Code identifying a
specific product or process characteristic to which a measurement applies
Code Name
MU Multiplier
Required for non -interval usage.
PJ Pulse Width
Description: Pulse
multiplier
Note: No other codes are supported
in this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
MEA03 739 Measurement Value
Description: The value of the
measurement and only used if MEA02=MU
User Note 1: Represents the meter
constant when MEA02 = "MU". When no multiplier is present, use a value of "1".
C R 1/20 Used
MEA04 C001 Composite Unit of Measure
Description: To identify a composite unit of measure
C Comp Used
355 Unit or Basis for Measurement Code
Description: Code specifying the
units in which a value is being expressed, or manner in which a measurement has been taken. This should be the same as that found on the QTY record.
M id 2/2 Must
use
Code Name
Description: Amperes
squared hours.
Note: If this value is
reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 68 is non-standard.
70 Volts
Description: Volts
squared hours.
Note: If this value is
reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 70 is non-standard.
K3 Kilovolt Amperes
Reactive Hour (KVARH)
Description: The total
reactive energy delivered to the load, the product of reactive power (kVAR) and the length of time (hours). Reactive energy is energy that cannot perform any work.
KH Kilowatt Hour (KWH)
Description: The total
real energy delivered to the load, the product of real power (KW) and length of time (hours). Real energy is energy that can perform actual work.
MEA07 935 Measurement Significance Code
Description: Code used to
benchmark, qualify or further define usage conveyed in QTY02.
O ID 2/2 Used
Ref ID Element Name Req Type Min/
Max
REF Reference Identification
To specify identifying information.
Code Name
03 Approximately - used for
readings created through meter disaggregation.
22 Actual - normal usage
passed validation (included non-metered) 31 Calculated - reading created by PAD 39 Plugging from Redundant Meter
46 Estimated - usage not
derived from actual meter reads.
62 Current - current version
of data.
68 As Is - used to indicate
the first (raw) version of data.
83 83 Good Verified - value
appears anomalous but has been verified.
88 Adjusted
Note: No other codes are supported
in this implementation at this time. The full UIG EDI-867 specification does allow for other codes.
Example