Ontario EBT Standards Document

Gas Distribution Access Rule (GDAR)

Electronic Business Transactions (EBT) Standards Document

for the Gas Marketing Industry

May 9July 20, 2005

Version 0.05 GDAR EBT STANDARDS DOCUMENT

NOTICE OF DISCLAIMER

The information provided is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied.

vER Version 0.15 May 24July 20, 2005 Page 2 GDAR EBT STANDARDS DOCUMENT

Table of Contents Page GDAR EBT Standards Change Log 1. Introduction 1.1 Guiding Principles 1.2 Technology Introduction 1.4 Glossary of Terms Used in This Document 2. Summary 3. Technology Overview 4. Business Relationships 5. Electronic Business Transactions 5.1 Service Transaction Requests 5.2 5.3 5.4

GDAR EBT Standards Change Log

Revision Date Version Revised Section and Reason:

1. Introduction

The Gas Distribution Access Rule was issued by the Ontario Energy Board on December 11, 2002 pursuant to the delegated legislative power under section 44 of the Ontario energy Board Act in order to:  establish conditions of access to gas distribution services provided by a gas distributor; and,  establish rules governing the conduct of a gas distributor as such conduct relates to a gas vendor.

Further to this Rule, the Board issued a Decision in proceeding RP-2000-0001 dated May 9, 2005 in which it expressed the view that the development of a common Electronic Business Transaction (EBT) Standard is necessary for an efficient competitive gas market. The Board directed staff to develop draft EBT Standards containing adequate detail with respect to service transaction requests that will allow the market to operate competitively and ensure that consumers have the maximum choice of gas suppliers. To the maximum extent possible, the proposed EBT Standards mirror the EBT Standards used currently in the retail electricity sector.

1.1 Guiding Principles

The EBT Standards define the computer-based transaction mechanism for transmitting common format data among gas distributors and gas vendors, which shall be implemented by a gas distributor and a gas vendor (or trading partner, as appropriate)...

Nothing in the EBT Standards Document shall be interpreted as in any way interfering with the contractual rights or obligations of gas distributors, gas vendors or consumers or the remedies available to gas distributors, gas vendors or consumers to enforce those contractual rights or obligations.

A gas distributor shall take every reasonable step to ensure that all information concerning consumers in the gas distributor’s franchise area, including the identity of the consumer’s gas vendor and billing option, is accurate and up-to- date.

A gas distributor shall only use gas vendor information: (a) for purposes expressly set out in the Service Agreement; or, (b) as otherwise authorized by the Board.

A gas distributor shall not disclose any data or information acquired by the gas distributor regarding a gas vendor to anyone other than the Board or as otherwise required by law, without the written consent of that gas vendor, unless specifically authorized by the Board.

A gas distributor may disclose information that has been sufficiently aggregated such that an individual gas vendor’s information cannot reasonably be identified.

The gas distributor shall notify the requesting party of the gas distributor’s proposed Service Transaction Request (STR) implementation date as soon as practicable.

A gas distributor shall implement the direction contained in an STR in a timely manner, but in any event, no later than 60 days from the date that the gas distributor receives a valid and complete STR, provided that this time limit shall not include the time which elapses while the gas distributor has suspended processing the STR.

Any time a gas distributor rejects, stops or suspends processing an STR, the gas distributor shall include in any notification the specific reasons for the gas distributor taking this action.

All STRs between distributors and vendors shall be XML-based and structured in a format approved by the Board.

1.2 The Role of Point to Point and Hubs

The Ontario EBT Standards specify protocols for communication of EBTs between market participants using direct Point to Point connections and also using EBT Hubs. In situations where Point to Point market participants wish to communicate with Hub subscriber market participants, a communications protocol is specified for Point to Hub communications.

A Hub acts as a centralized point of communication for Trading Partners in their endeavours to operate in the open marketplace. An important role of a Hub is to validate and acknowledge transactions that are error free and reject transactions with errors according to approved standardized schemas.

In the case of multiple Hubs serving the Ontario marketplace, the Hubs will communicate among themselves to pass transactions between trading partners. In this way, any trading partner will only need to communicate with one Hub, even if the receiving trading partner is using a different Hub. Part of each Hub’s functionality will be to direct the transactions to the correct trading partner using the Hub that the receiving trading partner is connected to. All Hubs serving the Ontario retail gas marketplace will be certified using a set of tests mutually agreed upon by the Hubs. This will ensure that the EBT Standards defined in this document are used throughout Ontario for all Market Participants connected to any Hub.

Initial Hub functionality provides simple mail boxing of EBTs. It provides a store- and-forward service for transactions as well as an archive and audit trail of all

vER Version 0.15 May 24July 20, 2005 Page 6 GDAR EBT STANDARDS DOCUMENT transactions. Each Hub also issues Functional Acknowledgements for all transactions in both the reject and accept states.

 The Hub verifies and validates that the Trading Partner is an authorized market participant, as defined by the OEB.  The Hub verifies users against a trading partner directory.  The Hub administration certifies all trading partners before they become Hub users.  The Hub administration may provide testing and training for Hub users.  Each Hub acts as a centralized repository for Schemas. All EBT Transactions for the Province of Ontario flow through a Hub to Spoke, a Hub to Point or a Point to Point connection.  The Hub rejects EBTs that do not adhere to the standardized transaction formats.  The Hub ensures First-In-First-Out (FIFO) processing of all files by recording a date and time stamp.  The Hub provides a transaction-level tracking system that acts as an audit trail for all transmissions that pass through that Hub.  The Hub assumes that it is the responsibility of the originator of all files to place the transactions into the proper business order for processing.  The Hub may provide manual entry of EBTs for small- to medium-sized market participants.  The Hub will not allow End-Use Consumers to have access to the Hub. Consumer access to information will be provided via a Vendor or Distributor website.

Further levels of functionality may be evaluated and implemented as needed and justified. The functionality could include such things as limited CIS "awareness". It could enable STR responses at the Hub level by maintaining replicated Distributor databases. It could also be expanded to include the provision of an end-use Consumer database of meter data, history, and information.

1.3 Technology Introduction eXtensible Markup Language (XML) will be the technology to implement EBT. XML introduces a framework of standardized business-to-business electronic transactions that will improve the competitive landscape of the deregulated retail energy industry. Electronic business transactions amongst trading partners are complex, data-intensive communications that are usually costly to establish and maintain. By implementing an XML-based electronic business transaction standard for deregulation, the barrier of entry for Market Participants is lowered by providing a cost-efficient, reliable, and ‘open’ means of communication between Trading Partners. Some of the benefits of using XML include:

 XML’s ease of development allows small- and medium-sized participants to maintain flexibility while interacting with a wide range of trading partners.  XML creates a richer structural and semantic environment to express the many roles and relationships among Market Participants.  XML’s extensibility is key to fulfilling its promise of simplified standards. Ease of parsing and validation allows developers to quickly adapt to changes in the industry.  XML is designed for use on the Internet, allowing Trading Partners to minimize their costs.  XML is widely accepted across many industries.  XML is readable and easily parsed by computers.  XML is available in a wide variety of low-cost tools, such as Internet Explorer.

XML is a tag-based framework used primarily to organize data in a universally understood format. XML is a subset of the Standard Generalized Markup Language (SGML) and is similar to Hyper Text Markup Language (HTML). The use of XML facilitates the transmission of information from system to system, independent of platforms. XML was created to deliver structured, readable, usable information over the Internet platform. It is a generalized markup language that is platform-independent and extremely flexible. XML can be used to specify the presentation of a document (font size, indentation, etc.) or to specify structure of the document through Document Type Definitions (DTDs) or schemas. XML is designed for Web usage and introduces a new class of documents that do not require a predefined document type. The benefit of XML is that it provides a standard that allows the capacity for processing information by non-proprietary software such as search engines, browsers, and parsers. As the interest in E-commerce and EDI over the Internet increases, XML is proving to be a leading factor in enabling business-to-business electronic commerce.

Glossary of Terms Used in This Document

This glossary has been prepared solely for the convenience and assistance of readers by providing a narrative, non-technical description of some of the terms used in the sections of this document.

Authentication: The logon message is utilized to authenticate a user attempting to establish a connection to a remote system. Bill Ready: A consolidated billing practice in which the billing party receives the calculated charge amount(s) directly from the non-billing party (rather than the billing party calculating it directly from the rate). Blackout Period: A window or lead-time during which a Distributor may suspend the processing of STRs until the next billing cycle. Consumer: A person who uses gas for that person’s own consumption. Consumer Information: Data and/or information collected and maintained b y a gas distributor pursuant to section 5.1 of the Gas Distribution Access Rule. Document: Group of batched transactions, same as PIPE document. Document Type Definitions (DTD): Content and element validation code used to support each document. E-commerce: Business to business electronic transactions Electronic Business Transaction (EBT) Clearinghouse: A computer-based transaction mechanism for transmitting common format data between market participants. Electronic Data Interchange (EDI): Use of a standardized format to define electronic business transactions. Encryption: The exchange of sensitive data across public carrier networks may make it advisable to employ data encryption techniques to mask the application messages. The choice of encryption method will be determined and standardized. End-Use Consumer: see Consumer Enrolment: The process of signing up a Consumer for competitive gas supply. Hub: A centralized computer system that enables the Trading Partners to connect and route EBT transactions. Flow: Gas flow to a Vendor’s new Consumer begins when the Distributor generates the first meter read. The date when gas starts to flow is the “Flow Date” defined below. Flow Date: The flow date is the date that the Consumer begins receiving gas from the new Vendor and is no longer on System Gas, or being supplied from a previous Vendor. Any charges and related costs for gas used by the Consumer on, and after, this date will be made through the new Vendor. Likewise, the new Vendor begins charging the Consumer for gas on, and after, this date. Franchise Area: The area of the Province of Ontario, either for which a gas distributor holds a Certificate of Public Convenience and Necessity granted by the Board, or in which a gas distributor was supplying gas on April 1, 1933. Gas: Natural gas, substitute natural gas, synthetic gas, manufactured gas, propane-air gas or any mixture of any of them.

Gas Day: A period of 24 consecutive hours commencing at 9:00am Central Time on a given calendar day. Gas Distribution System: A system used to provide gas distribution services. Gas Distribution Services: The services related to the delivery of gas to a consumer, including related safety functions such as emergency leak response, line locates, inspection, and provision of safety information. Gas Distributor: A person who delivers gas to a consumer. Gas Distributor-Consolidated Billing: A method of billing whereby a gas distributor issues a single bill to a consumer setting out the charges for gas distribution services and the charges for the gas commodity. Gas Vendor: A person that holds a gas marketer’s licence granted by the Board authorizing that person towho (a) sells or offers to sell gas to a low-volume consumer, or (b) acts as the agent or broker for a seller of gas to a low-volume consumer, or (c) acts or offers to act as the agent or broker of a low-volume consumer in the purchase of gas. Gas Vendor-Consolidated Billing: A method of billing whereby a gas vendor issues a single bill to a consumer setting out the charges for gas distribution services and the charges for the gas commodity. Gas Vendor Information: Data and/or information provided by a gas vendor to a gas distributor concerning that gas vendor. Hyper Text Markup Language (HTML): The basic language of the Web, which tells Web browsers how to display elements such as text, headlines and graphics. Low-volume Consumer: A person who annually uses less than 50,000 cubic meters of gas. Meter: A device owned or controlled by a gas distributor and used to measure the units of gas consumption which form the basis for billing the consumer. Nomination: A request for a physical quantity of natural gas under a specific purchase, sales, or transportation agreement or for all contracts at a specific point. Ontario Energy Board (OEB): An independent, self-financing Crown corporation that regulates Ontario’s natural gas and electricity sectors. Partner Interface Process (PIP): Transaction container for an individual utility trading partner, such as Enrol STR. Partner Interface Process for Energy (PIPE); XML-based messaging protocol for the exchange of transactions among trading partners in the retail energy industry. PIPE Document: Document container for a trading partner directory and one or more PIP transactions. Rate Ready: A consolidated billing practice in which the non-billing party provides rate information to the billing party sufficient for that billing party to calculate the non-billing party’s charges. Rescission Period: The ten-calendar day period that commences when a written copy of the contract is delivered to the Consumer, and during which the Consumer is restricted from reaffirming the contract. A Vendor must hold the

Enrol STR until the Rescission Period is over, and the Consumer has reaffirmed the contract. Schemas: Content and element validation code used to support an XML transaction. Service Transaction Request: A direction between a gas distributor and/or a gas vendor(s). Split Billing: A method of billing whereby the gas distributor issues a bill to a consumer setting out the charges for gas distribution services, and the gas vendor issues a bill to a consumer setting out the charges for the gas commodity. Standard Temperature and Pressure (STP): Temperature of 15 degrees Celsius and absolute pressure of 101.325 kilopascals (kPa) at which the volume of gas measures on cubic metre (m 3). Standardized General Markup Language (SGML): Highly complex vigorous language with tags for structure content. System Gas: Gas which is sold or available to be sold by a gas distributor to a consumer. Trading Partner Directory: Defines all trading partners within the entire PIPE Document message. Transaction: A message from one trading partner to another in a standardized format. Transaction set: Multiple transactions of the same type, e.g., STRs, meter data transactions. Usage: The actual consumption (cubic meters) used by the Consumer during a period as measured by the meter. eXtensible Markup Language (XML): A tag-based framework used primarily to organize data in a universally understood format; it facilitates the transmission of information from system to system independent of platform. XML was created to deliver structured content over the Internet. eXtensible Style Language (XSL): The standard style sheet language for XML.

2. Summary

The remainder of this document is comprised of the following sections:

Section 3. Technology Overview This section is a high-level discussion of the technology considerations for implementing EBT in Ontario.

Section 4. Business Relationships This section summarizes the relationships between the Consumers, Vendors and the Distributors. It is intended to foster the development of a mutual understanding of those relationships.

Section 5. Electronic Business Transactions This section defines a set of electronic business transactions corresponding to the business relationships described in Section 4. It also includes a description of the business rules that govern the use of the transactions.

Appendices:

Appendix A: References. This appendix contains references for the Schemas and Implementation Guides that are part of these Standards. This appendix also contains references for other documents which are useful in using these standards such as … {possibly to be named later}

3. Technology Overview

This section describes the technology considerations to implementing the EBT System beyond the choice of XML as an EBT format and translation standard as described in Section 1.3, Technology Introduction. Technology must also be employed to ensure the security, reliability, and data transport of EBTs to and from Trading Partners.

Public Key Infrastructure technology (PKI) was chosen as the key standard to adopt in ensuring EBT Internet security characteristics of Privacy, Authentication, Integrity, and Non-repudiation (“PAIN”). Specific technology standards followed are Secure Multipurpose Internet Mail Extensions (S/MIME) employing Triple Digital Encryption Standard (DES) for encryption and Secure Hash Algorithm (SHA) for Digital Signature.

A discussion of EBT transport alternatives initially considered for the Ontario deregulated electricity market can be found in the EBT Standards Document for Retail Settlement in the Electricity Retail Open Access Industry.

4. Business Relationships

The business relationships described in this document are intended to serve as a general guide for established standards for exchanging information. The business relationships to which the standards will be applied in accordance with the OEB’s Rules are defined below, and represent the current understanding of each person’s responsibilities.

Consumer:

1. Provides appropriate authorization to a Vendor for release of historical consumption and payment history information from the Distributor to that the Vendor. 2. Selects one Vendor for enrolment per Distributor account. 3. Provides the applicable Distributor account identification to the Vendor or authorizes Vendor to obtain the account identification. 4. Provides the appropriate authorization for the Vendor to enrol the Consumer. 5. Selects a billing option per Distributor account from Vendor, if offered or applicable. 6. Notifies Vendor to drop from Vendor to System Gas.; alternatively may contact Distributor to drop to System Gas but may incur charge with this option if off-cycle. 7. Notifies Distributor or Vendor of a move, initiation, or disconnect of Distributor service.

Consumer’s Agent :

1. Any action required or permitted to be performed by a consumer may be performed by an agent authorized in writing by the consumer.

Vendor:

1. Obtains licence from the Ontario Energy Board, if required. 2. Enters into a service agreement with each Distributor in whose territory it will operate. 3. Obtains the appropriate authorization from the Consumer for historical consumption information and payment history information to be released by the Distributor to the Vendor. 4. Obtains the appropriate authorization from the Consumer for Enrol STR.

5. Obtains the required information from the Consumer to enrol the Consumer on the Distributor’s records. 6. Submits Enrol STR after the rescission period has passed and reaffirmation has been received, if applicable. There is one enrolment per Distributor account and one billing option per Distributor account. 7. Sends the applicable information via the EBT system to the Distributor for Consumer enrolment, changes, or termination of service. 8. Provides the Distributor with billing options and pricing information for the Distributor-Consolidated Billing option or renders its own bills to the Consumer for service. 9. Maintains its own set of records to reconcile information from the Distributor related to Consumer information and accounts receivable. 10.Completes required training and electronic systems testing of its EBT solution prior to Consumer enrolment. 11.Identifies both a business and a technical contact to facilitate inter-business communications. 12.Contacts each Distributor for company-specific information. 13.Processes transactions according to EBT standards, including use of a functional acknowledgement. 14.Responsible for collecting own arrears from the Consumer on Vendor- Consolidated Billing or Split Billing. 15.Requests Consumer and Historical Usage data as separate STRs.

Distributor:

1. Retains consumer information, at a minimum, until the later of:  24 months;  the period of time required by the Board; and  the period of time required by law.

2. Provides a consumer unfettered access to the meter for interrogation provided:  the device used to interrogate the meter complies with the gas distributor’s reasonable technical requirements; and  such access to the meter does not interfere with the operation or function of the meter or impair or impede the ability of the gas distributor to read the meter at normally scheduled times.

32. Creates or obtains, at a minimum, and maintains the following information on all consumers who are provided gas distribution services by the distributor:

for identification purposes:  consumer name;  service address, including postal code where applicable;  consumer mailing address, including postal code;  consumer distribution service account number;  meter identification number;

for billing purposes:  billing address, including postal code;  gas distribution services contracted for;  units of consumption (corrected for STP), estimated or actual, by billing period;  meter reading dates;  dates of bills rendered based on actual meter readings;  dates of bills rendered based on estimated meter readings;  dates of bills rendered based on methods other than actual or estimated meter readings;  method of bill calculation (e.g., equal billing);

for payment profile purposes;  payment due dates, payment receipt dates;  number of times the consumer was delinquent or in arrears in the past 24 months;  maximum credit exposure in the past 24 months;  number of times the consumer’s security arrangements were revised in the past 24 months;

for consumption information;  24 months of consumption data per individual meter by individual distribution service consumed.

43. Shall only use consumer information:  necessary to provide gas distribution services;  necessary for system operations;  necessary to provide system gas;  for purposes expressly set out in the Service Agreement; or  as otherwise authorized by the Board.

5. Shall not disclose any data or information acquired by the gas distributor regarding a consumer to anyone other than the Board, or any person as required by law, without the written consent of that consumer, unless specifically authorized by the Board. (A gas distributor may disclose information that has been sufficiently aggregated such that an individual consumer’s information cannot reasonably be identified.)

6. Provides consumer information listed above in item 3 with respect to a consumer in accordance with any written direction received from that consumer, and in a format requested by the consumer, if available, or, at a minimum, in hard copy. Any action required or permitted to be performed by a consumer may be performed by an agent authorized in writing by the consumer.

7. Renders bills to the Consumer as required by Consumer/Vendor relationshipa Service Agreement between the parties.

8. Provides the Vendor with invoice meter data information as required by the agreed upon billing option.

9. Identifies both a business and a technical contact to facilitate inter-business communications.

10. Is the sole party who can terminate (i.e. physically connect and disconnect) gas service to the Consumer.

11. Processes EBT transactions and updates Consumer account information according to EBT standards, including use of Functional Acknowledgements on all transactions.

5. Electronic Business Transactions

This section describes the EBT Standards, business process flows and business rules. The following table lists the EBTs, their associated flows and section reference numbers. Appendix A contains a reference to the list of mandatory and optional transactions for the Ontario Gas Market. [Table below to be updated later]

Transaction Set Flows Section

Service Transaction Requests (STR) Enrol Request, Reject, Accept STR-1, 2, 3, 4, 5, 6, 7, 5.1.1 8, 9, 10, 11, 12, 13 Consumer Information Request, Reject, Accept STR-1, 2 5.1.2 Historical Usage STR-14 5.1.2 Payment History STR-15 5.1.2 Meter Change Request, Reject, Accept STR-16, 17 5.1.3 Consumer Information Change Request, Reject, Accept STR-18, 19 5.1.4 Change Consumer Location Request, Reject, Accept STR-20, 21, 22, 23, 24, 5.1.5 25 Drop Request, Reject, Accept STR-26, 27, 28 5.1.6

Meter Data Transaction (MDT) Usage MDT-1 5.2.1 Meter Maintenance MDT-2, 3, 4, 5 5.2.2 Historical Usage Accept MDT- 6, 7 5.2.3

Invoice Transaction (INV) Split Billing INV-1 5.3.1 Distributor Consolidated - Bill Ready INV-2 5.3.2 Distributor Consolidated - Rate Ready INV-3 5.3.3 Retailer Consolidated - Bill Ready INV-4 5.3.4 Retailer Consolidated - Rate Ready INV-5 5.3.5 Settlement Invoice - Retailer Consolidated Bill Ready INV-6 5.3.6 Settlement Invoice - Retailer Consolidated Rate Ready INV-7 5.3.6 Settlement Invoice - Distributor Consolidated Bill Ready INV-8 5.3.6 Settlement Invoice - Distributor Consolidated Rate Ready INV-9 5.3.6 Settlement Invoice - Split Billing INV-10 5.3.6 Market Participant Invoice INV-11 5.3.7

Transaction Set Flows Section

Remittance (PA) Settlement Remittance PA-1 5.4.1 Market Participant Remittance PA-2 5.4.2

Net System Load Shape Daily (NSLS) Net System Load Shape Daily none 5.5

CSV Transport (CSV) CSV Transport CSV-1 5.6

Application Advice (AA) Application Advice Accept AA-1, 2 5.7

Status Advice (SA) Status Advice Various Flows 5.8

Functional Acknowledgements (FA) Functional Acknowledgements FA-1, 2 5.9

Business Rules for All Transaction Sets

Below are the business rules that correspond to every electronic transaction.

 All trading partners, including Hubs if applicable, generate a Functional Acknowledgement upon receipt of every PIPE document.  All EBTs contain the basic information identifying the sender and receiver by their OEB Licence numbers in the case of Vendors, or their self- identified unique number in the case of Distributors (a cross-reference to the list of OEB licence and self-identified numbers can be found in Appendix A).  All transactions must be given a unique transaction number assigned by the originator.  All transactions must be date/time stamped upon creation by the originator of the transaction.  In certain circumstances, the recovery of EBT processing costs from Vendors by Distributors is allowed. The relationship between the services for which this recovery is allowed specific EBTs is documented in Appendix B.

Technical Rules for All Transaction Sets

Below are technical rules that apply to every electronic transaction:

 Transactions should be collected together into PIPE documents for transmission between hubs, spokes and points. Large numbers of very small documents and single documents containing very large numbers of transactions create processing and efficiency problems for the Hubs and market participants. It is intended that market participants pack as many transactions as possible, up to a reasonable limit, into a single document before sending the document on to its intended recipient. To that end, there is a set quantifiable lower limit to the number of transactions that can be packed into a document. If a trading partner sends over 100 PIPE documents per day to a given recipient, the mean daily average number of PIP transactions per PIPE document must be greater than ten transactions per document. There are no limitations on trading partners sending less than this threshold per day.  The plaintext EBT document must not be larger than 500Mb prior to encryption and compression.  When Market Participants reject EBT transactions, it may not be clear what Market Participants mean by their Reject Reasons. Different Market Participants may use the same Reject Reason to mean different things, or the same error condition may be reported in different ways. Appendix A contains a reference to a list of Reject Reasons that have been standardized in order to reduce the amount of manual effort required to process corrections. Each Market Participant must decide whether or not

to reject a transaction based on its own business process. It is acknowledged that there are various ways to manage error conditions. For example, one Market Participant may choose to reject an EBT transaction and another may choose to handle the error condition through off-line processes. The fact there is a list of Reject Reasons does not mean to imply that all Market Participants must use all the listed Reject Reasons. However, if an EBT reject transaction is sent for one of the reasons listed, it must be reported using the associated Reject Reason text.  The interval between a Request transaction and a Response transaction is measured from the time the PIPE document containing the Request transaction is made available for download at the Request sender’s hub, to the time the PIPE document containing the Response transaction is made available for download at the Response sender’s hub. The interval is measured in business days. This convention is applicable to all transaction response intervals.  In situations where an element is optional and the trading partner does not have any data for the field, the trading partner should not include the element and pass an empty field or load the field with fill characters (e.g., blanks) in order to pass XML validation. In an optional field, if there is no data to convey the optional field must be absent from the transaction  The time zone within dates is represented as a two-byte abbreviation. Within the EBT Standards, only Eastern Standard Time is to be used The abbreviation for the Eastern Standard Time zone is: o ES = Eastern Standard Time (EST)  The definition for time within the XML schema definition language defines midnight as 00:00:00. Note: Gas Day normally defined as commencing at 9:00am Central Time – may need discussion as to definition of times to be standardized in the EBT Standards and systems.  Any telephone numbers presented in EBTs must be fully formatted including any standard punctuation. For example, North American telephone numbers should be presented in the following way for numbers without extensions: 999-999-9999 Or in the following way if the telephone number includes an extension (the extension number may be of variable length): 999-999-9999x99999  Any postal codes presented in EBTs must be fully formatted including any standard punctuation. Canadian postal codes must be seven characters long with a space in the middle of the code and the letters must be presented as upper case as per the Canadian Postal Code Standard. U.S. zip codes must be either five or ten characters long, and those that are ten characters long must have a hyphen after the fifth digit. o Canadian postal code example: . “A9A 9A9” o U.S. zip code examples: . “99999”

. “99999-9999”  Where address fields are used in an EBT, the following rules are to be followed: o The values to be used to populate the “Province” field and the “Country Code” field are to follow the Province, State and Country Code standard abbreviations used by Canada Post; o The “Province” field is a mandatory field that must be populated correctly for addresses in Canada or the U.S. Where the address being provided is in a Country other than Canada or the U.S., the Distributor shall populate the field with a valid default province/state code of their choice; and o The “Country Code” field is optional in the schemas; however, it is mandatory under some conditions (conditional logic of this kind cannot be adequately represented in the schemas). The field must be populated in the case where the address is in a Country other than Canada. Where the address is in Canada, population of the “Country Code” field is optional. Therefore, if the field is left unpopulated, the country for the address must be Canada.

EBT Life Cycle Example

This section describes a simple scenario for EBT transaction processing between a Distributor and a Vendor, from the Distributor’s perspective. The billing option used in this scenario is Distributor Bill-Ready Consolidated Billing.

Initiating the Enrolment A Consumer who wishes to change his or her electricity supplier from the Distributor to a Vendor contacts the Vendor to initiate this process. It is assumed in this scenario that the Distributor and Vendor are approved market participants. The Vendor sends an Enrol Service Transaction Request (STR) to the Distributor to initiate the process.

Hub Processing If the EBT is sent through a Hub, when the Hub receives the Enrol STR from the Retailer, the Hub validates the required data fields and their data type, according to the schemas (see a reference to the Schemas in Appendix A of this document). The Hub also verifies and validates that the Vendor is a licensed market participant and Trading Partner with the Distributor. A Functional Acknowledgement (FA) transaction is the result of both of these processes. The FA reports that the Vendor’s Enrol STR is syntactically correct by indicating either “acceptance” or “rejection”. An FA is the response for all non-FA transactions sent between Trading Partners.

If the Enrol STR is in error, the Hub sends the “reject” FA to the Vendor, who must then correct the Enrol STR and send the new corrected version to the Hub.

When the Hub receives a valid Enrol STR from the Vendor, it assigns an internal “receipt” date and time stamp to the transaction. The Hub forwards the verified and validated transactions to the Distributor in the order in which they were accepted from the Vendor. The Hub also “archives” the transaction for auditing purposes and file recovery.

Distributor Processing When the Distributor receives the Enrol STR, the Distributor validates it based on the application and business rules. The Distributor then sends an “accept” or “reject” STR response to the Vendor. The Vendor can also request Historical Payment or Historical Usage information for an account; however, these requests must be submitted as separate STRs from the Enrol STR. In the case of the Historical Usage Request STR, a request for Meter Information must also be submitted. There are several possible responses, depending on the specific information requested. The Distributor sends a Historical Payment Transaction, a Historical Usage Accept Transaction (MDT) response and a Meter Maintenance Transaction (MDT) response, or “reject” STR response. The Vendor may also submit a Meter Information request STR independent of Historical Usage Request STR. When the Vendor receives responses to any of the STRs, the Vendor validates the data and sends an Application Advice (AA), indicating “acceptance” or “rejection” of the data, to the Distributor.

After enrolment, at the next scheduled meter read date for the account, the Distributor reads the Consumer’s meter and sends the Usage Transaction containing the usage for the meter to the Vendor. In the event that the Distributor cannot read the meter, the Distributor sends a Status Advice (SA) to the Vendor indicating the new enrolment effective date and the reason for the delay. When the Vendor receives the Usage Transaction, the Vendor validates the data and sends an Application Advice (AA), indicating “acceptance” or “rejection” of the data, to the Distributor. If the Vendor rejects the Usage Transaction at the data level, the Distributor corrects and resends the new corrected version to the Vendor.

At the next meter read date for the Consumer’s account, the Distributor reads the meter and sends the billing usage information to the Vendor as a Usage MDT, according to the new billing cycle for the Consumer’s account.

Billing Period Processing At the end of the account’s billing period, the Vendor sends its portion of the Consumer’s bill to the Distributor as a bill-ready Invoice (INV). When the Distributor receives the Retailer’s bill-ready line items for its portion of the invoice, the Distributor validates the data and sends an AA, indicating “acceptance” or “rejection” of the data, to the Vendor. When the Distributor receives a valid invoice from the Vendor, the Distributor forwards a Payment Advice (PA) to the Vendor. This completes the billing process for the Consumer’s account

5.1 Service Transaction Requests

Introduction A “Service Transaction Request” or “STR” means a direction to a gas distributor, and includes resulting instructions that may be required between the Trading Partners to allow the market to operate competitively. STRs have many purposes, including those to accomplish the following business activities:  a change of gas supply from system gas to a gas vendor;  a change of gas supply from one gas vendor to another gas vendor;  a change of gas supply from a gas vendor to system gas;  a change in billing option for a consumer; and  a change in consumer service address when a gas vendor provides service. Note: GDAR provides that any change or modification in service not included in the above list may be processed in accordance with the gas distributor’s normal business practices (ref 4.1.2).

Validation of STRs for Enrol and Historical Usage After the distributor verifies a valid Service Agreement is in place, Tthe Distributor must perform a rigorous validation matching several criteria, collectively the “validation terms”, for each STR. These validation terms are:

(a) If the consumer has an account number with the gas distributor,  the gas vendor’s account number with the gas distributor;  the consumer’s account number with the gas distributor; and  at least one of: (1) the consumer’s name, and (2) the consumer’s postal code.

(b) If the consumer does not have an account number with the gas distributor,  The gas vendor’s account number with the gas distributor;  Tthe consumer’s name; and  Tthe consumer’s postal code.

The following rules apply:

 The vendor’s account number with the distributor, which is to be presented in the XML Account Validator field fully formatted as it appears in the Service Agreement. The vendor’s account number will be a unique alpha-numeric identifier assigned by the distributor. Note: the proposed Service Agreement does not currently require identification of a vendor account number. Further, this number is not unique to a transaction (i.e., it will apply to all STRs from the subject vendor), and therefore may not represent the best Account Validator. It is, however, the only required common element in (a) and (b) above.

 The consumer account number with the distributor is to be presented in the XML consumer “Account Number” field formatted as it is presented on the part of the bill retained by the consumer and as it appears in a field labelled "Account Number". The format should match the case, special characters, leading zeros and check-digits of those on the bill, which are deemed to match the information contained in the distributor’s information system (CIS). Note: this is a change from February 2004 GDAR EBT WG Interpretive Document which agreed that the account number would be stripped of any spaces or special characters.

 The consumer’s name is to be presented in the XML Name Validator field using the first four alpha-numeric print characters of the consumer’s name as it appears printed on the bill within the customer full name field. The first four alpha-numeric print characters will be formatted using uppercase only, (i.e., A-Z and 0-9) left to right with all other characters and blanks excluded. The name validator includes any salutations or initials presented on the bill with the name. The intention is that there is no contextual decoding of the name on the bill required in order to obtain a name validator. For example, the name validator for 'Ms. J. Smith' would be 'MSJS', the name validator for 'Mrs. J. Smith' would be 'MRSJ' and the name validator for 'I. Hu' would be 'IHU'.

 The consumer’s postal code of the mailing address is to be presented in the XML Address Validator field fully formatted including any standard punctuation. For example, the address validator for a Canadian address would look like “A9A 9A9” and the address validator for a U.S. address would look like “99999”, or “99999-9999”. Note: this is a change from February 2004 GDAR EBT WG Interpretive Document which agreed that the postal code would be stripped of any spaces.

Even though a good validation only requires the Account Validator plus any one of the other three two validators to be correctly matched, before a consumer is enrolled it is mandatory for the Vendor to present all three required validation terms in an attempt to uniquely identify the consumer. After the consumer is enrolled it is deemed that the consumer has been uniquely identified and only the account validator is mandatory. The other validators are optional in subsequent STRs. If present, however, they must correctly validate according to the rules defined above.

During account number validation, a trading partner should initially check the validation account number. If the Vendor does not recognise the value in the account number validator field, it should assume that the account number has changed and attempt to look into the message for a previous account number of the Distributor and use that account number for its validation. If the account number has changed and the Distributor does not recognise the value in the

vER Version 0.15 May 24July 20, 2005 Page 25 GDAR EBT STANDARDS DOCUMENT account number validator field as a current account number, it should attempt to recognise this value as a previous account number.

STR Responses Each STR transaction has an Accept transaction and a Reject transaction. STRs are the only EBTs that are designed this way. All other transactions such as Meter Data, Invoice, Payments and Status Advice are accepted or rejected with a transaction called the Application Advice detailed in another section.

All STRs must be responded to within five business days (NOTE: is number specified in electricity EBT – need to discuss) of receipt of the request. The response may be an “Accept” transaction or a “Reject” transaction. See Appendix A for a reference to the list of Reject Reason codes used in STR processing, and Section 5.0 under the heading ‘Technical Rules for All Transaction Sets’ for rules applying to Reject Reasons.

The following section describes each of the types of STRs. Process flows are provided for multiple scenarios of enrol, change, and drop STRs.

5.1.1 STR – Enrol

Note: As written, this section applies only where a consumer has an account number.

Definition/purpose The Enrol STR signs up the Consumer for competitive gas supplied by a Vendor. Only one enrol STR will be processed by the distributor at any time. If another Vendor sends an enrol request during the period prior to the effective date, the distributor will reject the 2 nd enrol with a reason of Pending enrolment. [need to clean up this wording].

Flow After the Consumer has signed a contract with the Vendor and the ten-calendar day rescission period is over, the Vendor sends the Distributor an Enrol Request.

General Description of Data The information sent in the Enrol Request includes the three validation fields described previously in this section, the billing option (Distributor Consolidated, Vendor Consolidated or Split Billing), and the effective date which shall coincide with the 1 st of a month. The Vendor shall ensure a valid and complete enrol request is submitted no less than 35 to 45 calendar days, and no more than 120 calendar days, prior to the effective date. and the read indicator that determines how the first meter read will be obtained to begin flow from the Vendor. The Enrol Request may ask for the effective date to coincide with the Consumer’s next scheduled meter-read date, the latest historical read, a specified meter reading, a meter change out, or a future meter cycle. The reading must be an actual meter read. An estimated reading may be used only with written consent from all parties.

Response The Distributor confirms the successful enrolment with the Enrol Accept. A successful Enrol Request matches the validation terms and contains all the necessary information regarding billing options and read indicators for the Distributor to process the request. Refer to Validation of STRs in the introduction to the STR section. The Enrol Accept file transaction contains a complete Consumer record including billing address information and, service address information, and any necessary billing cycle information. Accept transactions go back to the originator with correct information. This includes both the account number as formatted on the bill.and the account validator when an account number has changed. If the account number has changed, the accept response must also include the old account number in the old account number attribute. The Distributor tags the STR as “pending” until the effective flow date.

The Enrol Reject transaction informs the Vendor that the Enrolment was rejected, provides the reasons for the reject, and echoes back the Vendor’s request data

(i.e. mirrors, or echoes back what was sent in the request transaction). If there is an existing “pending” STR, the Distributor will send an Enrol Reject. If the Distributor determines that any information necessary to implement the pending STR is inaccurate or incomplete, the Distributor will suspend processing the STR. The Distributor shall resume processing the STR once the Vendor has provided the Distributor with all of the necessary information. If the necessary information has not been provided within 30 days from receipt of the STR (Enrol Reject), the Distributor will reject the STR. Possible Reject Reasons can be found using the reference in Appendix A, and the rules applying to Reject Reasons can be found in Section 5.0 under the heading ‘Technical Rules for All Transaction Sets’.

The accept or reject response must be sent within fourteen seven calendar days of the receipt of the request. This section may not apply to a municipality or municipal public utility that is not subject to rate regulation by the OEB, but in any event such public utilities shall send an accept or reject response within fourteen calendar days.

Rules The general rule for an STR is that there can be only one request for enrolment for one Distributor account, and one billing option per Distributor account. There are two basic types of STR Enrol transactions; the System Gas to Vendor, and the Vendor to Vendor Switch. Some of the possible scenarios are described below.

System Gas to Vendor Enrol In this scenario the Consumer is will be on system gas on the identified effective date when the Vendor sends an Enrol Request to the Distributor. If the STR contains valid entries for the validation terms, and there is not a pending STR with respect to the consumer, the gas distributor tags the STR as “pending”. If a pending STR exists for the consumer, the Distributor rejects the STR and notifies the Distributor Vendor by sending an Enrol-Reject with the appropriate Reject Reason. The Vendor starts providing gas to that Consumer on the next billing cyclerequested effective date.

Vendor to Vendor Switch

Need to define “effective Date ” or use “flow date” but not both. Need to define the standard enrolment service interval as well as all other lead times for STR and other transaction processing - ie Drops , Status Advice, responses, etc . Need to define Direct Purchase agreement/GTA/DP/Pooletc and use 1 term consistently throughout the document.

In this scenario there is already a Vendor (Vendor A) providing gas for the Consumer on the identified effective date at the time thatsubmitted by another Vendor (Vendor B) sends in an Enrol Request for the same Consumer. If the STR is well correctly formatted, contains all required data and can be processed, the Distributor must process the Enrol Request STR. Upon determining that the consumer is currently served by a Vendor (Vendor A), the transfer process is subjected to a Contest Period. The process flows as follows:

I. The Distributor verifies that the Effective Date requested by Vendor B is at least 30 days forward (the required Contest Period), in addition to the standard enrolment service interval (as defined in the Glossary). a. If the Effective Date meets or exceeds this service interval requirement, the Distributor continues to process the Enrol Request STR. Go to Step II. b. If the Effective Date does not meet or exceed this service interval requirement, the Distributor will respond to Vendor B with an Enrol Reject. The reject reason will indicate to Vendor B that the consumer is currently receiving service from a Vendor and is subject to a contest period. Vendor B may then resubmit a new Enrol Request STR to the Distributor with a revised Effective Date which provides for the standard service interval and the additional 30 day contest period requirement. Vendor B will also update any other additional information as required ( ie Direct Purchase agreement ID applicable to the new Effective Date). II. The Distributor responds to Vendor B with an Enrol Accept. III. Coincident with the above, the Distributor sends a Drop Transaction to Vendor A. The Drop Transaction provides the Effective Date that the consumer will be removed from Vendor A and also provides a reason which indicates that the consumer is being contested by another Vendor. IV. If the Drop Transaction is correctly completed and valid, Vendor A will respond with a Drop Accept transaction. (The Drop cannot be rejected by Vendor A because they contest the switch). V. Within the 30 day contest period, Vendor A may: a. Allow the Drop to proceed as scheduled. After the 30 day contest period expires the Distributor will send a Status Advice transaction to both Vendors confirming the switch. Vendor A will receive a Status Advice confirming they will lose the customer on the Effective Date and Vendor B will receive a Status Advice confirming they will begin supplying the consumer on the Effective Date. b. Upon authorization of the consumer, Vendor A may terminate the contest. Vendor A submits a Status Advice transaction to the Distributor requesting the Distributor to terminate the switch to Vendor B. The Distributor will then send a Status Advice transaction to Vendor B indicating the same. The switch to Vendor B is terminated.

VI. Within the 30 day contest period, the consumer may: a. Contact the Distributor to request cancellation of the switch to Vendor B. The Distributor sends out a Status Advice transaction to Vendor A terminating the Drop request and a Status Advice transaction to Vendor B terminating the Enrol request. The consumer remains with Vendor A. b. Contact Vendor B to terminate the switch to Vendor B. Vendor B sends a Status Advice to the Distributor terminating the Enrol Request. The Distributor sends a Status Advice to Vendor A terminating the Drop transaction. VII. Within the 30 day contest period, Vendor B may: a. Cancel the switch request by sending a Status Advice to the Distributor terminating the Enrol Request. The Distributor will send a Status Advice to Vendor A terminating the Drop request.

and send an Enrol Accept along with a notification called a “Status Advice” back to Vendor B. Vendor A also receives a copy of the “Status Advice”. This advice notifies the Vendors that there is a pending switch by a status code of “Notice of Pending Switch”, and the Vendor will return an Application Advice transaction to accept or reject the Status Advice.

It is foreseeable that there may be cases where the Consumer selects more than two Vendors and that those Vendors will attempt to enrol the same Consumer. The first valid enrolment received will be processed through to the Enrol Accept. The Distributor will reject the second enrolment request, and any subsequent enrolment requests, by returning an Enrolment Reject notifying the Vendor that there is already a pending enrolment on the account. In this manner, only one enrolment may be pending at one time.

Flow Date The flow date is the date that the Consumer begins receiving gas from the new Vendor and is no longer on system gas or a previous Vendor. Any charges and related costs for gas used by the Consumer on, and after, this date will be made through the new Vendor. Likewise, the new Vendor begins charging the Consumer for gas on, and after, this date. The flow date is communicated to a Vendor by returning it in the effective date field as part of the enrol accept transaction to the new Vendor.

Where adjustments are made for previous periods in which the consumer was served by another party, that party will be responsible for any charges (negative and/or positive) resulting from the adjustments.

Before the flow date, the enrolment must be cancelled via a Status Advice transaction of type 'Terminate Transfer Request'. After the flow date, the enrolment must be cancelled via a Drop transaction. If the Distributor Vendor

vER Version 0.15 May 24July 20, 2005 Page 30 GDAR EBT STANDARDS DOCUMENT must change the power gas flow date previously sent to a Vendor Distributor for any reason, it must send a Status Advice transaction of type 'New Effective Date' where the effective date within this transaction is the newly scheduled flow date. This transaction must be sent in accordance with the timing agreed to for an enrol request, i.e., at least “X” days prior to the new effective date. The Vendor Distributor will acknowledge the acceptance or rejection of the Status Advice using an Application Advice transaction.

NOTE: JUNE 22/23 REVIEW OF DOCUMENT ENDED AT THIS POINT.

Legend for Transaction Flows 1. Dotted lines indicate communication outside the EBT System. 2. Vendor A is the current or old Vendor and Vendor B is the new Retailer. 3. SA is an abbreviation for Status Advice in some flows. 4. The purpose or message of the Status Advice is abbreviated on the flows as follows: a. NED - New Effective Date b. TXReq – Terminate Transfer Request c. NPS – Notice of Pending Switch d. CCL – Consumer Change Location e. OTx – Original Transaction Number

TRANSACTION FLOW STR1 System Gas to Vendor Enrol - Accept

This is an Enrol STR with valid, complete information. The Consumer is on System Gas. The STR is accepted.

1. Enrol Request

VENDOR 2. Enrol Accept DISTRIBUTOR A

Flow: 1. Vendor A submits a valid Enrol Rrequest. 2. Distributor sends the Enrol Accept within 14 7 calendarbusiness days.

Rules: None

Exceptions: None

Roles and Responsibilities: None

TRANSACTION FLOW STR2 System Gas to Vendor Enrol - Reject

This is an Enrol STR. The Consumer is on System Gas. The STR is not valid and is rejected.

1. Enroll Request

VENDOR A 2. Enrol Reject DISTRIBUTOR

Flow: 1. Vendor A submits an Enrol Request with invalid information. 2. Distributor sends an Enrol Reject within 14 7 calendar days with reasons for the rejection.

Rules: The Distributor must provide information about all invalid fields.

Exceptions: None

Roles and Responsibilities: Vendor has 30 days from timestamp of STR2 to provide the required information in a new Enrol Request.None

TRANSACTION FLOW STR3 Enrol/Cancel (Before Flow)

In this scenario, the Consumer enrols with Vendor A, but before gas begins to flow, Vendor A wishes to cancel the enrol request.

1. Enrol Request

VENDOR 2. Enrol A Accept DISTRIBUTOR 4. Status Advice (TXREQ) (OTx=EnrolReq)

***Application Advice Accept or Reject must be sent for all Status Advice transactions to indicate an accept or reject of the transaction.

Flow: 1. Vendor A submits a valid Enrol Request to the Distributor. 2. Distributor sends an Enrol Accept to Vendor A within 14 7 calendar days. 3. Vendor A decides to cancel the enrolment. 4. Vendor A sends the Distributor a Status Advice (Terminate Transfer Request). 5. Consumer does not enrol with Vendor A.

Rules: None I. An Enrol Request may not be terminated within XX days of the effective date. II. If the Vendor attempts to terminate the transfer within this period, the Distributor will reject the Status Advice TXREQ with the correct standardized reason.

Exceptions: None

TRANSACTION FLOW STR4 Enrol/Switch-Reject (Pending Enrolment)

In this scenario, the Consumer is enrolled with Vendor A but the gas flow has not begun. Vendor B submits an Enrol STR.

1. Enrol Request

VENDOR DISTRIBUTOR B 2. Enrol Reject

VENDOR A

Flow: 1. Vendor B submits Enrol Request. 2. Distributor sends an Enrol Reject to Vendor B within 14 7 calendar days with reason “Pending STREnrol”.

Rules: None

Exceptions: None

Need a flow diagram for a contest period – all scenarios -

Need a flow diagram in which a customer moves during the pending enrol (prior to effective date)- several scenarios.

An enrol terminate before effective date rejected by distributor

Need a placeholder- new section to cover contract management – creating DPs/ price points , moving accounts between them etc . Perhaps could get agreement to address this in a next phase.

5.1.2 STR -- Consumer Information Requests: Historical Usage, Meter Information, and Historical Payment

Definition/Purpose The Consumer Information Request STR is issued by the Vendor to gather information about the Consumer. The Vendor can request usage history (consumption data), meter information, or payment history, as separate requests. The Vendor is responsible for obtaining and maintaining the appropriate Consumer authorization in accordance with OEB rules. See transaction flows STR5 through STR7.

Proposed that there is no requirement for meter Information transaction or a meter maintenance transaction. Flow The Vendor sends a Historical Usage Request, a Meter Information Request, or a Historical Payment Request to the Distributor. The Distributor can reject any of the transactions, indicating the reason for the rejection, only if validation fails.. or there is no data for the Consumer. A request should not be rejected if there is no data for the consumer; rather. Aan accept should be returned and populated with 0zero data. If a request is accepted, the Distributor responds with a Historical Usage Accept Transactionn, a Meter Maintenance Transaction, or a Historical Payment Accept Transaction, depending on the files requested.

General Description of Data The request transaction includes account identification information and indicates whether historical usage, meter information, or payment history is requested and how many periods. A request can be for up to 24 months of consumption or payment history.

Response The Distributor responds by:  Sending a Historical Payment Accept if payment history was requested. A response for payment history includes payment due dates and payment receipt dates, the number of times the consumer was delinquent or in arrears, maximum credit exposure, and number of times the consumer’s security arrangements were revised.  Sending a Meter Maintenance Transaction if meter information was requested.

 Sending a Historical Usage Accept if historical usage was requested. We need to capture the information needed in this transaction.  Sending a Reject Response (STR) if no data is available for the Consumer or if validation failed.   If no data is available, an Accept is returned and populated with zero values as defined later in this document. Rules If meter information has not been requested prior to the historical usage request, it must be submitted as a separate STR at the same time.

TRANSACTION FLOW STR5 Consumer Information Request

In this scenario, the Consumer authorizes Vendor to request Consumer Information.

2. Consumer Information Request

VENDOR DISTRIBUTOR 3. Consumer Information Accept

1. Authorization for Distributor to provide historical Consumer information to Vendor.

CONSUMER

Flow: 1. Consumer provides authorization for the Vendor to request information. 2. Vendor submits a Consumer Information Request 3. Distributor sends the Consumer Information Accept within 14 days.

Rules: None

Exceptions: None

TRANSACTION FLOW STR6 Historical Usage

In this scenario, the vendor requests consumption and billing data.

1. Historical Usage Request

2. Historical Usage Accept VENDOR DISTRIBUTOR

3. Status Advice-NED

Flow: 1. Vendor submits a request for Consumer’s Historical Usage. 2. Distributor sends Historical Usage Accept within 7 calendar days. 3. Distributor sends Status Advice providing a date when the information will be available.

Rules: None

Exceptions: None

Need to add another flow for the reject process flow

TRANSACTION FLOW STR7 Historical Payment

In this scenario, the vendor requests payment profile data.

1. Historical Payment Request

2. Historical Payment Accept VENDOR DISTRIBUTOR

3. Status Advice-NED

Flow: 1. Vendor submits a request for Consumer’s Historical Payment Profile. 2. Distributor sends Historical Payment Accept. 3. Distributor sends Status Advice providing a date when the information will be available.

Rules: None

Exceptions: None

5.1.3 STR - Meter Change Request Is this necessary?

Definition /purpose/flow The Meter Change Request is used by the Vendor to request a new type of meter to be installed by the Distributor for an end-use Consumer.

Data The Vendor must include the meter number for the existing meter that will be removed and the meter type for the replacement. In the Meter Change Accept transaction, the Distributor will send the meter cycle and billing cycle if these are different due to the meter change. The Vendor will request a change meter installation date and the Distributor will either confirm this date or provide a new projected installation date in the accept transaction.

Response The Distributor will respond to the Meter Change Request with an accept or a reject transaction. The Meter Change Request may be rejected using a Reject Reason such as "ValidationFailed" or "InvalidMeterType".

Rules The Distributor will bill the Vendor for the new meter installation. If a Consumer on competitive service calls the Distributor with a change meter request, the Distributor will advise the Consumer to call the Vendor, since a change in the meter type may not be consistent with the Consumer’s current contract with the Vendor. The Distributor will make available a list of the meter options provided to the Vendors.

5.1.4 STR - Change Consumer Information

Definition/Purpose The Change Consumer Information STR is a transaction for communicating information changes between the parties who service the Consumer. Any consumer information to be defined later field within the Enrol Accept file may be changed.

*The types of information that need to be included in the transaction need to be detailed. Customer information such as address, name, account number etc . It was suggested that Delivery Point and price point type info could be exchanged through a CBO transaction

Flow This request may be sent by either the Distributor to the Vendor or by the Vendor to the Distributor. There is no requirement for the Distributor to match their information to the Vendor. The Distributor is the “owner” of the Consumer information. See Transaction Flow STR8 and STR9. The flow for the Change Billing Option transaction will work similarly to that for the Enrolment Request as illustrated in the flow STR-1.

Data Description The sender will provide the transaction purpose, the field changed, the reason for the change, the changed information, and the effective date.

Response The party receiving the Change Consumer Information request will respond within fourteen 7 calendar days upon receipt by sending a Change Consumer Information Accept. If the Change Consumer Information Request is sent to the Vendor, the Vendor will echo back the same fields sent by the Distributor. If the Change Consumer Information Request is sent to the Distributor, the Distributor will Accept the request. The Accept response from the distributor is intended to be an acknowledgment of receipt of the request transaction. If the distributor amends its records recordswhere appropriate, it will send the current data to the Vendor with a new Change Consumer Information request and respond back to the Retailer with the new current data.

When the Distributor sends a CCI request to the Vendor, the Vendor responds with an Accept transaction. T he Vendor updates the changes to it s system . If the Vendor has any questions regarding the updated information, the vendor contacts the distributor manually.

Once a Distributor has sent an Enrol Accept transaction and the Consumer is in a pending enrol state with a Vendor, the Change Consumer information STR must be used to communicate updated information between the Vendor and the Distributor even though gas flow from the Retailer Vendor has not begun. The Distributor ultimately owns the information of record regarding the Consumer. In the case of a contest, the distributor sends the CCI to both Vendors.

Rate and/or billing option changes made between bill cycles will only occur on the “next scheduled read”. Changes to the Bill Cycle must be sent through the Change Consumer Information STR. Changes to billing options need to be sent through the Change Billing Option Transaction. The Vendor is obligated to inform the Distributor of a change in the billing option, and the Distributor will make the appropriate changes as of the effective date sent in the Change Billing Option Accept. There is no separate transaction to cancel a Change Billing Option. When a Change Billing Option transaction is issued and at a later date the request needs to be cancelled, the trading party that originally issued the transaction should issue a new Change Billing Option transaction and explicitly change it back. Whatever state is last set when the bill is issued to the Consumer will be the billing option for that month.

If a trading partnerdistributor sends an old account number, the account number switch date must also be included. An old account number must be presented in the EBT transactions for at least two billing periods and must be accepted by the distributor for at least 2 billing periods.

CCI Requests have a 'requested effective date'. This effective date is to be built with the date the transaction was constructed. The party will send the transaction on the date it becomes effective.[parties to confirm]. .

Note re “Fullname” Format:

To move the implementations to a common format, the preferred order of names within the ‘Fullname’ element is defined. To accommodate legacy systems, this is only the recommended order of names.

The preferred convention is:

“OR“<company name><ltd. or inc., etc.>” vER Version 0.15 May 24July 20, 2005 Page 40 GDAR EBT STANDARDS DOCUMENTExamplesMrs. Anne K Jones Mr. Bill Mark Smith III ABC Company Ltd.NEED New Section for Change billing Option TransactionThe flow for the Change Billing Option transaction will work similarly to that for the Enrolment Request as illustrated in the flow STR-1.Rate and/or billing option changes made between bill cycles will only occur on the “next scheduled read”. Changes to the Bill Cycle must be sent through the Change Consumer Information STR. Changes to billing options need to be sent through the Change Billing Option Transaction. The Vendor is obligated to inform the Distributor of a change in the billing option, and the Distributor will make the appropriate changes as of the effective date sent in the Change Billing Option Accept. There is no separate transaction to cancel a Change Billing Option. When a Change Billing Option transaction is issued and at a later date the request needs to be cancelled, the trading party that originally issued the transaction should issue a new Change Billing Option transaction and explicitly change it back. Whatever state is last set when the bill is issued to the Consumer will be the billing option for that month.Need to determine how credits or adjustments can be put on the bill . vER Version 0.15 May 24July 20, 2005 Page 41 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR8 Change Consumer Information – Consumer to VendorIn this scenario, the Consumer provides the Vendor with changed information.2. Change Consumer Information RequestVENDOR 3. Change Consumer Information Accept DISTRIBUTOR1. Changed Consumer Information given to the Vendor.CONSUMERFlow: 1. Consumer provides Vendor with changed information. 2. Vendor submits a Change Consumer Information Request. 3. Distributor sends the Change Consumer Information Accept within 7 calendar14 days.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 42 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR9 Change Consumer Information – Consumer to DistributorIn this scenario, the Consumer provides the Distributor with changed information.2. Change Consumer Information RequestVENDOR DISTRIBUTOR 3. Change Consumer Information Accept1. Changed Consumer Information given to the Distributor.CONSUMERFlow: 1. Consumer provides Distributor with changed information. 2. Distributor submits a Change Consumer Information Request to the Vendor. 3. Vendor sends the Change Consumer Information Accept within 7 calendar14 days.Rules: NoneExceptions: NoneRoles and Responsibilities: NoneA request is rejected if validation fails or data is not valid. vER Version 0.15 May 24July 20, 2005 Page 43 GDAR EBT STANDARDS DOCUMENT5.1.5 STR – Change Consumer LocationNOTE: THIS SECTION HAS NOT BEEN REVISED OR ALTERED – IT IS EXACTLY AS WRITTEN IN THE ELECTRICITY EBT STANDARDS. NEED TO DISCUSS WHETHER IT IS APPRORIATE. Definition/purpose A Consumer may move to new premises within or outside of the Distributor’s service territory (NOTE: see definition below). The Change Consumer Location STR is used only when the move is within the Distributor’s service territory. It provides the opportunity for a Consumer to retain their enrolment with their existing RetailerVendor at their new premises. When the Consumer moves outside the Distributor’s territory, a STR-Drop is used. See Transaction Flows STR-20, 21, 22, and 23 for moves inside the Distributor’s territory and see Transaction Flows STR- 24 and 25 for moves outside the Distributor’s territory. The rules for each of these scenarios are described at the end of this section.Service Territory: For purposes of this section, all references to Distributor’s service territory are limited to the territory defined by a specific delivery point. This definition may be revised at a future date.Flow Typically, a Consumer will contact the Distributor when they are moving. If the Consumer contacts the Retailer Vendor instead, the Retailer Vendor may refer the Consumer to the Distributor, or send a Status Advice to the Distributor notifying of Consumer intent to move. In any event, the Distributor and the Consumer will make contact to arrange details of the move.If a Consumer notifies the Distributor that they are moving inside the Distributor’s territory but no longer wishes to remain with the same RetailerVendor, the Distributor may indicate this to the Retailer Vendor using one of the following flows:  Issue a Change Consumer Location transaction followed by a Drop Request transaction; or  Bypass issuing the Change Consumer Location transaction and only issue a Drop Request transaction. From the Retailer’s Vendor’s view, this optional flow appears to be identical to the flow for a move that is out of the Distributor’s territory.In both cases, tThe forwarding address of the Drop Request tTransaction must be filled in if known. (NOTE: Kitchener has stated it is unable to provide a new address due to MFIPPA legislation.)If the Consumer notifies the RetailerVendor of the move, the RetailerVendor will send a Status Advice to the Distributor indicating the Consumer’s move followed by a Drop request. vER Version 0.15 May 24July 20, 2005 Page 44 GDAR EBT STANDARDS DOCUMENTIf the Distributor has issued a Change Consumer Location tTransaction in error, this transaction can be cancelled by sending the RetailerVendor a Status Advice - Terminate Transfer Request.General Description of Data The information sent in the Change Consumer Location Request includes the new Distributor account number if applicable, the new billing and service addresses, and the associated dates for the old and new service locations as provided by the Consumer.If a trading partner either the Distributor or the Vendor sends an old account number, the account number switch date must also be included. An old account number must be presented in the EBT transactions for at least two billing periods.Response If the Retailer Vendor replies with a Change Consumer Location Accept, or does not reply before the move, the Distributor will maintain Consumer enrolment with the Retailer Vendor at the new location, provided the rules listed below are met. For an In Territory move, once the Change Consumer Location Request has been sent, the Distributor shall not send a Drop Request on the move out location (i.e., there is an implied drop at the old location).If the move out date in the Change Consumer Location Request is future dated, the Retailer Vendor may reply with a Change Consumer Location Reject with a reason of “RetailerRejectsConsumerVendorRejectsConsumer”. This Reject Reason will instruct the Distributor not to enrol the Consumer at Location 2 to the Retailer Vendor of record. If the move out date in the Change Consumer Location Request is backdated then the Retailer Vendor must accept the Change Consumer Location Request and issue a Drop Request at Location 2 if they choose.Rules The Change Consumer Location Request allows a Consumer to stay enrolled with the same Retailer Vendor at the new address and must occur when the following conditions are met:  Any Consumer is eligible for an in-territory move.  The account billing method is split billing or bill ready option (not rate ready).  A Distributor shall issue a CCL to a Retailer Vendor when it is has been determined that the same Consumer is moving from one location vER Version 0.15 May 24July 20, 2005 Page 45 GDAR EBT STANDARDS DOCUMENT to another location within the service territory. If the Consumer does not provide a move in date then a Drop Request will be issued.NOTE: need to review this above condition in light of Union’s current practice to determine if current practice is preferable, and whether or not all distributors can effect Union’s current practice. If Move In information is provided after a Drop Request has been sent and prior to the final meter read being dispatched to the field, then the Drop will be terminated and a CCL will be issued to the Retailer.  If the Consumer provides the required details with respect to an in- territory move and is still currently registered in Location 1, then the Distributor will issue a CCL transaction to the RetailerVendor. Notification of the move may occur before or after the physical move.NOTE: Enbridge has stated it is currently unable to contractual information such as a new date, retroactively. This would require a major system modification (for which Enbridge will try to provide the impact. Gap and overlap scenarios will be allowed.  There are no restrictions with respect to the number, type of meters, and/or service points at the new service location.  In-territory moves and rules surrounding contest periods are dependent on when the move occurs and when the Consumer contacts the Distributor (refer to the Scenarios section below).The Distributor will not delay the move if there is not sufficient lead time for notification and response from the RetailerVendor. For out of territory moves, the Distributor shall initiate a Drop Request to the RetailerVendor for service at the old location, including the new service address if available. If the RetailerVendor intends to maintain Consumer enrolment at the new location, the RetailerVendor must initiate an Enrol STR with the new Distributor at the new service location.In-Territory Move ScenariosScenarios and In-Territory Move Working Principles 1. At the time a Consumer contacts a Distributor, the information relayed to the Distributor will determine the appropriate transaction to notify a Retailer(s)Vendor of Consumer’s relocation. If criteria/rules are met and the relocation is within the Distributor’s service territory, then a CCL transaction will be initiated. vER Version 0.15 May 24July 20, 2005 Page 46 GDAR EBT STANDARDS DOCUMENTScenarios and In-Territory Move Working Principles If criteria are met and the relocation is outside the Distributor’s service territory, then a Drop Request tTransaction will be initiated.2. The CCL tTransaction is intended to ensure that the Consumer/RetailerVendor relationship is maintained throughout an in- territory move. The CCL tTransaction is sent by the Distributor to the Retailer(s)Vendor to inform of a Consumer move within the Distributor’s service territory and will provide all required data as per the schemas.3. Definition of a Consumer re-location within a Distributor’s service territory, which will result in a CCL transaction, includes:  move out and move in on the same dates (simple);  move out date less than move in date (gap); and  move out date greater than move in date (overlap).4. For a gap or overlap scenario, if the Consumer provided all relevant data at the time of notification to the Distributor (dates and move in location), then a CCL tTransaction will be initiated by the Distributor regardless of the difference (gap or overlap) in the dates provided. 5. Regardless of when a Consumer notifies the Distributor of relocation, (prior to, on or after the move out date) a CCL transaction will be initiated if the criteria are met as outlined in the “Rules” section above.6. If the Consumer notifies the Distributor of a relocation cancel after a CCL has been issued, then a SA-TTX will be issued and sent to the Retailer(s)Vendor.7. If the Consumer notifies the Distributor of a date change after a CCL has been issued, then a SA-NED will be issued and sent to the RetailerVendor.If the date change is for the Move Out date then the value will be “New Effective Date – Move Out” If the date change is for the Move In date then the value will be “New Effective Date – Move In” If there is a date change for both the Move In and Move Out dates then two SA transactions will be sent, one for the Move In date and one for the Move Out date.8. If information in the CCL tTransaction requires modification (as a result of Consumer contact and or processing errors) prior to the Move In date, then a SA-TTX will be issued to cancel the original CCL and a new CCL will be issued reflecting the change. vER Version 0.15 May 24July 20, 2005 Page 47 GDAR EBT STANDARDS DOCUMENTScenarios and In-Territory Move Working PrinciplesIf the information requires modification after the Move In date then the Distributor will generate a Change Consumer Information (CCI) tTransaction.9. All Usage tTransactions (and the required values for the UsagePurpose data field) associated with the CCL process will follow the business rules as outlined in Section 5.2.1?? Usage Transaction.10. The Retailer Vendor must have the ability in a gap and or overlap scenario, if applicable, to generate separate IBRs in response to Usage transactions received in which the account number is the same for both the old and new premises locations.11. The Distributor has the responsibility to maintain all internal processes (meter reads, billing, etc) throughout the CCL process with or without a response from the RetailerVendor.12. The Retailer Vendor will respond to the CCL tTransaction with a Change Consumer Location Accept tTransaction if they wish to continue the relationship with the Consumer. If no response is sent, the default is that the Vendor will continue the relationship with the Consumer.13. If a Retailer Vendor does not wish to continue the Consumer relationship, then a Change Consumer Location Reject will be issued with a Reject Reason of “RetailerRejectsConsumerVendorRejectsConsumer”. This specific Reject Reason will be equivalent to a Drop Request for the Distributor. No further response is required from the Distributor to the RetailerVendor.14. In the scenario in which a CCL has been initiated by the Distributor to Retailer Vendor A and then RetailerVendor B submits an Enrol Request for the Consumer, the Distributor will respond to the Enrol Request as follows:  Issue an Enrolment Reject to RetailerVendor B with a Reject Reason of “PendingMove”.This Reject Reason provides a method for RetailerVendor B to re-submit the Enrolment Request after contacting the Consumer. Note: The Enrolment Reject of “PendingMove” will also apply for a Consumer on SSSsystem gas.15. If during the period in which a Consumer’s account is in a Contest and the Consumer notifies the Distributor of an in-territory move prior to the end of vER Version 0.15 May 24July 20, 2005 Page 48 GDAR EBT STANDARDS DOCUMENTScenarios and In-Territory Move Working Principles the Contest period, the Distributor may cancel the Enrol transaction (thus the Contest) by sending SA-TTX transactions to both RetailersVendors.  The “SA-TTX PendingMove” transaction will be sent to both RetailersVendors.In the event that a RetailerVendor rejects the SA-TTXPendingMove transaction it must be noted that the Contest period will be terminated. However, the responsibility to correct and resend the SA- TTXPendingMove transaction remains with the Distributor.16. If during the period in which the Contest is over but prior to power gas flow with the winning RetailerVendor (SA-CPO tTransactions having been sent to both RetailersVendors) the Consumer notifies the Distributor of a move, then the following will apply:  The Distributor shall inform at least the winning RetailerVendor of the in-territory move and may inform the second RetailerVendor using a Change Consumer Location transaction if they choose.  If the move date is prior to the current switch date, the Distributor will amend the switch date to match the move date and send SA-NEDs to both RetailersVendors.  If the move date is after the current switch date, then the Distributor may amend the date and send SA-NEDs to both RetailersVendors if they choose.Scenario: Move within Distributor ’s Service Territory If the Consumer is moving within the service territory, then the Distributor service representative will initiate action that will result in continuation of service with the same Retailer Vendor at the new address (referred to as a “seamless move”), unless the Consumer indicates that they wish to return to Standard Supply Servicesystem gas. The Distributor will notify the RetailerVendor by means of a Change Consumer Location Request that the seamless move will take place. vER Version 0.15 May 24July 20, 2005 Page 49 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR-2020: Change Consumer Location STRIn this scenario, the Consumer notifies the Distributor about the change of location within the Distributor’s service territory. The Retailer Vendor accepts the change of location.12. Change Consumer Location 1. Change Consumer Location Request Request 23. Change Consumer Location 2. Change Consumer Location RETAILER DISTRIBUTOR Accept HUB Accept VENDOR 3. Status Advice (NED), if 34. Status Advice (NED), if needed needed 1.Request Change LocationCONSUMER***Application Advice Accept or Reject must be sent for all Status Advice transactions to indicate an accept or reject of the transaction.the SA has been processed.Flow: 1. Consumer contacts Distributor with a Change Location (Move) request inside the current Distributor’s territory. 2. Distributor sends a Change Consumer Location Request to the Retailer Vendor after verifying change location information with Consumer. 3. Retailer Vendor accepts the Change Consumer Location Request by sending the Distributor a Change Consumer Location Accept. (Note: The default is that the Distributor will assume the Vendor accepts the CCL Request Transaction. If the Vendor does not wish to retain the relationship with the Consumer the Vendor MUST send a Drop Request.) 4. The Distributor sends a Status Advice (New Effective Date) if either the Move In or Move Out date changes from the original dates sent in the Change Consumer Location Request.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 50 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR-21: Change Consumer Location STRIn this scenario, the Consumer notifies the Retailer Vendor about the change of location within the Distributor’s service territory. The Retailer Vendor accepts the change of location.12. Status Advice 1. Status Advice RETAILER (CCL) 23. Change(CCL) Consumer Location HUB 2. Change Consumer Location VENDOR RequestRequest DISTRIBUTOR 34. Change Consumer Location 3. Change Consumer Location Accept Accept 4. Status Advice (NED), if 45. Status Advice (NED), if needed needed1.Request Change LocationCONSUMER***Application Advice Accept or Reject must be sent for all Status Advice transactions to indicate an accept or reject of the transaction.the SA has been processed.Flow: 1. Consumer contacts Retailer Vendor with a Change Location (Move) request inside the current Distributor’s service territory. 2. RetailerVendor sends a Status Advice (Change Consumer Location) to the Distributor. 3. Distributor sends a Change Consumer Location Request to RetailerVendor after verifying change location information with Consumer. 4. RetailerVendor accepts the Change Consumer Location Request by sending the Distributor a Change Consumer Location Accept. (Note: The default is that the Distributor will assume the Vendor accepts the CCL Request Transaction. If the Vendor does not wish to retain the relationship with the Consumer the Vendor MUST send a Drop Request.) 5. The Distributor sends a Status Advice (New Effective Date) if either the Move In or Move Out date changes.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 51 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR-22: Change Consumer Location STRIn this scenario, the Consumer notifies the Retailer of the change of location within the Distributor’s territory and the Retailer rejects the change of location.1. Status Advice 1. Status Advice RETAILER (CCL) (CCL) 2. Change Consumer Location HUB 2. Change Consumer Location Request Request DISTRIBUTOR 3. Change Consumer Location 3. Change Consumer Location Reject Reject 4. Drop Request, 4. Drop Request, possible possible 5. Drop Accept, 5. Drop Accept, possible possibleReques t Change Locatio n CONSUMER***Application Advice Accept or Reject must be sent for all Status Advice transactions to indicate an accept or reject of the transaction.Flow: Consumer contacts Retailer with a Change Location (Move) request inside the current Distributor’s territory. 1. Retailer sends a Status Advice (Change Consumer Location) to the Distributor. 2. Distributor sends a Change Consumer Location Request to Retailer after verifying change location information with Consumer. 3. Retailer sends a Change Consumer Location Reject. The Consumer will drop to SSS upon the Move Out date. 4. Retailer sends a Drop Request if they choose to drop the Consumer before the Move Out date. The Retailer will pay for the meter reading to drop before the move. 5. Distributor sends a Drop Accept to the Retailer.Rules: NoneExceptions: NoneRoles and Responsibilities: Retailer may ask the Consumer to contact the Distributor directly regarding a move. vER Version 0.15 May 24July 20, 2005 Page 52 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR-23: Change Consumer Location STRIn this scenario, the Consumer notifies the Distributor about the change of location within the Distributor’s service territory. The RetailerVendor accepts the change of location. The Consumer then contacts the RetailerVendor to cancel the move.56. Status Advice (TXReq) outside EBT2. Change Consumer Location 2. Change Consumer Location Request 3.Request Change Consumer Location RETAILER DISTRIBUTOR 3. Change Consumer Location HUB Accept VENDOR 5. StatusAccept Advice (CCL) 5. Status Advice (CCL) 6. Status Advice (TXReq)1. Request Change Location4. Request Cancellation of CONSUMER Move***Application Advice Accept or Reject must be sent for all Status Advice transactions to indicate an accept or reject of the transaction.the SA has been processed.Flow: 1. Consumer contacts Distributor with a Change Location (Move) request inside the current Distributor’s service territory. 2. Distributor sends a Change Consumer Location Request to the RetailerVendor after verifying change location information with Consumer. 3. Retailer Vendor accepts the Change Consumer Location Request by sending the Distributor a Change Consumer Location Accept. (Note: The default is that the Distributor will assume the Vendor accepts the CCL Request Transaction. If the Vendor does not wish to retain the relationship with the Consumer the Vendor MUST send a Drop Request.) 4. Consumer contacts Retailer Vendor to cancel the move. 5. Retailer Vendor sends a Status Advice (Change Consumer Location) tocontacts the Distributor outside the EBT System to indicate that the consumer is not moving. 6. The Distributor sends a Status Advice (Terminate Transfer Request), after verifying the cancellation with Consumer, to inform the Retailer Vendor that the move is cancelled.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 53 GDAR EBT STANDARDS DOCUMENTScenario: Move Outside Distributor ’s Service Territory If the Consumer is moving outside the Distributor’s service territory, the Distributor will arrange to finalize the Consumer’s account, and notify the Retailer Vendor by means of a Drop Request.When the Consumer is moving outside the Distributor’s territory and there is a pending RetailerVendor, a Drop is not valid since the Retailer Vendor is only pending. Under these conditions a Status Advice -- Terminate Transferaction Request (SA-TTx) is to be used with a Reason stating that this is due to a move outside the territory. The Retailer Vendor will acknowledge acceptance or rejection of the Status Advice using an Application Advice transaction.TRANSACTION FLOW STR-24: Change Consumer Location STRIn this scenario, the Consumer notifies the Retailer Vendor of the change of location outside the Distributor’s service territory.12. Status Advice 1. Status Advice RETAILER (CCL) (CCL) DISTRIBUTOR HUB VENDOR 2. Drop 23. Drop Request Request 34. Drop 3. Drop Accept Accept 4. Status Advice (NED), if 45. Status Advice (NED), if needed needed1. Request for ChangeCONSUMER***Application Advice Accept or Reject must be sent for all Status Advice transactions to indicate the an accept or reject of the transaction.SA has been processed.Flow: 1. Consumer contacts the Retailer Vendor with a request to change location (move) outside of the current Distributor’s service territory. 2. Retailer Vendor sends a Status Advice (Change Consumer Change Location) to the Distributor notifying them of the Consumer’s request to move. 3. Distributor sends a Drop Request to the Retailer Vendor after verifying change location information with the Consumer. 4. Retailer Vendor sends the Distributor a Drop Accept. The Drop Request in this case (Consumer moving outside of the service territory) can only be rejected if the validation fails. The Retailer Vendor must accept the drop and enrol the Consumer with the new Distributor in the new service territory. vER Version 0.15 May 24July 20, 2005 Page 54 GDAR EBT STANDARDS DOCUMENT5. A Status Advice with a new Drop effective date will be sent if the move/drop date changes from the original effective date sent in the Drop Request.Rules: NoneExceptions: NoneRoles and Responsibilities: NoneTRANSACTION FLOW STR-25: Change Consumer Location STRIn this scenario, the Consumer notifies the Distributor of the change of location outside the Distributor’s service territory.1. Drop 12. Drop Request Request RETAILER 23. Drop HUB 2. Drop VENDOR Accept Accept DISTRIBUTOR 3. Status Advice (NED), if 34. Status Advice (NED), if needed needed1. Request for ChangeCONSUMER***Application Advice Accept or Reject must be sent for all Status Advice transactions to indicate an accept or reject of the transaction.the SA has been processed.Flow: 1. Consumer contacts the Distributor with a request to change location (move) outside of the current Distributor’s service territory. 2. Distributor sends a Drop Request to the RetailerVendor after verifying change location information with the Consumer. 3. Retailer Vendor sends the Distributor a Drop Accept. The Drop Request in this case (Consumer moving outside of the service territory) can only be rejected if the validation fails. The RetailerVendor must accept the drop and enrol the Consumer with the new Distributor in the new service territory. 4. A Status Advice with a new Drop effective date will be sent if the move/drop date changes from the original effective date sent in the Drop Request.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 55 GDAR EBT STANDARDS DOCUMENTNOTE: The following section has not been reviewed at this time – will check to see if applicable/necessary after reviewing invoice transactions. vER Version 0.15 May 24July 20, 2005 Page 56 GDAR EBT STANDARDS DOCUMENTNotification of a Move after the Move Has Taken PlaceIn the case where the Consumer moves out and notifies the Distributor after the fact, the Distributor should treat the situation as if a mistake was made in the Usage transaction. Even though any consumption and demand amounts reported may have been correct, the Usage transaction itself was not correct in that it should have been sent as a final Usage. The Distributor should cancel and re-issue the Usage. The Distributor and Retailer should then further recover in a manner identical to that occurring when a misread of a meter takes place.Note that if the utility discovers the error after the final bill is due, the onus is on the Retailer to follow-up with the Consumer. The Distributor keeps the Retailer whole for the amount billed up to the date of the final bill. After the final bill due date, the Distributor will not collect for the Retailer.Distributor Consolidated Bill Ready account where the Consumer moves out without notifying any party:Step 1) Consumer-A moves out. Step 2) Consumer-B moves in. Step 3) The Consumer’s meter is read.Note that Application Advice transactions have not been shown to simplify the flows.EBT Transactions:(U1) Usage transaction sent from Distributor to Retailer for Consumer(I1) Invoice - Bill ready transaction from Retailer to Distributor for Consumer Consumer’s account charged  BILL ISSUED to Consumer by Distributor  The Transaction Cross Reference Number is set to the Transaction Reference Number from (U1).(I2) Invoice - Settlement transaction sent from Distributor to RetailerStep 4) The Distributor discovers that Consumer-A is no longer responsible for the meterEBT Transactions:(UC) Usage Cancel transaction from Distributor to Retailer vER Version 0.15 May 24July 20, 2005 Page 57 GDAR EBT STANDARDS DOCUMENT The Original Transaction Reference Number is set to the Transaction Reference Number from (U1).(U2) Usage Final transaction sent from Distributor to Retailer for the correct period (The move out date is determined at the discretion of the Distributor)(IC) Invoice - Bill Ready Cancel transaction sent from Retailer to Distributor. Consumer’s charge in (I1) is reversed.  The Original Transaction Reference Number is set to the Transaction Reference Number from (I1).  The Transaction Cross Reference Number is set to the Transaction Reference Number from (U1).(I3) Invoice - Bill ready transaction sent from Retailer to Distributor (Note: This can occur immediately or on next bill cycle) The Consumer’s account charged for new Distributor non-commodity amounts  If the move out was discovered before the due date of the previous bill, the Consumer’s account is also charged for the new commodity amounts from the Retailer. (If the move out was discovered after the due date of the previous bill, the Retailer is responsible for collecting these amounts.)  Retailer account is credited with corrected amount  BILL ISSUED to Consumer by Distributor. This Consumer bill will sum all adjustments, payments and new charges for a net invoice amount.  The Transaction Cross Reference Number is set to the Transaction Reference Number from (U2).(I4) Invoice - Settlement transaction sent from Distributor to Retailer for corrected amount. vER Version 0.15 May 24July 20, 2005 Page 58 GDAR EBT STANDARDS DOCUMENT5.1.6 STR – Drop Definition The drop transaction is the opposite of an enrol transaction. It is used to terminate a flowing billable enrolment between a Consumer and a Vendor of record. at the next scheduled meter read or at a specified meter read.Flow Can occur as a result of a Consumer request to the Vendor or the Distributor to drop to System Gas; as a result of a request by the Vendor to drop the Consumer; or as a result of a move by the Consumer outside of the Distributor’s territory. The drop flows for these scenarios are STR10, STR11, and STR12 respectively.Rules Scenario: Consumer Drops Vendor If the Consumer wishes to enrol with a new Vendor, the Consumer must first cancel the contract with the existing Vendor. If a The Consumer may inform the Distributor or the current Vendor of record. If the Consumer informs the Vendor directly, the Vendor will send a Drop Request transaction to the Distributor. If the Consumer informs the Distributor directly to drop a Vendor, competitive service will be terminated on the date of the Consumer’s next scheduled meter read (billing cycle) unless the Consumer requests a specified read. The Distributor will automatically move the Consumer to system gas. based on an actual read and bill the Consumer the appropriate fee (if specified read). See Transaction Flow STR11 for details.SScenario: Vendor Drops Consumer The Vendor, after complying with any applicable notification period, notifies the Distributor to discontinue competitive service for a Consumer. The general rule is that the termination will be made to coincide with the Consumer’s normal cycle meter-read date. If the Vendor desires to drop the Consumer off-cycle, the Distributor will send a Confirm Drop transaction to the Vendor, indicating the predicted off-cycle drop date. The Distributor will automatically move the Consumer to system gas based on an actual read, and bill the Vendor the appropriate fee. If applicable, Tthe Vendor will be sent final Consumer Usage Consumption or Consumer Billing and UsageConsumption Information tTransaction at the time of billing to allow the completion of the Consumer accounting process. After that date, the Consumer will automatically receive system gas until they enrol with a new Vendor. See flow STR for details.Scenario: Consumer Notifies Distributor of a Move After Usage Has Been Sent In the scenario in which: vER Version 0.15 May 24July 20, 2005 Page 59 GDAR EBT STANDARDS DOCUMENT a Distributor is notified by the Consumer of a move out after a Usage transaction has been sent to the Vendor; and  both the service period and consumption provided in that Usage transaction are correct; then the Distributor shall issue a Drop transaction to the Vendor with a Read Indicator of “LastActualRead” or “SpecifiedRead”. The Specified Meter Read Date field will be populated with the service period end date of the previously received Usage.Under the conditions above, it is not necessary to cancel the previously sent Usage and reissue with a UsagePurpose value of “AccountFinal”, however the cancel re-bill process remains an option for a Distributor.Effective Date of a Drop RequestWWhen a Drop Request is issued, it is the responsibility of the respondent issuing party to provideinclude the Effective Date of the Drop within the Drop Accept Transaction. The Distributor is in control of the billing / meter reading cycle, so when the Distributor is the issuer of the Drop Request with an identified Read Indicator of “NextScheduledRead”, Vendos are required to provide their “best guess” for the Effective Date. The Effective Date provided by the Vendor in the Drop Accept Transaction can be based on: a meter reading schedule provided by the Distributor; estimation of the next possible read date from previously read periods; or other methods where not enough or inconsistent data is present.Where the date of the drop will be changed, this will be done through an SA-NED Transaction. NOTE: The following section will be discussed after the section on invoice transactions to see if it needs to be included here. As the Retailer is not in control of any changes to the billing / meter reading cycle and may not have received from the Consumer the same information as the Distributor has received regarding actual final read date requirements, this information needs to be provided by the Distributor.The SpecifiedMeterReadDate is now ??mandatory?? – NEED TO DISCUSS. The date provided depends on the ReadIndicator used and which Market Participant is initiating the request, as follows:ReadIndicator SpecifiedMeterReadDate SpecifiedMeterReadDate Distributor Provided to Vendor provided to Vendor Distributor NextScheduledRead Expected Effective Date of A properly formatted date or OnCycle the drop - Vendor will use value - Distributor will ignore SpecifiedRead Special meter read date, Special meter read date, indicating the effective date indicating the effective date of the drop - Vendor will use of the drop - Distributor will vER Version 0.15 May 24July 20, 2005 Page 60 GDAR EBT STANDARDS DOCUMENT use LastActualRead Last meter read date, Last meter read date, indicating the effective date indicating the effective date of the drop - Vendor will use of the drop - Distributor will use vER Version 0.15 May 24July 20, 2005 Page 61 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR10 Vendor DropIn this scenario, the Vendor initiates the Drop of the Consumer.1. Drop RequestVENDOR DISTRIBUTOR 2. Drop AcceptFlow: 1. Vendor submits a Drop Request. 2. Distributor sends the Drop Accept. 3. Status Advice-New Effective Date (if applicable)Rules: Vendor may request a specified meter read date for the drop. If the Distributor can arrange for this the Vendor may be charged.Exceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 62 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR11 Consumer DropIn this scenario, the Consumer initiates the return to System Gas.2. Drop Request3. Drop VENDOR DISTRIBUTOR Accept4. SA-NED (if needed)1. Request return to System GasCONSUMERFlow: 1. Consumer requests return to System Gas 2. Distributor submits a Drop Request. The Drop Read Effective date must be scheduled for at least 30 days after the Request. Need to review need for this timeline. 3. Vendor sends the Drop Accept. The only valid Reject Reason is for invalid validation terms. 4. Distributor sends a Status Advice-New Effective Date (SA-NED) if the effective date changes from the original date.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 63 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR12 Enrol/SwitchIn this scenario, Vendor A has been dropped by the Consumer (STR 10), and enrols with Vendor B.1. Enrol Request2. Enrol VENDOR DISTRIBUTOR Accept BVENDOR AFlow: 1. Vendor B submits an Enrol Request. 2. Distributor send the Enrol Accept within 14 days. 3. Consumer enrols with Vendor B.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 64 GDAR EBT STANDARDS DOCUMENT5.2 Meter Data TransactionsThis section has been deleted – need to discuss 5.2 Consumption TransactionsThe Consumption Transaction (CT) is the XML document used by the Distributor to communicate consumption data to the Vendor. There are two CT schemas (XML formats) defined for use in the Ontario EBT Gas Market. While each CT contains general Consumer account and summary level information, i.e. account number, address information, etc; each CT contains specific information for its particular function. The two CTs are:  Consumption  Historical ConsumptionThe following sections describe each CT in detail.5.2.1 Consumption TransactionDefinition The Consumption Transaction conveys information from the Distributor to the Vendor concerning the consumption of gas. Typically the Consumption Transaction is used to deliver billable consumption to the Vendor.Consumption is measured in cubic meters (m 3), such that each cubic meter is the volume of gas when such gas is at a temperature of 15 degrees Celsius and an absolute pressure of 101.325 kilopascals. It is important that Vendors be able to reconcile the amount of gas consumed by customers as provided in the Consumption Transactions to the amount of gas delivered to serve those same customers. To this end, over the term (normally annually) of a given pool/GTA/DP/DPA/etc (“Pool”), the amount of gas consumed by customer of that Pool, as provided in Consumption Transactions, must in aggregate equal the amount of gas required by the Distributor to be delivered by the Vendor to the Pool (subject to reasonable rounding and unit of measure conversion precision).Flow The Distributor generates the Consumption Transaction and sends it to the Vendor. The Vendor responds with an Application Advice Accept or Reject (AA) indicating acceptance or rejection, at the application level, of the transaction. See flow CT-1 for details.The Consumption Transaction “purpose of transaction” option allows the Distributor to:  Send original transactions  Send cancel transactions. vER Version 0.15 May 24July 20, 2005 Page 65 GDAR EBT STANDARDS DOCUMENT Send replacement transactions if one or more data errors were discovered after transmission  Send a final transaction.General Description of the Data The Distributor issues a Consumption Transaction according to its meter read schedule. If data is missing from a Consumption Transaction, or if there are gaps in the dates of a Consumption Transaction, then the Distributor is showing that the meter was installed at the service site but locked, installed at the service site but not connected, or variations on this.The consumption data will include consumption on the dates included in the Service Period. To clarify the interpretation of the XML Names “Service Period” “Begin Date/Time” and “End Date/Time”, the consumption data is included for the dates stated in both of these fields. For example, if the “Begin Date/Time” is 200506010000 (June 1, 2005 at the beginning of the day), and the “End Date/Time” is 200506142359 (June 14, 2005 at the end of the day), then the consumption data includes data for the period of June 1 to June 14 inclusive. Regardless of how the time is designated, the consumption data is included for the complete date that is stated in both the Begin Date/Time and End Date Time.Response The Vendor responds to a Consumption Transaction with an Application Advice Accept or Reject (AA) indicating acceptance or rejection of the data.Rules The following rules apply to the Consumption Transaction: The Consumption Transaction must be sent to the Vendor no later than four business days after the consumption is calculated.  The AA response to the Consumption Transaction must be returned back to the Distributor no later than two business days after the Vendor receives the Consumption Transaction.  At the end of the billing period, the Distributor will send a message containing the full set of consumption information with the BillRequired field set to ‘yes’. The BillRequired field being set to ‘yes’ indicates to the Vendor that an invoice transaction should be created for this data.  Only one valid Consumption Transaction for billing purposes (BillRequired field set to ‘yes’) may be provided for a given account number. For further clarity, the Distributor will provide only one consumption value for each service period for each Consumer account to be billed. Consumption Transactions are not cumulative. A Distributor may not send multiple consumptions for the same service period in any account. vER Version 0.15 May 24July 20, 2005 Page 66 GDAR EBT STANDARDS DOCUMENT For accounts containing multiple meters, all consumption information for all meters to be billed under that account number is to be captured in one single Consumption Transaction. Stated differently, for a given billing period, a Distributor shall send a single Consumption Transaction for each account number which will contain all consumption information to be billed under that account number with the BillRequired field set to ‘yes’. (Note: There are relatively few situations where this will apply.)  A Distributor may send multiple service periods for a given account within a single Consumption Transaction. However, the service periods must be distinct, providing for the respective consumption value for each service period, and the service periods must be presented in the transaction in chronological order. Service periods for a given account must be contiguous, and the service must not be repeated within the transaction.  A negative consumption value is not allowed on a billable Consumption Transaction (BillRequired field set to ‘yes’). Where a Distributor has over- estimated previous consumption value(s) for a Consumer account resulting in a negative value, the Distributor is required to cancel and rebill the service periods, adjusting the previous estimated consumption and current consumption accordingly such that the Consumer’s consumption is reflected as accurately as possible.The following rules apply to the Consumption Cancel transaction: In the event that the consumption has been sent to the Vendor and not rejected, and must be revised or replaced, a Consumption Cancel Transaction must be transmitted to the Vendor, followed by a revised Consumption Transaction for that same service period. It is not valid to send the replacement Consumption Transaction without first cancelling the original Consumption Transaction being replaced.  A Consumption Cancel Transaction cancels the original Consumption Transaction in its entirety. It cannot partially cancel the original consumption information. The effect is as if the original Consumption Transaction was never sent.  Under Distributor Consolidated Billing, if a Consumption transaction is sent to the Vendor and the Invoice Bill Ready is sent to the Distributor after the Distributor has created a Consumption Cancel transaction (sent or not yet sent), both the Consumption and Consumption Cancel Transactions must be accepted by the Vendor. For clarity, ‘sent’ is to be interpreted from the sender’s perspective; the transaction may or may not have been received by the recipient.The following rules apply to the Application Advice Reject of a Consumption Transaction: In the event that an Application Advice Reject is sent by the Vendor in response to a Consumption Transaction and it is determined between the vER Version 0.15 May 24July 20, 2005 Page 67 GDAR EBT STANDARDS DOCUMENT parties that the reject is valid (the Consumption Transaction is not valid due to a Distributor cause), the Distributor will issue a new valid Consumption Transaction to the Vendor.The following documents the methods available for rebilling periods: In the case where Consumption Transactions were cancelled for the following periods:  Service Period 1: 2003/06/15 to 2003/07/15;  Service Period 2: 2003/07/15 to 2003/08/15; and  Service Period 3: 2003/08/15 to 2003/09/15; the methods documented in the table below are available to be used for the cancel rebill of consumption.  Each of the methods outlined in the table below captures the treatment of the Consumption Transaction processing for the rebilled consumption.  In each case, it is assumed that the original Consumption Transactions have been cancelled.Method Consumption TransactionConsumptio Consumption Consumption n Tx1 Tx2 Tx3 1 Service Service Service Period 1 Period 2 Period 3 2003/06/15 2003/07/15 to 2003/08/15 to to 2003/08/15 2003/09/15 2003/07/15Consumption Tx1Service 2 Service Service Period 1 Period 2 Period 3 2003/06/15 2003/07/15 to 2003/08/15 to to 2003/08/15 2003/09/15 2003/07/15Consumption Tx1 3 Service Period 1 2003/06/15 to 2003/09/15Consumption Consumption Consumption Tx1 Tx2 Tx3 4 Service Period 1 2003/06/15 to 2003/09/15 vER Version 0.15 May 24July 20, 2005 Page 68 GDAR EBT STANDARDS DOCUMENTNOTE: Table to be considered with a preferred outcome of selecting one method only.Definitions for the ConsumptionPurpose Data Field:ConsumptionPurpose - communicates the disposition of the Consumer account for the given Consumption Transaction as it pertains to the Vendor. Definitions of the associated values are as follows:NOTE: Value names may be revised due to potential conflicts with current terminology.Original – identifies to the current Vendor that the given Consumption Transaction may be the first Consumption being received for a Consumer account or for a service period that is not the final service period.AccountFinal – identifies to the current Vendor that the Consumption Transaction is the final billable Consumption to be received by the Vendor for a Consumer’s account as it pertains to that Vendor. The value of “AccountFinal” is to be populated in the last Consumption Transaction sent to the current Vendor as identified in the conditional logic scenarios – specifically:  For when a Consumer switches to an alternative Vendor  For when a Consumer switches to system gas  For when a Consumer moves “out of territory”  For when a Consumer moves “in territory”, the Consumption with the “AccountFinal” value will be issued for the move out premises location NOTE: At this point, in territory and out of territory refers only to a defined delivery areaCancel – identifies to the current Vendor that a previously received Consumption Transaction as referenced within the transaction by the “Original Transaction Reference Number” is now in a cancelled disposition. Use of the ConsumptionPurpose Field:The EBT Standards identify that the responsibility to communicate the disposition of a Consumer’s account for the current Vendor is with the Distributor. The guiding principle for use of the values in the ConsumptionPurpose data field is to communicate the disposition/status of a Consumer’s account as it pertains vER Version 0.15 May 24July 20, 2005 Page 69 GDAR EBT STANDARDS DOCUMENT specifically to the Vendor regardless of the end status in the Distributor’s CIS. The following logic scenarios shall be applied to communicate the disposition of an account as it pertains to the Vendor’s service:1. If the Consumption Transaction represents either the first or ongoing consumption for a Consumer account prior to a final consumption then the value in the ConsumptionPurpose data field would be “Original”. 2. If the Consumption Transaction represents both the first and final consumption for a Consumer account then the value in the ConsumptionPurpose data field will be “AccountFinal”. 3. If the Consumption Transaction represents the final consumption to be received by the Vendor for a Consumer account then the value in the ConsumptionPurpose data field will be “AccountFinal”. Under the conditions above, it is not necessary to cancel the previously sent Consumption and reissue with a ConsumptionPurpose value of “AccountFinal”; however, the cancel re-bill process remains an option for a Distributor.Account Number and Premises:The term “Account” refers to the Distributor Consumer Account Number and the premises to which it is attached.Where a Distributor does not change the Consumer’s account number in the event of a move within territory, then:  The final Consumption to be sent to the Vendor for the old premises (move-out location) must have the ConsumptionPurpose field populated with the value ‘AccountFinal’; and  The first and further Consumption transactions sent to the Vendor for the new premises (move in location) must have the ConsumptionPurpose field populated with the value ‘Original’. vER Version 0.15 May 24July 20, 2005 Page 70 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW CT-1: ConsumptionIn this scenario, the Distributor performs the meter read according to the scheduled meter read date for the account.VENDOR 1. DISTRIBUTOR Consumption2. AAFlow: 1. Distributor reads the metered service and sends Consumption to the Vendor within four business days following the calculation of the consumption. 2. Vendor returns an AA response within two business days. vER Version 0.15 May 24July 20, 2005 Page 71 GDAR EBT STANDARDS DOCUMENTNOTE: Darcy will review the following section to see if it or any part of it may be applicable. 5.2.2 Meter Maintenance TransactionDefinition The Meter Maintenance Transaction conveys general, descriptive information pertaining to the services for a Consumer’s account, e.g. for metered services, meter type, meter manufacturer name, meter serial number, etc.; for unmetered services, service type (e.g. streetlights), number of units, service identification number. This transaction can be issued as a response to a Meter Information STR from a Vendor, or initiated by the Distributor to notify the Vendor of a change to a service’s information, e.g. completion of a meter service request, meter re-seal. The Vendor should request the meter information, in conjunction with a request for historical Consumption, if it hasn’t been previously requested. The Meter Maintenance Transaction does not contain Consumption. See the sections on Meter Information STRs and Historical Consumption Accept Transaction for details. Typically, the Meter Maintenance Transaction would be issued as part of service startup, or when a meter has been swapped out. From time to time a meter at a Consumer location may be replaced by a new one at the request of the Consumer, or re-sealed as the result of the standard inspection process required every six years for all meters. The former scenario can be a response to a STR from the Vendor or initiated by the Distributor. Only the Distributor initiates the re-seal scenario. The Meter Maintenance Transaction conveys the information on the new or re- sealed meter to the Vendor. Requests for changes to an unmetered account are to be handled offline using a process outside the EBT system.Flow The Distributor generates the Meter Maintenance Transaction and sends it to the Vendor. The Vendor responds with an Application Advice (AA) indicating acceptance or rejection, at the application level, of the transaction. See flows MDT-2, MDT-3, MDT-4 and MDT-5 for details.The Meter Maintenance Transaction “purpose of transaction” option allows the Distributor to:  Send original transactions  Send replacement transactions if one or more data errors were discovered after transmission  Send duplicate transactionsGeneral Description of the Data The Meter Maintenance Transaction conveys general, descriptive information pertaining to the services for a Consumer’s account, e.g. for metered services, meter type, meter vER Version 0.15 May 24July 20, 2005 Page 72 GDAR EBT STANDARDS DOCUMENT manufacturer name, meter serial number, etc.; for unmetered services, service type (e.g. streetlights), number of units, service identification number.Response The Vendor responds to a Meter Maintenance Transaction with an Application Advice (AA) indicating acceptance or rejection of the data.Rules The following rules apply to the Meter Maintenance Transaction: Requests for changes to unmetered services on an account are not handled by the EBT. Such changes are handled offline in a process to be agreed to by both the Distributor and the Vendor.  The Meter Maintenance Transaction must be sent to the Vendor before noon of the fourth business day.  The AA response to the Meter Maintenance Transaction must be returned back to the Distributor no later than two business days after the Vendor receives the Meter Maintenance Transaction.Typical Application Codes Typical application codes that can be returned in the AA are: All OK.  Metered Service is not found – the Vendor has no record of the metered service that was sent in the Meter Maintenance Transaction.  Unmetered Service is not found – the Vendor has no record of the unmetered service that was sent in the Meter Maintenance Transaction.  Metered Service is already enrolled – the Vendor already has enrolled the metered service that was sent in the Meter Maintenance Transaction. The Vendor is expecting a Consumption Transaction, but not a Meter Maintenance Transaction.  Unmetered Service is already enrolled – the Vendor has no record of the unmetered service that was sent in the Meter Maintenance Transaction. The Vendor is expecting a Consumption Transaction, but not a Meter Maintenance Transaction.The following diagrams show the basic transaction flows for the Ontario EBT Standard for Meter Maintenance transactions. Meter Maintenance transactions are used to convey detailed information on meters and unmetered services. This information is delivered as a result of a change in the meter, power beginning to flow after a new enrolment or if current information was requested by a Vendor.There are four basic scenarios that take place using meter maintenance. These scenarios are: A meter change request from the Vendor (a meter being exchanged);  A meter change notification from the Distributor (a meter being added, removed, exchanged, turned on, turned off or its configuration being changed); vER Version 0.15 May 24July 20, 2005 Page 73 GDAR EBT STANDARDS DOCUMENT A meter information request from the Vendor; and  An initial read notification from the Distributor.TRANSACTION FLOW MTD-2 Meter Change Request from the VendorIn this scenario, a Vendor requests the Distributor to change the Consumer’s meter. Most likely it is a request to upgrade the Consumer’s meter to an interval meter as part of signing up the Consumer. The request to change the meter is sent out and a response is returned indicating when the change will take place. When the meter has been changed, the Distributor will send the Vendor the maintenance data on the new meter.The Vendor can only request a change of meter using this process. New meters being added and old meters being removed are not permitted using this process.Meter Request STR Meter Request STR MeterChangeOut=yes MeterChangeOut=yesVENDOR Meter Response – HUB Meter Response – DISTRIBUTOR Accept or Reject Accept or RejectMeter Maintenance Meter MaintenanceAA AAFlow: 1. The Vendor requests to change the meter type (Vendor cannot add or remove meters) 2. The Distributor sends the meter response, either accept or reject, when the Distributor has scheduled the meter change 3. The Distributor sends the Meter Maintenance with the new meter info (e.g. serial number and model) once the meter has been changed 4. The Vendor responds with an Application Advice vER Version 0.15 May 24July 20, 2005 Page 74 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW MTD-3 Meter Change Notification from the DistributorIn this scenario, the Distributor changes a Consumer’s meter. An example of a reason for this change could be that the Distributor upgraded the meter to an interval meter because the Consumer is now using a lot more electricity than was previously used.This scenario is also valid for cases where a meter has been added or removed by the Distributor.Meter Maintenance Meter Maintenance VENDOR HUB DISTRIBUTORAA AAFlow: 1. The Distributor sends the Meter Maintenance with the new meter info (e.g. serial number and model) once the meter has been changed, a new meter was added or a meter was removed 2. The Vendor responds with an Application Advice vER Version 0.15 May 24July 20, 2005 Page 75 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW MTD-4 Meter Information Request from the VendorIn this scenario, a Vendor requests the Distributor to provide Meter Maintenance data. Typically this is used in the case where a Vendor is in the process of obtaining detailed information about a potential Consumer.Meter Request STR Meter Request STR MeterChangeOut=no MeterChangeOut=noVENDOR Meter Response – HUB Meter Response – DISTRIBUTOR Accept or Reject Accept or RejectMeter Maintenance Meter MaintenanceAA AAFlow: 1. The Vendor requests information about the meter 2. The Distributor sends the meter response, either accept or reject, to indicate that the request was received 3. The Distributor sends the Meter Maintenance with the information for the meter (e.g. serial number and model) once the meter information has been collected 4. The Vendor responds with an Application Advice vER Version 0.15 May 24July 20, 2005 Page 76 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW MTD-5 Initial Read Notification from the DistributorIn this scenario the Distributor is providing the new Vendor with an indication that the Consumer has been switched to the new Vendor as a result of an enrolment. Enrolment STR Enrolment STR VENDOR HUB DISTRIBUTOR Enrolment Accept Enrolment Accept Meter Maintenance Meter MaintenanceAA AAFlow: 1. The Vendor requests enrolment of the Consumer (see the Enrol Request STR ) 2. The Distributor sends the Enrol Accept to indicate that the Consumer will be switched to the Vendor 3. The Distributor sends the Meter Maintenance with the information for the meter (e.g. serial number and model) or unmetered service once the initial meter read has been completed for the Vendor, and the Vendor is now supplying power to the Consumer 4. The Vendor responds with an Application Advice vER Version 0.15 May 24July 20, 2005 Page 77 GDAR EBT STANDARDS DOCUMENT5.2.2 Historical Consumption TransactionDefinition The Historical Consumption Transaction responds to the Vendor’s request for historical consumption. A response must be sent from the Distributor to the Vendor within seven calendar days of receipt of the request.The Historical Consumption Transaction conveys the history of a Consumer’s gas consumption on the account. The Distributor issues this transaction in response to a Historical Consumption Request Transaction by the Vendor. The Vendor may request up to a maximum of the previous 24 months of consumption data; however, if the account does not have data for the whole period requested, the available data, including void fields where data is not available, is delivered. Because the amount of data can be quite large with this transaction, the value for the number of requested months field in the originating transaction defaults to twelve.If the consumption data will not be available within the seven calendar day timeframe, the Distributor will respond to the Vendor by sending an Historical Consumption Reject Transaction. The responsibility will then be on the Vendor to follow up with the Distributor outside the EBT system. Once the Vendor contacts the Distributor, the Vendor will submit a new Historical Consumption Request Transaction within the timeframe agreed upon with the Distributor.Flow The Vendor requests the historical consumption for an account by sending a Historical Consumption Request Transaction to the Distributor. If the originating request is accepted, the Distributor responds to the Vendor by sending an Historical Consumption Transaction within seven calendar days. If the originating request is rejected, the vendor will follow up with the Distributor outside the EBT system.General Description of the Data The Historical Consumption Accept Transaction contains all requested and available consumption on an account. If there is no consumption during any part of the period, a value of “zero” should be returned. If data is not available a “null” field should be returned. Rules The following rule applies to the Historical Consumption Transaction: The Historical Consumption Transaction must be sent back to the Vendor within seven calendar days after the Distributor receives the Historical Consumption Request Transaction. vER Version 0.15 May 24July 20, 2005 Page 78 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW CT-2: Historical Consumption TransactionIn this scenario, the historical consumption is available.VENDOR 1. Historical Consumption Request DISTRIBUTOR Transaction2. Monthly Historical Consumption Data ReturnedFlow: 1. Vendor submits a Historical Consumption Request Transaction. 2. Distributor gathers data and returns the Historical Consumption data to the Vendor within seven calendar days of receipt of the request.TRANSACTION FLOW CT-3: Historical Consumption Reject TransactionIn this scenario, the historical consumption is not available within the seven calendar day timeframe.VENDOR DISTRIBUTOR1. Historical Consumption Request2. Historical Consumption RejectVendor contacts Distributor outside EBT Flow: 1. Vendor submits a Historical Consumption Request Transaction. 2. Distributor cannot provide historical consumption data within the seven calendar day timeframe, so sends a Historical Consumption Reject within seven calendar days of receipt of the request. 3. Vendor will follow up with Distributor outside the EBT system, and submit a new Historical Consumption Request Transaction within an agreed upon timeframe. vER Version 0.15 May 24July 20, 2005 Page 79 GDAR EBT STANDARDS DOCUMENT5.3 Invoice Transactions Five Four types of Consumer Billing Options are possible: Split Billing  Distributor Consolidated Billing – Bill Rate Ready  Distributor Consolidated Billing – RateBill Ready  Retailer Vendor Consolidated Billing –- Bill Ready  Retailer Consolidated Billing – Rate Ready  Split BillingThe Consumer and Vendor will determine the selection of a billing option. The Vendor will then notify the Distributor of the desired billing option. The Distributor Consolidated “bill ready” option shall be offered as a mandatory service (NOTE: Not in GDAR – need to discuss) upon request by a Vendor. A Distributor may provide “rate ready” billing as an optional service and, upon request from a Vendor, shall make a good faith effort to provide “rate ready” billing.The Distributor shall have the ability to accommodate a rate-ready and a bill-ready form of Distributor Consolidated Billing.For purposes of bill processing, the gas distributor shall be responsible for the accuracy and completeness of the information which the gas distributor provides, and the gas vendor shall be responsible for the accuracy and completeness of the information which the gas vendor provides, according to the terms of the Service Agreement.NOTE: Hold following section for now There are two types of Trading Partner Invoices:  Settlement Invoice  Total  Detail  Market Participant Invoice5.3.1 Invoice – Distributor Rate ReadyDefinition/purpose The Invoice Rate Ready (IRR) Transaction is used when the Distributor calculates the Vendor charges based on the rates provided by the Vendor. The Consumer receives one bill from the Distributor with both the Distributor and Vendor charges on the bill.Flow Vendors provide unit rates in advance for vendor managed, commodity-based elements as applicable. Charge categories include: A. Managed at Price Point Level  Commodity  Transportation vER Version 0.15 May 24July 20, 2005 Page 80 GDAR EBT STANDARDS DOCUMENT Storage  Vendor Administration Fee B. Managed at Account Level  Vendor AdjustmentThe following rules apply. A. Managed at Price Point Level  Unit rates have no expiry date, and must be replaced by a changed rate.  Changed rates must not be negative (may be zero or positive).  Rate changes are made effective the 1 st of a calendar month and consumption is prorated on the 1 st of the month in the event of a rate change.  Unit rates can be changed up to 3 calendar days, but no more than 120 calendar days, prior to the effective date of the rate change. (Note Grandfathering Clause)B. Managed at Account Level  Amount will be a lump-sum value which can be either positive or negative.  The value will be associated with an account and a price point. An account can only be associated with 1 price point in effect at any point in time.  The description associated with the adjustment will be selected from a pre-defined table.  The adjustment must be received by the Distributor a minimum of 15 calendar days prior to the 1 st of the month to ensure the adjustment is included on the bill for that month.  There may be no more than 1 pending adjustment at any time (i.e., if an adjustment is pending, a subsequent adjustment will be rejected).  The adjustment may only be submitted by the Vendor of record on the effective date.Response The Distributor calculates the Vendor charges based on the applicable unit rate(s) provided by the Vendor and the consumption determined by the Distributor. Vendor charges are applied directly to the consumer’s invoice as part of the Distributor’s billing process.The Distributor sends consumption and billing data in a single IRR Transaction to the Vendor within 5 calendar days of the consumer’s actual billing date.The Vendor sends an Application Advice Accept or Reject within 7 calendar days to acknowledge receipt of the consumption and billing data in the correct format, but no other response questioning the data is permitted. vER Version 0.15 May 24July 20, 2005 Page 81 GDAR EBT STANDARDS DOCUMENTFor consumption errors, the Distributor initiates an Invoice Cancel transaction to the Vendor. The Distributor issues the corrected invoice to the consumer and sends the corrected IRR Transaction based on revised consumption and billing data to the Vendor (see Cancel/Rebill Procedures at the end of the Invoices section for more details). See flow STR?? for details.Rules There is only one Consumer to one IRR Transaction.An IRR cannot be sent without including the corresponding consumption.Billing of Taxes The Distributor shall calculate, collect and remit to Canada Customs & Revenue Agency GST on the Vendor charges and on Distributor charges. TRANSACTION FLOW STR?? Distributor Rate Ready Billing1. UsageUnit 2. Invoice Rate Change VENDOR DISTRIBUTOR 3. Cancel Usage 65. Corrected InvoiceIRR CONSUMER 4. Send Bill***Application Advice Accept or Reject must be sent on all transactions to indicate the transaction has been processed.Flow: 1. Unit rate for each applicable Vendor charge category is provided to the Distributor in advance. 2. (Optional – Vendor sends rate change to the Distributor up to 3 calendar days but no more than 120 calendar days in advance of the effective date, which effective date shall be the 1 st of a month.) 3. (Optional – Vendor sends adjustment value 15 calendar days prior to the 1 st of the month.) 4. Distributor calculates Vendor charges based on unit rate(s) provided by Vendor and consumption determined by Distributor, and outside EBT, sends the Consumer a consolidated bill with both Vendor and Distributor charges on it, by regular mail. 5. Distributor sends IRR Transaction, including consumption and billing data, to the Vendor within 5 calendar days of sending consolidated bill to the Consumer. vER Version 0.15 May 24July 20, 2005 Page 82 GDAR EBT STANDARDS DOCUMENTRules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 83 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STRXX Distributor Rate Ready Billing Option (Vendor Correction)1. Utility bills consumerVENDOR DISTRIBUTORConsumer2. Invoice Rate Ready(3a) 3a. Consumer Calls (3a) 3. Invoice Vendor Adjust4.Utility bills Consumer5. Invoice Rate ***Application Advice Accept or Reject must be sent on all above transactions to indicate the transaction has been processed.Flow: 1. Utility bills the consumer. 2. After the Utility bills the consumer an Invoice Rate Ready (IRR) transaction is sent from the Utility to the Vendor. Transaction includes at a minimum the Consumption amount, Rate, and if applicable the Transportation, and Storage charges associated with the consumer’s bill. ** It may also include the Vendor Adjustment (VA) and Vendor Admin Fee (VAF) if applicable. 3. If Vendor realizes the information in the IRR is incorrect or has been notified by the consumer the invoice is incorrect (3a), the Vendor corrects the charges and returns an Invoice Vendor Adjust (IVA) to the Utility. 4. The utility bills the consumer on the following billing cycle with the additional line item including the description of the Vendors Adjustments 5. The Utility after billing the consumer sends an IRR transaction to the Vendor with the following Vendor Adjustments included in the transaction. 6. The sequence repeats until the consumer’s bill has been corrected.Rules: 1. The amount in the IVA amount may be a positive or a negative number. 2. The IVA must be provided back to the Utility 15 days before the first of the month so the IVA will be presented on the bill to the consumer for the following month. 3. If the Vendor does not make this 15-day timeline the IVA will be rejected with an Application Advice Reject (AAR). This indicates to the Vendor the correction (IVA) will have to re submitted again to be placed on the following consumers bill. 4. Only one-dollar amount and one line will be allowed in the IVA. vER Version 0.15 May 24July 20, 2005 Page 84 GDAR EBT STANDARDS DOCUMENT5. A description of this amount will accompany the amount in the IVA transaction and the description must be from an agreed upon enumerated selection list. 6. The Vendor must be the Vendor of record as of the effective date of the transaction, i.e. the first of the month following submission. Exceptions: NoneRoles and Responsibilities: 1. Vendors are only allow to provide adjustments that relate to the charges or line items on the customers bill, e.g. Commodity, and if applicable transportation and storage charges. vER Version 0.15 May 24July 20, 2005 Page 85 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STRXX Distributor Rate Ready Billing Option (Vendor Correction with Vendor cancel)1. Utility bills consumerVENDOR DISTRIBUTORConsumer2. Invoice Rate Ready3a. Consumer Calls4.3. Vendor Invoice cancels Vendor Adjust5.Utility bills Consumer 6. Invoice Rate ***Application Advice Accept or Reject must be sent on all transactions to indicate the transaction has been processed.Flow: 1. Utility bills the consumer. 2. After the Utility bills the consumer an Invoice Rate Ready (IRR) transaction is sent from the Utility to the Vendor. Transaction includes at a minimum the Consumption amount, Rate, and if applicable the Transportation, and Storage charges associated with the consumer’s bill. ** It may also include the Vendor Adjustment (VA) and Vendor Admin Fee (VAF) if applicable. 3. If Vendor realizes the information in the IRR is incorrect or has been notified by the consumer the invoice is incorrect (3a), the Vendor corrects the charges and returns an Invoice Vendor Adjust (IVA) to the Utility. 4. If the event that an adjustment line is initially accepted by the Utility but the Vendor wishes to cancel the IVA, the Vendor would send a Status Advice Terminate Transfer request point pointing to the IVA transaction. (This notifies the Utility to cancel the IVA). 5. The utility bills the consumer on the following billing cycle without the additional line item. 6. The Utility after billing the consumer sends an IRR transaction to the Vendor without the IVA included in the transaction. (This informs the Vendor the IVA did not make it on the consumers bill) 7. The sequence repeats until the consumer’s bill has been corrected.Rules:1. The amount in the IVA amount may be a positive or a negative number. vER Version 0.15 May 24July 20, 2005 Page 86 GDAR EBT STANDARDS DOCUMENT2. The IVA must be provided back to the Utility 15 days before the first of the month so the IVA will be presented on the bill to the consumer for the following month. The 15 day requirement is also true for the SA. (4) 3. If the Vendor does not make this 15-day timeline the IVA will be rejected with an Application Advice Reject (AAR). This indicates to the Vendor the correction (IVA) will have to re submitted again to be placed on the following consumers bill. 4. Only one-dollar amount and one line will be allowed in the IVA. 5. A description of this amount will accompany the amount in the IVA transaction and the description must be from an agreed upon enumerated selection list. 6. The Vendor must be the Vendor of record as of the effective date of the transaction, i.e. the first of the month following submission. Roles and Responsibilities: 1. Vendors are only allowed to provide adjustments that relate to the charges or line items on the customers bill, e.g. Commodity, and if applicable transportation and storage charges. vER Version 0.15 May 24July 20, 2005 Page 87 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STRXX Distributor Rate Ready Billing Option (Vendor Correction with Utility cancel)1. Utility bills consumerVENDOR DISTRIBUTORConsumer2. Invoice Rate Ready3a. Consumer Calls3. Invoice Vendor Adjust4. Utility cancels 5.Utility bills Consumer 6. Invoice Rate ***Application Advice Accept or Reject must be sent on all transactions to indicate the transaction has been processed.Flow: 1. Utility bills the consumer. 2. After the Utility bills the consumer an Invoice Rate Ready (IRR) transaction is sent from the Utility to the Vendor. Transaction includes at a minimum the Consumption amount, Rate, and if applicable the Transportation, and Storage charges associated with the consumer’s bill. ** It may also include the Vendor Adjustment (VA) and Vendor Admin Fee (VAF) if applicable. 3. If Vendor realizes the information in the IRR is incorrect or has been notified by the consumer the invoice is incorrect (3a), the Vendor corrects the charges and returns an Invoice Vendor Adjust (IVA) to the Utility. 4. If the event that an adjustment line is initially accepted but subsequently cancelled when posted to the account because of a change to the status of the account, (Consumer moves). A Status Advice Terminate Transfer request will be sent from the Utility to the Vendor pointing to the IVA transaction. (This notifies the Vendor the IVA did not make it on the consumers bill) 5. The utility bills the consumer on the following billing cycle without the additional line item. 6. The Utility after billing the consumer sends an IRR transaction to the Vendor without the IVA included in the transaction. (This informs the Vendor the IVA did not make it on the consumers bill) 7. The sequence repeats until the consumer’s bill has been corrected.Rules: 1. The amount in the IVA amount may be a positive or a negative number. vER Version 0.15 May 24July 20, 2005 Page 88 GDAR EBT STANDARDS DOCUMENT2. The IVA must be provided back to the Utility 15 days before the first of the month so the IVA will be presented on the bill to the consumer for the following month. 3. If the Vendor does not make this 15-day timeline the IVA will be rejected with an Application Advice Reject (AAR). This indicates to the Vendor the correction (IVA) will have to re submitted again to be placed on the following consumers bill. 4. Only one-dollar amount and one line will be allowed in the IVA. 5. A description of this amount will accompany the amount in the IVA transaction and the description must be from an agreed upon enumerated selection list. 6. The Vendor must be the Vendor of record as of the effective date of the transaction, i.e. the first of the month following submission. Roles and Responsibilities: 1. Vendors are only allow to provide adjustments that relate to the charges or line items on the customers bill, e.g. Commodity, and if applicable transportation and storage charges. vER Version 0.15 May 24July 20, 2005 Page 89 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STRXX Distributor Rate Ready Billing Option (Utility Correction)1. Utility bills consumer 2. Invoice Rate Ready VENDOR DISTRIBUTOR5.Utility bills Consumer 6. Invoice Rate ReadyConsumer3. Consumer CallsFlow: 1. Utility bills the consumer. 2. After the Utility bills the consumer an Invoice Rate Ready (IRR) transaction is sent from the Utility to the Vendor. Transaction includes at a minimum the Consumption amount, Rate, and if applicable the Transportation, and Storage charges associated with the consumer’s bill. ** It will also include the Vendor Adjustment (VA) and Vendor Admin Fee (VAF) if applicable 3. Consumer calls and/or Utility decide that the bill has to be canceled. 4. Utility make correction to the bill. 5. Utility bills consumer. 6. Utility sends an IRR transaction. vER Version 0.15 May 24July 20, 2005 Page 90 GDAR EBT STANDARDS DOCUMENTGrandfathering Clause for Distributors’ Acceptance of Rate ChangesNotwithstanding the EBT Standards requirements for rate changes to be accepted by the Distributor if sent by the Vendor at least 3 calendar days prior to the effective date of the rate change, Distributors who were, at September 6, 2005, only able to guarantee rate changes sent at least 30 calendar days prior to the effective date will be grandfathered. Despite this Grandfathering Clause, Distributors to whom the Grandfathering Clause applies will make best efforts to accommodate rate changes which are sent by the Vendor at least 3 calendar days prior to the effective date.Note: July 13/14 Review stopped at this point. It was noted that bad debt and acceptable tolerances for both rate changes and adjustments need to be discussed.NOTE: Preceding 4 transaction flows prepared by Darcy in response to action item noted in July 20/21 meeting added for review July 27/28.5.3.1 Invoice – Split BillingDefinition/purpose The Distributor and Vendor both bill the Consumer for their portion of the Invoice. The Consumer receives two Invoices in this billing scenario. This billing option is the simplest in terms of coordination, process steps and data exchange requirements between the Vendor and Distributor. The Split Bill requires the exchange of Consumer meter data from the Distributor to the Vendor via a Consumer Usage STR.Flow The Distributor sends the Usage STR to the Vendor no later than noon of the 4th business day from the scheduled meter read date. The Consumer will receive two bill statements, one from the Vendor for their portion of the commodity being provided to the Consumer and one from the Distributor for their delivery service being provided to the Consumer. See flow STR13 for details.Billing of Taxes The billing parties will be responsible for the collection and remittance of all taxes to the government. See Section 5.3.6 Invoice – Settlement under “Billing of Taxes” for further information.TRANSACTION FLOW STR13 Split Billing Option1. Usage 2. Cancel VENDOR Usage 3. Corrected DISTRIBUTOR Usage vER Version 0.15 May 24July 20, 2005 Page 91 GDAR EBT STANDARDS DOCUMENTVendor Invoice for CONSUMER Distributor Invoice for Consumer Consumer***Application Advice Accept or Reject must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 1. Distributor sends Usage STR to Vendor within X days of the scheduled meter read date. The Consumer will receive two bill statements – one from the Vendor for the gas commodity and one from the Distributor for delivery charges. 2. (Conditional) Distributor sends cancelled Usage to Vendor. 3. (Conditional – Only if Step 2 occurs) Distributor sends corrected Usage to Vendor.5.3.2 Invoice – Distributor Bill ReadyDefinition/purpose This bill option is the a mandatory bill option. that the OEB has chosen. The Vendor sends this transaction to the Distributor. This transaction is used when the Vendor calculates its own charges and the charges print on a Distributor’s consolidated bill. The Distributor then sends the complete bill to the Consumer.Flow The UsageConsumption Transaction is sent from the Distributor to the Vendor no later thanno later than noon of the 4th business days from after the consumption is calculatedthe scheduled meter read date. The Vendor then calculates the commodity charges based on the contract with the Consumer. The Vendor submits to the Distributor the line item charge(s) to be put on the Consumer’s bill no later than two business days after the Usage tConsumption Transaction has been sentreceived. See flow STR14 STR?? for details.The Distributor should not begin to execute the Consumer billing after receipt of the IBR until the minimum IBR Bill window interval (currently a minimum of two business days) has elapsed such that any IBR Cancel transaction or subsequent IBR transaction may be processed if also received within the interval. For clarity, if a Vendor wishes to correct an IBR issued to the Distributor, it will send an IBR Cancel transaction and a new IBR. Any of these transactions that are sent within the response interval (from transmission of the original UsageConsumption) should be accepted and processed.Under Distributor Consolidated Billing, should the Distributor not be capable of issuing the new Usage tConsumption Transaction and receiving the IBR in time for the current Consumer billing for that UsageConsumption service period, the Distributor shall Cancel/Rebill the Consumer immediately thereafter. The Distributor shall issue a new valid Usage tConsumption Transaction such that the vER Version 0.15 May 24July 20, 2005 Page 92 GDAR EBT STANDARDS DOCUMENTVendor may provide the IBR response and the Consumer will be re-billed to include the commodity charge. This will occur prior to the next expected billing unless mutually agreed to by both parties.In the event of a cancel/rebill scenario: The Distributor initiates a UsageConsumption Cancel tTransaction to the Vendor.  The Vendor cancelssends the originalan Invoice Bill Ready Cancel (IBR- Cancel) to the Distributor.  The Distributor sends the corrected UsageConsumption Transaction to the Vendor.  The Vendor issues the corrected IBR to the Distributor (see Cancel/Rebill at the end of the Invoices section for more details). Response Once the Distributor receives the Invoice Bill Ready (IBR) tTransaction, it sends an Application Advice Accept or Reject back to the Vendor stating that the data was either accepted or rejectedto indicate whether the transaction has been processed. This Application Advice Accept or Reject is sent no later than two business days after the receipt of the IBR transaction from the Vendor.An Application Advice Accept in response to an IBR tTransaction indicates that the invoice amount will be presented on the Consumer billing when the Consumer is billed for all charges for the respective Usage consumption, and the IBR amount will be settled with the Vendor. If an IBR is rejected for any reason (Application Advice Reject), it will not be included in the Consumer billing nor will it be included in the settlementremittance with the Vendor.Only one Application Advice tTransaction can be sent in response to any request (i.e. UsageConsumption or IBR) received. Where the sending party has made an error in the type of Application Advice transmitted (e.g. an AA Accept was transmitted instead of an AA Reject), the offending party must notify the receiving party of the error immediately outside the EBT System, and both Trading Partners must work out a fix as mutually agreed.In Distributor Consolidated Bill Ready situations, if a Distributor receives an Invoice Bill Ready transaction from the Vendor after the Distributor has already sent the bill to the Consumer; the Distributor will reject the transaction. The Vendor, receiving such a reject, will have to combine the line items for the current late month together with the line items for the next month into the Invoice Bill Ready tTransaction for the next month.Rules Only Commodity Charges: vER Version 0.15 May 24July 20, 2005 Page 93 GDAR EBT STANDARDS DOCUMENTThe Vendor can only send commodity charges, as applicable, with one item per line. There is only one Consumer to one Invoice transaction. Negative charges (credits) are allowed on an IBR.One IBR per UsageConsumption: Where the Vendor chooses to send an IBR, only one IBR tTransaction may be sent in reference to one Usage tConsumption Transaction (BillRequired field set to ‘yes’). Multiple IBR transactions may not be sent in reference to a single Usage tConsumption Transaction, nor may an IBR be sent without a corresponding UsageConsumption. Similarly, only one valid IBR Cancel tTransaction may be sent for any given UsageConsumption Cancel tTransaction.An IBR Cancel must be issued if the Usage tConsumption Transaction has been cancelled (with a UsageConsumption Cancel tTransaction) and an IBR has already been transmitted by the Vendor in response to the Usage tConsumption Transaction that is being cancelled. Additionally, under DCB, if the IBR has not yet been sent by the Vendor when the UsageConsumption Cancel is received, then neither the IBR referencing the original UsageConsumption, nor the IBR Cancel is required to be sent by the Vendor, but if received by the Distributor, they must be processed. Further, in the case where a Usage tConsumption Transaction is received by the Vendor, the IBR tTransaction sent by the Vendor is rejected and the Vendor subsequently receives a UsageConsumption Cancel tTransaction prior to re-issuing a new IBR tTransaction, the Vendor would send no further transaction as the IBR transaction was rejected.If the Distributor has received an IBR in response to a Usage tConsumption Transaction, then even if the Usage tConsumption Transaction is subsequently cancelled, the Distributor must bill the IBR amount unless the Distributor receives an IBR Cancel to cancel the original IBR.In the event that the IBR has been sent and not rejected, and must be revised or replaced, an IBR Cancel tTransaction must be sent, followed by a revised IBR tTransaction for that same service period. It is not valid to send the replacement IBR tTransaction without first cancelling the original IBR transaction Transaction being replaced. The issuance of an IBR Cancel tTransaction may or may not be dependent on the issuance of a Usage Consumption Cancel tTransaction.Account/Rate/Account Service Charges: NOTE: Most of this may not apply – need to discuss An account is described as a specific location that can have multiple meters. A Consumer with multiple locations should have multiple accounts. Within one account there could be multiple meters with different Distributor rates associated with those meters. Based on the above, the following will detail what charges should be used: vER Version 0.15 May 24July 20, 2005 Page 94 GDAR EBT STANDARDS DOCUMENTAccount charges – This field will be used when charges are being applied at an account level regardless of the number of meters or rates associated with that account. Rate Charges – This field will be used when charges are being applied at a Distributor’s rate (price point) level rather than account level. While it is rare that Vendor or Distributors would use this type of charge, it is an option that allows for Distributors and Vendors to charge at a rate level rather than an account levelExamples of this type of charge, if applicable, are Commodity, Transportation, Storage and Vendor Administration Fee.Account charges – This field will be used when charges are being applied at an account level regardless of the rates associated with that account. An example of this type of charge is the Vendor Adjustment. Service Charges – This field will be used when charges are being applied at a meter level. If there were three meters on an account, there would be three service charges – one for each meter. While it is rare that Vendors or Distributors would use this type of charge, it is an option that allows for Distributors and Vendors to charge at a rate level rather than an account level.Billing of Taxes The billing party will be responsible for the collection and remittance of all taxes to the government. See Section 5.3.6 Invoice – Settlement under “Billing of Taxes” for further information.The Distributor shall calculate, collect and remit to Canada Customs & Revenue Agency GST on the Vendor charges and on the Distributor charges. vER Version 0.15 May 24July 20, 2005 Page 95 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR14STR?? Distributor Bill Ready Billing Option1. UsageConsum 2. Invoice – line items 3. Cancel VENDOR UsageConsumption DISTRIBUTOR 4. Cancel – Invoice – line items 5. Corrected UsageConsumption 6. Corrected – Invoice – line itemsCONSUMER 7. Send Bill***Application Advice Accept or Reject must be sent on all above transactions to indicate an accept or reject of the transaction has been processed.Flow: 1. Usage Consumption is sent from the Distributor to the Vendor no later than noon of the 4thwithin 4 business days after the scheduled meter read date.from the date the Distributor calculates the billable consumption. 2. The Vendor calculates the commodity charges based on the contract with the Consumer. The Vendor then submits to the Distributor the line item charge(s) to be put on the Consumer’s bill no later than 2 business days after the UsageConsumption Transaction has been sentreceived. The Distributor can extend this maximum time limit in their service agreement with the Vendor. 3. (Conditional) Distributor sends cancelled Usage Consumption to Vendor. 4. (Conditional) Vendor cancels original Invoice to Distributor. 5. (Conditional – Only if Step 3 occurs) Distributor sends corrected UsageConsumption to Vendor. 6. (Conditional – Only if Step 4 occurs) Vendor sends corrected Invoice to Distributor. 7. The Distributor then sends the Consumer a consolidated bill with both Vendor and Distributor charges on it, outside the EBT System.The Distributor then sends the Consumer a consolidated bill with both Vendor and Distributor charges on it, by regular mail.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 96 GDAR EBT STANDARDS DOCUMENTOptional Invoice TransactionsThe Service Agreement (Board Staff Proposal attached to Procedural Order No. 1 in Proceeding RP-2000-0001 dated July 15, 2005) Section 4.1 clauses (c) through (f) define the process to be undertaken should the Gas Vendor request in writing from the Gas Distributor vendor-consolidated billing or split billing. The following business processes, based on the Electricity EBT Standards, are being included as optional only, and may be revised in accordance with the process identified above. 5.3.3 Invoice – Distributor Rate ReadyDefinition/purpose This transaction is used when the Distributor calculates the Vendor charges based on the rates provided by the Vendor. The Consumer receives one bill from the Distributor with both the Distributor and Vendor charges on their bill.Flow Usage is sent from the Distributor to the Vendor no later than noon of the 4th business day from the scheduled meter read date. The Distributor then calculates the Vendor’s commodity price for the bill and sends the line items to the Vendor no later than 12 business days after the Usage transaction is sent.For Usage errors, the Distributor initiates a Usage Cancel transaction to the Vendor. The Distributor then cancels the original Invoice Rate Ready to the Vendor. The Distributor sends the corrected Usage to the Vendor. The Distributor then issues the corrected Invoice Rate Ready to Vendor (see Cancel/Rebill at the end of the Invoices section for more details). See flow STR15 for details.Response Once the Vendor receives this transaction, they send an Application Advice Accept or Reject back to the Distributor stating that it was either accepted or rejected. This Application Advice Accept or Reject is sent no later than two business days after the receipt of the Invoice Rate Ready (IRR) transaction from the Distributor.An Application Advice Accept transaction in response to an IRR transaction indicates that the invoice amount will be presented on the Consumer billing when the Consumer is billed for all charges for the respective Usage consumption, and the IRR amount will be settled with the Vendor. If an IRR is rejected for any reason (Application Advice Reject), it will not be included in the Consumer billing nor will it be included in the settlement with the Vendor. vER Version 0.15 May 24July 20, 2005 Page 97 GDAR EBT STANDARDS DOCUMENTOnly one Application Advice transaction can be sent in response to any request (i.e. Usage or IBR) received. Where the sending party has made an error in the type of Application Advice transmitted (e.g. an AA Accept was transmitted instead of an AA Reject), the offending party must notify the receiving party of the error immediately and both Trading Partners must work out a fix as mutually agreed.If a Vendor receives an Invoice Rate Ready transaction where the originating Distributor does not correctly calculate the charges, the Vendor will return an Application Advice Reject to the Distributor. The final resolution of the issue will take place offline.Rules There is only one Consumer to one Invoice transaction.An IRR cannot be sent without a corresponding Usage.Billing of Taxes The billing party will be responsible for the collection and remittance of all taxes to the government. See Section 5.3.6 Invoice – Settlement under “Billing of Taxes” for further information.TRANSACTION FLOW STR15 Distributor Rate Ready Billing Option1. Usage 2. Invoice 3. Cancel VENDOR Usage DISTRIBUTOR 4. Cancel Invoice 5. Corrected Usage 6. Corrected Invoice***Application Advice Accept or Reject must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 6. Usage is sent from the Distributor to the Vendor no later than noon of the 4th business day after the scheduled meter read date. 7. (Optional – If the Trading Partners agree that line items are necessary) The Distributor calculates the Vendor’s commodity for the bill and sends the line items to the Vendor no later than 12 business days after the Usage Transaction is sent. 8. (Conditional) Distributor sends cancelled Usage to Vendor. 9. (Conditional) Distributor cancels original Invoice. vER Version 0.15 May 24July 20, 2005 Page 98 GDAR EBT STANDARDS DOCUMENT10. (Conditional – Only if Step 3 occurs) Distributor sends corrected Usage to Vendor. 11. (Conditional – Only if Step 4 occurs) Distributor sends the corrected Invoice to Vendor.The Distributor then sends the Consumer a consolidated bill with both Vendor and Distributor charges on it, by regular mail.5.3.43 Invoice – Vendor Bill ReadyDefinition/purpose The Distributor sends this transaction to the Vendor. This transaction is used when the Distributor calculates its own charges and the charges print on a Vendor’s consolidated bill. The Vendor then sends the complete bill to the Consumer. This is the only type of vendor-consolidated billing currently contemplated.Flow Usage Consumption and charges areis sent from the Distributor to the Vendor no later than noon of the 4thwithin 4 business days from of the scheduled meter read date. The Distributor then calculates the non-competitive delivery charges, which will be sent to the Vendor no later than twelve two business days after the Usage tConsumption Transaction is sent.The Vendor should not begin to execute the Consumer billing after receipt of the IBR until the minimum IBR Bill window interval has elapsed such that any IBR Cancel transaction or subsequent IBR transaction may be processed if also received within the interval. For clarity, if a Distributor wishes to correct an IBR issued to the Vendor, it will send an IBR Cancel and a new IBR. Any of these transactions that are sent within the response interval (from transmission of the original UsageConsumption) should be accepted and processed.For Cancel/Rebill scenarios, the Distributor sends the Usage Consumption Cancel tTransactions to the Vendor. The Distributor must then send the Invoice Bill Ready Cancel tTransaction to the Vendor. The Distributor sends the corrected UsageConsumption tTransaction to the Vendor. The Distributor then sends the corrected Invoice Bill Ready to the Vendor (see Cancel/Rebill at the end of the Invoices section for more details). See flow STR16 for details.Response Once the Vendor receives this transaction, they send an Application Advice Accept or Reject back to the Distributor stating that it was either accepted or rejectedindicating that the transaction has been processed. This Application Advice Accept or Reject is sent no later than two business days after the receipt of the Invoice Bill Ready tTransaction from the Distributor.An Application Advice Accept tTransaction in response to an IBR tTransaction indicates that the invoice amount has been accepted by the Vendor. Such invoice amount will be included in a subsequent Invoice SettlementRemittance vER Version 0.15 May 24July 20, 2005 Page 99 GDAR EBT STANDARDS DOCUMENTDetail between Vendor and Distributor. Usage c Consumption and the IBR amount will be settled with the Vendor. If an IBR is rejected for any reason (Application Advice Reject), it should be dealt with by the Distributor in an expedient fashion.Only one Application Advice tTransaction can be sent in response to any request (i.e. UsageConsumption or IBR) received. Where the sending party has made an error in the type of Application Advice transmitted (e.g. an AA Accept was transmitted instead of an AA Reject), the offending party must notify the receiving party of the error immediately outside the EBT System, and both Trading Partners must work out a fix as mutually agreed.Rules There is only one Consumer Account to one Invoice tTransaction.Where the Distributor chooses to send an IBR, only one valid IBR tTransaction may be sent in reference to one Usage tConsumption Transaction (BillRequired field set to ‘yes’). Multiple IBR tTransactions may not be sent in reference to a single Usage tConsumption Transaction, nor may an IBR be sent without a corresponding UsageConsumption.NOTE: Distributors to provide possible charge categories.Where the Distributor decides to send a Usage Consumption Cancel tTransaction, only one valid IBR Cancel tTransaction may be sent in reference to one Usage Consumption Cancel transaction. An IBR Cancel tTransaction must be issued if the UsageConsumption tTransaction has been cancelled (with a Usage Consumption Cancel tTransaction) and an IBR has already been transmitted in response to the UsageConsumption tTransaction that is being cancelled.Under VCB, if the Distributor has forwarded an IBR in follow-up to a Usage tConsumption Transaction, then the Vendor must invoice the IBR amount even if the Usage tConsumption Transaction is subsequently cancelled. The exception to this is if the Vendor receives an IBR Cancel Transaction for the original IBR Transaction.In the event that the IBR Transaction has been sent and not rejected, and must be revised or replaced, an IBR Cancel tTransaction must be sent, followed by a revised IBR tTransaction for that same service period. It is not valid to send the replacement IBR tTransaction without first cancelling the original IBR tTransaction being replaced. The issuance of an IBR Cancel tTransaction may or may not be dependent on the issuance of a UsageConsumption Cancel tTransaction.Negative charges (credits) are allowed on an IBR. vER Version 0.15 May 24July 20, 2005 Page 100 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR16 Vendor Bill Ready Billing Option1. UsageConsump 2. Non-competitive Invoice 3. Cancel VENDOR UsageConsumption DISTRIBUTOR 4. Cancel Invoice 5. Corrected UsageConsumption 6. Corrected InvoiceVendor sends Bill Consumer***Application Advice Accept or Reject must be sent on all above transactions to indicate an accept or reject of the transaction has been processed.Flow: 1. Usage Consumption is sent from the Distributor to the Vendor no later than noon of the 4th within 4 business days after the scheduled meter read date. 2. Distributor calculates the non-competitive delivery charges and will send them to the Vendor no later than 12 business days after the UsageConsumption tTransaction is sent. 3. (Conditional) Distributor sends cancelled UsageConsumption to Vendor. 4. (Conditional) Distributor sends cancelled Invoice Bill Ready to Vendor. 5. (Conditional – Only if Step 3 occurs) Distributor sends corrected UsageConsumption to Vendor. 6. (Conditional – Only if Step 4 occurs) Distributor sends corrected Invoice Bill Ready to Vendor. 7. Vendor then sends the Consumer a consolidated bill with both Vendor and Distributor charges on it, outside the EBT System.Rules: NoneExceptions: NoneRoles and Responsibilities: None vER Version 0.15 May 24July 20, 2005 Page 101 GDAR EBT STANDARDS DOCUMENT5.3.54 Invoice – Vendor Rate ReadyNOTE: This invoice option will be deleted (waiting for confirmation from Darcy). No parties can see the possibility that this option would be used.Definition/purpose The Vendor sends this transaction to the Distributor. This transaction is used when the Vendor calculates the Distributor charges, based on the rates provided by the Distributor to the Vendor. The Vendor then sends the complete bill to the Consumer.Flow The Usage transaction is sent from the Distributor to the Vendor no later than noon of the 4th business day from the scheduled meter read date. The Vendor then calculates the Distributor’s line items for the bill and sends the line items to the Distributor no later than two business days after the Usage transaction is sent.For Cancel/Rebill scenarios, the Distributor sends the Usage Cancel transaction to the Vendor. The Vendor must then cancel the original Invoice Rate Ready transaction to the Distributor. The Distributor sends the corrected Usage transaction to the Vendor. The Vendor then issues the corrected Invoice Rate Ready (IRR) transaction to the Distributor (see Cancel/Rebill at the end of the Invoices section for more details). See flow STR17 for details.Response Once the Distributor receives this transaction, they send an Application Advice Accept or Reject back to the Vendor stating that it was either accepted or rejected. This Application Advice Accept or Reject is sent no later than two business days after the receipt of the Invoice Rate Ready transaction from the Vendor.An Application Advice Accept transaction in response to an IRR transaction indicates that the invoice amount has been accepted by the Distributor. Such invoice amount will be included in a subsequent Invoice Settlement Detail between Vendor and Distributor. Usage consumption and the IRR amount will be settled with the Vendor. If an IRR is rejected for any reason (Application Advice Reject), it should be dealt with by the Distributor in an expedient fashion.Only one Application Advice transaction can be sent in response to any request (i.e. Usage or IBR) received. Where the sending party has made an error in the type of Application Advice transmitted (e.g. an AA Accept was transmitted instead of an AA Reject), the offending party must notify the receiving party of the error immediately and both Trading Partners must work out a fix as mutually agreed. vER Version 0.15 May 24July 20, 2005 Page 102 GDAR EBT STANDARDS DOCUMENTRules This transaction is a one to one transaction. This means that there is only one Consumer to one Invoice transaction. There may be only one valid Invoice Rate Ready transaction for any given Usage transaction, and only one valid Invoice Rate Ready Cancel transaction for any given Usage Cancel transaction. An IRR cannot be sent without a corresponding Usage.Billing of Taxes The billing party will be responsible for the collection and remittance of all taxes to the government. See Section 5.3.6 Invoice – Settlement under “Billing of Taxes” for further information.TRANSACTION FLOW STR17 Vendor Rate Ready Billing Option1. Usage 2. Invoice 3. Cancel VENDOR Usage DISTRIBUTOR 4. Cancel Invoice 5. Corrected Usage 6. Corrected Invoice***Application Advice Accept or Reject must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 1. Usage is sent from the Distributor to the Vendor no later than noon of the 4th business day after the scheduled meter read date. 2. The Vendor calculates the Distributor’s line items for the bill and sends the line items to the Distributor no later than 2 business days after the Usage transaction is sent. 3. (Conditional) Distributor sends cancelled Usage to Vendor. 4. (Conditional) Vendor sends a cancel original Invoice. 5. (Conditional – Only if Step 3 occurs) Distributor sends corrected Usage to Vendor. 6. (Conditional – Only if Step 4 occurs) Vendor sends corrected Invoice Rate Ready to Distributor.The Vendor then sends the Consumer a consolidated bill with both Vendor and Distributor charges on it, by regular mail. vER Version 0.15 May 24July 20, 2005 Page 103 GDAR EBT STANDARDS DOCUMENT5.3.5 Invoice – Split BillingNOTE: A similar type of billing occurs now for some large customers greater than 700,000 Gj who are not offered ABC Contracts. This section is not intended to supersede or replace any existing contracts which may currently have a type of split billing component. Definition/purpose The Distributor and Vendor both bill the Consumer for their portion of the Invoice. The Consumer receives two Invoices in this billing scenario. The Split Bill requires the exchange of Consumer consumption data from the Distributor to the Vendor via a Consumption Transaction.Flow The Distributor sends the Consumption Transaction to the Vendor within 4 business days from the scheduled meter read date. The Consumer will receive two bill statements, one from the Vendor for their portion of the commodity being provided to the Consumer and one from the Distributor for their delivery service being provided to the Consumer. See flow STR13 for details.Billing of Taxes The billing parties will be responsible for the collection and remittance of all taxes to the government. TRANSACTION FLOW STR13 Split Billing Option1. UsageConsumption VENDOR 2. Cancel DISTRIBUTO UsageConsumption R 3. Corrected UsageConsumptionVendor Invoice for CONSUMER Distributor Invoice for Consumer Consumer***Application Advice Accept or Reject must be sent on all transactions to indicate the transaction has been processed.Flow: 4. Distributor sends Consumption Transaction to Vendor within 4 days of the scheduled meter read date. The Consumer will receive two bill statements – one from the Vendor for the gas commodity and one from the Distributor for delivery charges. 5. (Conditional) Distributor sends Consumption Transaction Cancel to Vendor. 6. (Conditional – Only if Step 2 occurs) Distributor sends corrected Consumption Transaction to Vendor. vER Version 0.15 May 24July 20, 2005 Page 104 GDAR EBT STANDARDS DOCUMENTNOTE: ADDITIONAL REVISION NEEDED FROM THIS POINT ONJuly 20/21 Review stopped at this point.5.3.6 Invoice – SettlementDefinition/purpose These transactions are sent from the Distributor to the Vendor. This is an Invoice that is sent between two Trading Partners that shall be sent in two different transactions:The “Settlement Total” transaction includes summary information based on all Consumers in the billing cycle. The detail that is needed on an individual Consumer level by billing cycle shall be sent using the “Settlement Detail” transaction. This is a mandatory transaction.The “Settlement Detail” transaction contains only one Consumer per transaction. This transaction is also mandatory. It will carry a Settlement cross reference number back to the “Settlement Total” transaction for the Vendor to match up.These Invoice Settlement transactions are used for the settlement between the Distributor and Vendor based on system gas price. These transactions are based on a Consumer’s Bill Cycle. This means that after each day’s Distributor Bill Cycle, the “Settlement Total” Invoice is generated and sent to the Vendor for all Consumers in this Bill Cycle. Once again, for detailed information needed for each Consumer within the Bill Cycle, you will use the Settlement Detail transaction in conjunction with the “Settlement Total” transaction. A Change Consumer Information transaction is required when the Distributor changes the Bill Cycle for a Consumer.The Invoice Settlement Detail (ISD) transaction is a Consumer-level account statement sent from a Distributor to a Vendor. The charges and credits listed on a given ISD must reflect any transactions listed below that are:  sent by, or received by, a Distributor for a particular Consumer since the last ISD transaction for that Consumer was issued; and  which cause a charge to be generated for Consumer billing and settlement.The transactions to be considered on the ISD transaction are as follows:  Usage transactions sent by the Distributor and used to calculate the settlement.  Usage-Cancel transactions sent by the Distributor and used to calculate the settlement.  Invoice Bill Ready transactions sent by the Vendor (or Distributor for Vendor Consolidated Billing) and used to calculate the settlement.  Invoice Bill Ready-Cancel transactions sent by the Vendor (or Distributor for Vendor Consolidated Billing) and used to calculate the settlement.  Invoice Rate Ready transactions sent by the Distributor and used to calculate the settlement. vER Version 0.15 May 24July 20, 2005 Page 105 GDAR EBT STANDARDS DOCUMENT Invoice Rate Ready-Cancel transactions sent by the Distributor and used to calculate the settlement. Flow These transactions are always sent from the Distributor to the Vendor. The timeframe of when these transactions are sent will be defined in the service agreement between the Distributor and Vendor. If these transactions do not meet the criteria defined by the EBT Standards, the Application Advice Reject will be generated to reject that transaction. Response Once the Vendor receives these transactions, they send an Application Advice Accept or Reject back to the Distributor stating that the transaction was either accepted or rejected. This Application Advice Accept or Reject is sent no later than two business days after the receipt of the Invoice transactions from the Distributor.Rules The “Invoice Settlement Total”(IST) transaction is mandatory. The “Invoice Settlement Detail” (ISD) transaction is also mandatory and contains only one Consumer per transaction. This transaction is sent based on a Consumer billing cycle.It is not the intention to alter the Distributor’s billing patterns and therefore the Billing Cycle is optional within the IST. To that end, a Distributor has two options for creating the IST:Option 1.) Do not present the Bill Cycle within the IST transaction and include more than one Bill Cycle within the IST transaction. The Bill Cycle for each Consumer is required in the ISD transactions that provide the detailed breakdown of the total.Option 2.) Present multiple IST transactions during the day. Each IST transaction is the total for a group of one, or more, ISD transactions where all ISD transactions within each group correspond to a single Bill Cycle.The IST transaction has a "Begin Date" and "End Date" under Service Period. These are mandatory fields. For the summary invoice of daily billing, this could span multiple service periods and Bill Cycles, particularly if adjustments are involved. The dates reflect when the charge was incurred (i.e., the dates for the invoice itself, not when the activities, or line items, may have taken place).The IST will provide for charges to be presented individually totalled by Account Charge Category. Further stated, a given IST transaction is associated with a set of one, or more, ISD transactions. Each of the ISDs points to the IST via the Transaction Cross Reference Number. The IST must contain sub-totals for each charge category type present with its associated set of ISD transactions. The amounts in the set of ISD transactions must balance against those in the associated IST transaction. Example IST calculations can be vER Version 0.15 May 24July 20, 2005 Page 106 GDAR EBT STANDARDS DOCUMENT found in Appendix C, Section 3.1 for Distributor Consolidated Billing, and Sections 3.2 and 3.3 for Vendor Consolidated Billing.When the Distributor wishes to send ISD transactions that correspond to different due dates, multiple IST transactions are required. The due date for each ISD transaction associated with a given IST transaction must be the same and must match that in the IST transaction.The information within the MarketParticipantInformation element should be of the type normally placed on a bill when invoicing a second party (i.e. the originator’s information). Specifically, this means the following:  The company name is the originator’s company name.  The GST Registration Number is that of the originator.  The MarketParticipantAccountNumber is the account number for the trading partner recipient of the message as held by the originator of the message. In this case, the recipient is the customer of the originator.  Billing Cycle is the originator’s billing cycle for this trading partner as a customerThe ‘Source Transaction Reference Number’ field in the ISD transaction will be populated with the Transaction Reference Number of the transaction being settled. The Source Transaction Reference Number will be required for every ‘VendorBillAmount’ and ‘Commodity’ Account Charge Category for Distributor Consolidated Billing (and every Account Charge Category coming from the Usage(s) and IBR transactions for Vendor Consolidated Billing). Each Account Charge will be assigned an Account Charge Category according to the source of the charge.There are three possible Account Charge Categories which may be used for the Distributor Consolidated Billing Option:Charge Category “Commodity”  Used for all charges related to the Competitive Gas Cost.  The Source Transaction Reference Number will refer to the Usage or Usage- Cancel EBT that contained the usage data used to calculate the charge. Charge Category “VendorBillAmount”  Used for the Vendor’s charges to the Consumer, including account, rate, and service charges  The Source Transaction Reference Number will refer to the Invoice Bill- Ready, Invoice Bill-Ready-Cancel, Invoice Rate-Ready, or Invoice Rate- Ready-Cancel transaction used to request the charges. Charge Category “Taxes”  Used in accordance with the “Billing of Taxes” options below.  The Source Transaction Reference Number will contain a null value.The applicable Charge Categories will be shown on the ISD for each Invoice Bill-Ready, Invoice Bill-Ready-Cancel, Invoice Rate-Ready, and Invoice Rate-Ready-Cancel transaction that generates a charge to be settled, notwithstanding the following: vER Version 0.15 May 24July 20, 2005 Page 107 GDAR EBT STANDARDS DOCUMENT Invoice Bill-Ready- When a Usage and corresponding Usage-Cancel EBT are issued within the same Consumer billing cycle, there is no net effect on the Consumer bill and therefore the transactions will not be captured on the ISD. Similarly, when an IBR and corresponding IBR-Cancel EBT are received within the same Consumer billing cycle, there is no net effect on the Consumer bill and the transactions therefore will not be captured on the ISD.  Invoice Rate-Ready- When a Usage and corresponding Usage-Cancel EBT are issued within the same Consumer billing cycle, there is no net effect on the Consumer bill and therefore the transactions will not be captured on the ISD. Similarly, when an IRR and corresponding IRR-Cancel EBT are received within the same Consumer billing cycle, there is no net effect on the Consumer bill and the transactions therefore will not be captured on the ISD. For Vendor Consolidated Billing, charges in the ISD will be presented per Account Charge Category. Categories on IBRs and IBR Cancels refer to all occurrences of charge categories, including account, rate, and service charges. Charge Category “Commodity”  Used to represent the cost of the Usage Consumption (specifically, the ‘Commodity’ charge total for a specified service period per Usage transaction).  The Source Transaction Reference Number shall refer to the Usage or Usage Cancel transaction that contained the usage data used to calculate the charge. Charge Category “Customer”  Used by the Distributor to recover the fixed costs for delivering gas.  The Source Transaction Reference Number shall refer to the IBR or IBR- Cancel transaction that contained the data used to calculate the charge. Charge Category “Distribution”  Used to represent the variable cost of delivering gas from the Distributor to the end Consumer, as well as the cost for providing services such as meter reading, billing and account maintenance.  The Source Transaction Reference Number shall refer to the IBR or IBR- Cancel transaction that contained the data used to calculate the charge. Charge Category “Transmission”  Used to represent the Distributor’s transmission rate.  The Source Transaction Reference Number shall refer to the IBR or IBR- Cancel transaction that contained the data used to calculate the charge. Charge Category “Taxes”  Used in accordance with the “Billing of Taxes” options below.  The Source Transaction Reference Number shall contain a null value. Charge Category “OtherSpecificCharges”  Used to capture other specified charges not identified above as a separate Category code. This Charge Category may not be used to reflect any charge categories that are defined already in this section. vER Version 0.15 May 24July 20, 2005 Page 108 GDAR EBT STANDARDS DOCUMENT Where this Charge Category is used, the Charge Category ‘Description’ field of the transaction shall reflect the exact charge description as approved on the Distributor’s Rate Order.  Where there are multiple items, each item must be reflected with a Charge Category of ‘OtherSpecificCharges’ and the Description field populated.  ‘Miscellaneous’ is not a valid Charge Category.  The Source Transaction Reference Number shall refer to the IBR or IBR- Cancel transaction that contained the data used to calculate the charge.Corrections to settlement amounts will be agreed upon by both parties and included on a future ISD transaction. The correction will be listed as an Account Charge with Source Transaction Reference Number referencing the Usage, Invoice Bill Ready, Invoice Rate Ready, or associated Cancel transaction for which the settlement amount is being corrected. The Charge Category will be chosen according to the transaction type, as described above.For clarity, the amount is not to be presented as an adjustment to the original amount, but as a correction. The incorrect amount must be provided as a reversal referencing the Source Transaction Reference Number of the transaction for which the amount is being reversed, and then issuing the corrected amount referencing the Source Transaction Reference Number of the transaction for which the amount is being corrected.The reversal and corrected amount may be provided for in the same ISD or in two separate ISDs. The correction will also be captured in the subsequent IST that follows. The Bill Purpose will be “Original”.Billing of Taxes The billing party will be responsible for the collection and remittance of all taxes to the government. The taxes in a transaction have to be listed and applied at the structural level within the transaction where the charge is actually listed.Taxes can be presented within EBTs in one of two ways: Option 1: Present the taxes without ‘Taxes’ as a charge category. With this option, each charge carries its own tax amount as part of the taxes element associated with the charge. There is no separate charge with a Charge Category of 'Taxes' Option 2: Present the taxes as a separate charge category. With this option, each charge carries a tax element with a tax amount of zero. A charge with a Charge Category of 'Taxes' exists. This charge has an amount of zero, but contains a tax amount equal to the total of the taxes for all the charges.Independent of whether option one or option two is selected, the total of all the charge amounts is the same and the total of all the tax amounts is the same. vER Version 0.15 May 24July 20, 2005 Page 109 GDAR EBT STANDARDS DOCUMENTAny taxes, calculated and rounded (per CCRA requirements) on ISDs, must be presented in the IST using summed ISD amounts. Such ISD calculated and rounded amounts cannot be recalculated from scratch (i.e. using the summed base amounts) and then rounded again on the IST. For example, if GST is calculated and rounded to a dollar amount on each ISD, the corresponding IST should show the summed ISD GST amounts as rounded in the ISDs and not 7% of the taxable amount. If the latter were to occur on an IST with large numbers of ISDs (which is quite common), the cumulative rounding effects can introduce reconciliation discrepancies. This applies to both Tax Option 1 and 2.It similarly follows that in order to maintain consistency between IST and ISD amounts, all tax amounts presented in an IST must equal the sum of all tax amounts presented on the corresponding ISDs. In the case of a tax-exempt Consumer where the Distributor charges the Vendor tax on a given account charge, the tax amount to be settled with the Retailer must be presented. This is due to the fact that an ISD is a Consumer-level breakdown of settlement information as it pertains to Vendor settlement. The tax exemption flag strictly indicates whether the Consumer was tax exempt.TRANSACTION FLOW STR Settlement Invoice – Distributor Consolidated Billing1. Settlement VENDOR Invoice 2. Cancel/Rebill DISTRIBUTOR Invoice***Application Advice must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 1. Distributor sends the Settlement Invoice (Detail and Total) according to a schedule provided in the Service Agreement. The amounts per Consumer account are calculated on the Usage that was sent previously multiplied by the difference between the System Gas price and the Vendor’s contract price with the Consumer. 2. If these transactions are disputed, the Application Advice Reject will be generated. The dispute will then be handled outside of the EBT system. vER Version 0.15 May 24July 20, 2005 Page 110 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW STR Settlement Invoice – Vendor Consolidated Billing1. Settlement VENDOR Invoice 2. Cancel/Rebill DISTRIBUTOR Invoice***Application Advice must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 1. Distributor sends the Settlement Invoice (Detail and Total) according to a schedule provided in the Service Agreement. The amounts per Consumer account are calculated on the Usage that was sent previously multiplied by the difference between the System Gas price and the Vendor’s contract price with the Consumer. 2. If these transactions are disputed, the Application Advice Reject will be generated. The dispute will then be handled outside of the EBT system. vER Version 0.15 May 24July 20, 2005 Page 111 GDAR EBT STANDARDS DOCUMENT5.3.7 Invoice – Market ParticipantDefinition/purpose This is a mandatory transaction that is sent through the EBT system between the Market Participants (a/k/a Trading Partners). A Market Participant sends an invoice to another Market Participant which represents the administration charges and other fees (e.g., enrolment fees, meter reads, collection charges, billing services, etc.). The Market Participant Invoice schedule will be determined between the trading partners, and is defined in the Trading Partner Service Agreement.Flow The Market Participant sends an Invoice to another Market Participant which represents the administration charges and other fees (e.g., enrolment fees, meter reads, collection charges, billing services, etc.). The days for which the Invoice will be calculated, as well as when the Invoice will be submitted, are determined in the trading partner’s service agreement. For Cancel/Rebill scenarios, Market Participant A sends an Invoice to reverse the invoice to be cancelled to another Market Participant, identified as Market Participant B. Market Participant A then sends the corrected Invoice to Market Participant B. (see Cancel/Rebill at the end of the Invoices section for more details). See INV-11 for more details.Data All applicable IMP charges shall be captured and categorized in the Charge Description data field using the recommended wording identified in the table below. Retailer Service Charges shall be detailed in the IMP Invoice in accordance with the relationship between Distribution Rate Handbook Services and transactions as outlined in Appendix B, and the charges categories supported by the Rate Handbook. The Charge Quantity field for each description shall reflect the transaction volumes or one-time charges for each Charge Description on the IMP Invoice.The following table outlines the applicable Charge Category values and the standardized Charge Description to be used on the IMP invoice: vER Version 0.15 May 24July 20, 2005 Page 112 GDAR EBT STANDARDS DOCUMENTCharge Category Retailer Service Description of Charge Charge Description to be used on Charges IMP Invoice RetailServiceCharges Standard Charge This refers to the ‘one-time’ charge Retailer Service Agreement and is intended to recover the costs of entering into the Service Agreement required by the Retail Settlement Code RetailServiceCharges Monthly Fixed This is intended to recover the cost Monthly Fixed Charge Charge of contract administration and monitoring of prudential requirements RetailServiceCharges Monthly This is intended to recover the costs Monthly Variable Charge Variable Charge related to general accounting, administration services and other communication and customer care services necessary to maintain the contract RetailServiceCharges Distributor This is intended to recover the Distributor Consolidated Billing Consolidated incremental costs incurred by a Charge Billing Charge Distributor in providing a Distributor-Consolidated Bill-Ready service RetailServiceCharges Retailer Under this arrangement, a Retailer Consolidated Billing Consolidated Distributor does not directly bill a Charge Billing Charge Consumer. Consequently, a Distributor will avoid certain costs (e.g. mailing). Hence, an avoided cost credit shall be paid to a Retailer that chooses Retailer-Consolidated Billing under this Charge Category RetailServiceCharges Request Fee(s) This is intended to recover costs Change Bill Option-STR-Request; incurred by a Distributor for the Change Customer Location-STR- initial screening process of an STR Request; Enrol-STR-Request; Drop-STR-Request -Retailer Initiated RetailServiceCharges Processing This is intended to recover costs Change Bill Option-STR-Accept; Fee(s) incurred to process the transaction Change Customer Location-STR- based on rules and procedures set Accept; Change Customer out under Chapter 10 of the RSC. Location-STR-Accept No See Appendix B of this document Response; Drop-STR-Retailer for further clarification Initiated-Accept; Enrol-STR- Accept; Meter - Accept Miscellaneous Miscellaneous Categories outside of the defined Interest On Late Payment Charges; request, processing, monthly and Specified Meter Read-Complete. variable charges Miscellaneous – (include description to describe activity) NOTE: The IMP description of “Miscellaneous” shall not be used for fees/charges categorized in the aforementioned defined Retailer Charge Categories and associated IMP description vER Version 0.15 May 24July 20, 2005 Page 113 GDAR EBT STANDARDS DOCUMENTResponse Once Market Participant B receives this transaction, they send an Application Advice back to Market Participant A stating that it was either accepted or rejected. This Application Advice is sent no later than two business days after the receipt of the Invoice transaction from Market Participant A.Rules This transaction is a one to one relationship. This means that there will be only one Invoice for all charges sent between Market Participants.The information within the MarketParticipantInformation element should be of the type normally placed on a bill when invoicing a second party (i.e. the originator’s information). Specifically, this means the following:  The company name is the originator’s company name.  The GST Registration Number is that of the originator.  The MarketParticipantAccountNumber is the account number for the trading partner recipient of the message as held by the originator of the message. In this case, the recipient is the customer of the originator.  Billing Cycle is the originator’s billing cycle for this trading partner as a customerIt is recommended that the IMP invoice for monthly charges be issued consistently once a month following the previous month’s charges. There shall be no gaps or overlaps in the service periods. All charges contained in the IMP invoice should reflect the transactions for the service period identified. It is also suggested that the submission date should be no later than 15 calendar days after the most recently completed Billing Month and the due date should be the current industry standard of net 30 (calendar) days.Note: If there is a need to charge for transactions outside of the service period then they should be identified in the “miscellaneous” Charge Category with a date and applicable Charge Description.If a Consumer drops in the middle of a monthly service period, any charges for that Consumer should be included in the IMP Invoice for the month since the calculation should be based on Consumers that were on flow or active within the service period timeframe.Billing of Taxes The billing party will be responsible for the collection and remittance of all taxes to the government. The taxes in a transaction have to be listed and applied at the structural level within the transaction where the charge is actually listed. See Section 5.3.6 Invoice – Settlement under “Billing of Taxes” for further information.There are two possible methods of calculating GST. In the first method, the charges are totalled and then the GST is calculated, rounding to the nearest cent. In the second method, the GST is calculated on each charge, rounding as appropriate, and the total vER Version 0.15 May 24July 20, 2005 Page 114 GDAR EBT STANDARDS DOCUMENT charge plus tax is calculated. It is suggested that the CCRA be consulted if there are questions about methods of calculating the GST.TRANSACTION FLOW INV-11: Market Participant Invoice1. Market Participant 1. Market Participant Invoice Invoice RETAILER 2. Reverse HUB 2. Reverse Invoice Invoice DISTRIBUTOR 3. Corrected 3. Corrected Invoice Invoice***Application Advice must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 1. Market Participant sends Invoice to other Market Participant that represents the admin. charges and the other fees (e.g. enrolment fees, meter reads, collection charges, billing services, etc.). The invoice will be calculated and submitted based on the number of days stipulated in the service agreement between the trading parties. 2. (Conditional) Market Participant sends Invoice to reverse original Invoice to other Market Participant. 3. (Conditional – Only if Step 2 occurs) Market Participant sends Corrected Invoice to other Market Participant. vER Version 0.15 May 24July 20, 2005 Page 115 GDAR EBT STANDARDS DOCUMENT5.3.8 Cancel/Rebill ProceduresThe Retail Settlement Code uses the following statements with respect to Billing Errors -- Adjustments: Adjustments for Invoices that are over billed can be credited to the Retailer/Consumer within up to a six-year time period as long as Measurement Canada has not become involved. The adjustment will also contain an interest amount as well as the adjustment amount. This adjustment will be performed by sending an Invoice transaction with a code for adjustment.  Adjustments for Invoices that are under billed can be debited back to the Retailer/Consumer within up to a two-year time period as long as Measurement Canada has not become involved. This adjustment will be done by sending an Invoice transaction with a code for adjustment.Cancel/Rebill Procedure – Distributor Consolidated Billing Option – Bill Ready1. (Conditional) Distributor Cancels Meter Readings: Distributor will forward one Usage Cancel transaction for each billing period being cancelled to the current Retailer for only the service periods in which the Consumer was served by that Retailer. When a given service period is to be cancelled and rebilled by a Distributor, the Distributor may only need to issue a Usage Cancel transaction for the specific service period, or may also need to cancel and rebill all service periods since the service period in error. For each individual Usage transaction to be cancelled, the Retailer will receive a corresponding Usage Cancel transaction. Service Periods to be cancelled shall be processed in a consecutive sequence by the Distributor. Service Periods to be rebilled, where corrected Usage transactions will be sent, shall also be processed in a consecutive sequence by the Distributor.Where a Consumer was served by multiple Retailers during the periods being rebilled, the Distributor must rebill the service periods with each of the respective Retailers for only the periods in which the Consumer was served by each Retailer. Usage Cancel transactions older than 24 months and/or cancellations involving prior Retailers can be communicated by EBT if all Market Participants agree. An active Retailer must be able to accept and process further transactions on a Consumer account for 24 months after an account becomes ‘inactive’ in their system (i.e. Consumer is dropped and no longer receiving service from the Retailer).2. Retailer Cancels Charges related to Cancelled Meter Readings: The current Retailer shall cancel their charges by forwarding an Invoice Bill Ready Cancel transaction for each original Invoice Bill Ready transaction sent. The Distributor will reject Invoice Bill Ready Cancel transactions from all previous Retailers unless agreement has previously been reached to accept these transactions through the EBT system. vER Version 0.15 May 24July 20, 2005 Page 116 GDAR EBT STANDARDS DOCUMENT3. (Conditional) Distributor Sends Corrected Meter Readings: Distributor will forward one or more new Usage transactions to the current Retailer for the applicable period of time (see section 5.2.1 Usage Transaction under the heading ‘Rules’ for more information). Corrected usage data older than 24 months and/or corrected usage data involving prior Retailers can be communicated by EBT if all Market Participants agree.4. Bill Ready Bill Data: Within two (2) business days of Step 3, the current Retailer shall forward to the Distributor one Invoice Bill Ready transaction for each Usage transaction. Any Invoice Bill Ready transactions received after the two-business day window will be rejected by the Distributor using the Application Advice transaction. When the Invoice Bill Ready is rejected, the Retailer will be required to combine the charges, one for the rejected Invoice Bill Ready and one for the current month’s charges, into one Invoice Bill Ready transaction for the following month. Additionally, Invoice Bill Ready transactions received from all previous Retailers will be rejected unless agreement has previously been reached to accept these transactions through the EBT system.Cancel/Rebill Procedure – Distributor Consolidated Billing Option – Rate Ready1. (Conditional) Distributor Cancels Meter Readings: Distributor will forward one Usage Cancel transaction for each billing period being cancelled to the current Retailer for only the service periods in which the Consumer was served by that Retailer. When a given service period is to be cancelled and rebilled by a Distributor, the Distributor may only need to issue a Usage Cancel transaction for the specific service period, or may also need to cancel and rebill all service periods since the service period in error. For each individual Usage transaction to be cancelled, the Retailer will receive a corresponding Usage Cancel transaction. Service Periods to be cancelled shall be processed in a consecutive sequence by the Distributor. Service Periods to be rebilled, where corrected Usage transactions will be sent, shall also be processed in a consecutive sequence by the Distributor.Where a Consumer was served by multiple Retailers during the periods being rebilled, the Distributor must rebill the service periods with each of the respective Retailers for only the periods in which the Consumer was served by each Retailer. Usage Cancel transactions older than 24 months and/or cancellations involving prior Retailers can be communicated by EBT if all Market Participants agree. An active Retailer must be able to accept and process further transactions on a Consumer account for 24 months after an account becomes ‘inactive’ in their system (i.e. Consumer is dropped and no longer receiving service from the Retailer). vER Version 0.15 May 24July 20, 2005 Page 117 GDAR EBT STANDARDS DOCUMENT2. (Conditional) Distributor Cancels Charges related to Cancelled Meter Readings: Distributor will forward one Invoice Rate Ready Cancel transaction for each billing period being cancelled to the current Retailer. Invoice Rate Ready Cancel transactions older than 24 months can be communicated by EBT if all Market Participants agree. Distributor will NOT send Invoice Rate Ready Cancel transactions to prior Retailers unless agreement has previously been reached to accept these transactions through the EBT system. 3. (Conditional) Distributor Sends Corrected Meter Readings: Distributor will forward one or more new Usage transaction to the current Retailer for the applicable period of time (see section 5.2.1 Usage Transaction under the heading ‘Rules’ for more information). Corrected usage data older than 24 months and/or corrected usage data involving prior Retailers can be communicated by EBT if all Market Participants agree.4. Distributor Sends Corrected Charges: Distributor will forward one new Invoice Rate Ready transaction to the current Retailer for each Usage transaction sent for the applicable period of time. Corrected charges older than 24 months can be communicated by EBT if all Market Participants agree.Cancel/Rebill Procedure – Retailer Consolidated Billing Option – Bill Ready1. (Conditional) Distributor Cancels Meter Readings: Distributor will forward one Usage Cancel transaction for each billing period being cancelled to the current Retailer for only the service periods in which the Consumer was served by that Retailer. When a given service period is to be cancelled and rebilled by a Distributor, the Distributor may only need to issue a Usage Cancel transaction for the specific service period, or may also need to cancel and rebill all service periods since the service period in error. For each individual Usage transaction to be cancelled, the Retailer will receive a corresponding Usage Cancel transaction. Service Periods to be cancelled shall be processed in a consecutive sequence by the Distributor. Service Periods to be rebilled, where corrected Usage transactions will be sent, shall also be processed in a consecutive sequence by the Distributor.Where a Consumer was served by multiple Retailers during the periods being rebilled, the Distributor must rebill the service periods with each of the respective Retailers for only the periods in which the Consumer was served by each Retailer. Usage Cancel transactions older than 24 months and/or cancellations involving prior Retailers can be communicated by EBT if all Market Participants agree. An active Retailer must be able to accept and process further transactions on a Consumer account for 24 months after an account becomes ‘inactive’ in their system (i.e. Consumer is dropped and no longer receiving service from the Retailer).2. Distributor Cancels Charges related to Cancelled Meter Readings: The current Distributor shall cancel their charges by forwarding an Invoice Bill Ready Cancel transaction for each original Invoice Bill Ready transaction sent. The Retailer will vER Version 0.15 May 24July 20, 2005 Page 118 GDAR EBT STANDARDS DOCUMENT reject Invoice Bill Ready Cancel transactions from all previous Distributors unless agreement has previously been reached to accept these transactions through the EBT system.3. (Conditional) Distributor Sends Corrected Meter Readings: Distributor will forward one or more new Usage transaction to the current Retailer for the applicable period of time (see section 5.2.1 Usage Transaction under the heading ‘Rules’ for more information). Corrected usage data older than 24 months and/or corrected usage data involving prior Retailers can be communicated by EBT if all market Participants agree.4. Bill Ready Bill Data: Within two (2) business days of Step 3, the current Distributor shall forward to the Retailer one Invoice Bill Ready transaction for each Usage transaction. Any Invoice Bill Ready transactions received after the two-business day window will be rejected by the Retailer using the Application Advice transaction. When the Invoice Bill Ready is rejected, the Distributor will be required to combine the charges, one for the rejected Invoice Bill Ready and one for the current month’s charges, into one Invoice Bill Ready transaction the following month,. Additionally, Invoice Bill Ready transactions received from all previous Distributors will be rejected unless agreement has previously been reached to accept these transactions through the EBT system.Cancel/Rebill Procedure – Retailer Consolidated Billing Option – Rate Ready1. (Conditional) Distributor Cancels Meter Readings: Distributor will forward one Usage Cancel transaction for each billing period being cancelled to the current Retailer for only the service periods in which the Consumer was served by that Retailer. When a given service period is to be cancelled and rebilled by a Distributor, the Distributor may only need to issue a Usage Cancel transaction for the specific service period, or may also need to cancel and rebill all service periods since the service period in error. For each individual Usage transaction to be cancelled, the Retailer will receive a corresponding Usage Cancel transaction. Service Periods to be cancelled shall be processed in a consecutive sequence by the Distributor. Service Periods to be rebilled, where corrected Usage transactions will be sent, shall also be processed in a consecutive sequence by the Distributor.Where a Consumer was served by multiple Retailers during the periods being rebilled, the Distributor must rebill the service periods with each of the respective Retailers for only the periods in which the Consumer was served by each Retailer. Usage Cancel transactions older than 24 months and/or cancellations involving prior Retailers can be communicated by EBT if all Market Participants agree. An active Retailer must be able to accept and process further transactions on a Consumer account for 24 months after an account becomes ‘inactive’ in their system (i.e. Consumer is dropped and no longer receiving service from the Retailer). vER Version 0.15 May 24July 20, 2005 Page 119 GDAR EBT STANDARDS DOCUMENT2. (Conditional) Retailer Cancels Charges related to Cancelled Meter Readings: Retailer will forward one Invoice Rate Ready Cancel transaction for each billing period being cancelled to the current Distributor. Invoice Rate Ready Cancel transactions older than 24 months can be communicated by EBT if all Market Participants agree. Retailer will NOT send Invoice Rate Ready Cancel transactions to prior Distributors unless agreement has previously been reached to accept these transactions through the EBT system. 3. (Conditional) Distributor Sends Corrected Meter Readings: Distributor will forward one or more new Usage transaction to the current Retailer for the applicable period of time (see section 5.2.1 Usage Transaction under the heading ‘Rules’ for more information). Corrected usage data older than 24 months and/or corrected usage data involving prior Retailers can be communicated by EBT if all Market Participants agree.4. Retailer Sends Corrected Charges: Retailer will forward one new Invoice Rate Ready transaction to the current Distributor for each Usage transaction received for the applicable period of time. Corrected charges older than 24 months can be communicated by EBT if all Market Participants agree.Cancel/Rebill Procedure – Settlement Invoice1. (Conditional) Distributor “Cancels” Settlement Invoice: Distributor will forward one Settlement Invoice transaction that reverses the invoice to be “cancelled” for each billing period being “cancelled” to the current Retailer for only the service periods in which the Consumer was served by that Retailer. Where a Consumer was served by multiple Retailers during the periods being rebilled, the Distributor must resettle the service periods with each of the respective Retailers for only the periods in which the Consumer was served by each Retailer. Settlement Invoice transactions older than 24 months can be communicated by EBT if all Market Participants agree. Distributor will not send Settlement Invoice transactions to a prior Retailer unless the Retailer has agreed to process these transactions using EBT. An active Retailer must be able to accept and process further transactions on a Consumer account for 24 months after an account becomes ‘inactive’ in their system (i.e. Consumer is dropped and no longer receiving service from the Retailer).2. Distributor Rebills Settlement Invoice: Distributor will forward one new Settlement Invoice transaction to the current Retailer for the applicable period of time. Corrected Settlement Invoice data older than 24 months and/or corrected Settlement Invoice data involving prior Retailers can be communicated by EBT if all Market Participants agree.Cancel/Rebill Procedure – Market Participant Invoice1. (Conditional) Distributor/Retailer “Cancels” Invoice: Distributor/Retailer will forward one Invoice Market Participant transaction to reverse each Invoice affected to vER Version 0.15 May 24July 20, 2005 Page 120 GDAR EBT STANDARDS DOCUMENT the Distributor/Retailer. Invoice Market Participant transactions older than 24 months can be communicated by EBT if all Market Participants agree. Distributor/Retailer will NOT send Invoice Market Participant transactions to Retailers/Distributors without a valid service agreement.2. Distributor/Retailer Rebills Invoice: Distributor/Retailer will forward one new Invoice Market Participant transaction to the Distributor/Retailer for the applicable period of time. Corrected Invoice Market Participant transaction data older than 24 months can be communicated by EBT if all Market Participants agree.Cancel/Rebill Procedure - Over Bill Option Changes Any cancel/rebill that pertains to a prior billing option change will be done outside the EBT system.Cancel/Rebill Procedure - Prior Retailers and Distributors Any cancel/rebill that pertains to a prior Market Participant may be done using the EBT system if all Market Participants agree; otherwise it will be done outside the EBT system.Correction of Taxes The billing party will be responsible for the correction and settlement of all taxes to the government. The taxes in a transaction have to be listed and applied at the structural level within the transaction where the charge is actually listed. See Section 5.3.6 Invoice – Settlement under “Billing of Taxes” for further information. vER Version 0.15 May 24July 20, 2005 Page 121 GDAR EBT STANDARDS DOCUMENT5.4 Payment AdviceThe sections below define the definition/purpose, flow, response, and business rules around implementing any type of Payment Advice. The types of Payment Advice transactions that are specified in the Retail Settlements Code: Settlement Invoice  Market Participant InvoiceThe above Settlement Invoice Payment Advice can be sent in the following manner. The Market Participant Invoice will be the “Payment Advice Total” transaction only.“Payment Advice Total” transaction includes just the summarized total that is to be paid by the Trading Partner for a given Consumer’s billing cycle.“Payment Advice Detail” transaction contains only one Consumer per transaction. This is sent if individual information is needed on an individual Consumer level. If it is used, it has a Payment cross reference number back to the “Payment Advice Total” transaction for the Trading Partner to match up.5.4.1 Payment Advice – Settlement BillingDefinition/purpose This is a transaction to let either the Distributor or Retailer know when and how to expect their payment of the Settlement Invoice. The payment due date is the same as the Consumer bill.Flow On the due date of payment, the Distributor or Retailer forwards the Payment Advice to the other party. The actual payment will be sent according to the Payment Advice. The options are “Direct Deposit”, “Wire Transfer”, and “Cheque”. See flow PA-1 for details.Response Once the Distributor or Retailer receives this transaction, they send an Application Advice back to the other party stating that it was either accepted or rejected. This Application Advice is sent no later than two business days after the receipt of the Payment Advice transaction.Rules Payments are made based on the amount and due date of the Settlement Invoice. vER Version 0.15 May 24July 20, 2005 Page 122 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW PA-1: Settlement Payment AdviceRETAILER HUB DISTRIBUTOR 1. Payment Advice 1. Payment Advice***Application Advice must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 1. Retailer validates Invoice and Distributor forwards Payment Advice (Total and/or Detail) to the Retailer if payment is due to the Retailer. If monies are owed to the Distributor, then the Retailer forwards the Payment Advice (Total and/or Detail) to the Distributor. Rules: Either Retailer or Distributor can send Settlement Payment Advice (Total and/or Detail), so this process flow is bi-directional.5.4.2 Payment Advice – Market ParticipantDefinition/purpose This is a transaction to let either the Distributor or Retailer know when and how to expect their payment on their portion of the Market Participant Invoice. The only Payment Advice transaction allowed for this is the “Payment Advice Total”. The payment due date is decided upon by Trading Partners and defined in their Service Agreement.Flow On the due date of payment, the Distributor or Retailer forwards the Payment Advice to the other party. The actual payment will be sent according to the Payment Advice. The options are “Direct Deposit”, “Wire Transfer”, and “Cheque”. See flow PA-2 for details.Response Once the Distributor or Retailer receives this transaction, they send an Application Advice back to the other party stating that it was either accepted or rejected. This Application Advice is sent no later than two business days after the receipt of the Payment Advice transaction from the Trading Partner that sent the Payment Advice.Rules Payments are made based on the amount and due date of the Market Participant Invoice. vER Version 0.15 May 24July 20, 2005 Page 123 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW PA-2: Market Participant Payment AdviceRETAILER HUB DISTRIBUTOR 1. Payment Advice 1. Payment Advice***Application Advice must be sent on all above transactions to indicate an accept or reject of the transaction.Flow: 1. Market Participant validates Invoice and forwards Payment Advice (Total only) to the other Market Participant.Rules: Either Retailer or Distributor can send Market Participant Payment Advice (Total only), so this process flow is bi-directional. vER Version 0.15 May 24July 20, 2005 Page 124 GDAR EBT STANDARDS DOCUMENT5.5 Net System Load Shape DailyDefinition/Purpose The NSLS Daily transaction provides net system load shape (NSLS) information from a Distributor to a Retailer. The Distributor must transmit a particular day’s NSLS to all the Retailers operating within its territory no later than three business days after receiving the preliminary daily statement data from the IMO.Flow The NSLS Daily transaction is a one-way posting from a Distributor to a Retailer. Data The NSLS Daily transaction uses the units of kWh for usage and cents per kWh for price. Prices should be provided to three decimal places. An example of conversion - $1,499.99 per MWh becomes 0149.999 cents per kWh.The NSLS Daily transaction provides the ability to convey information for many zones within a Distributor’s territory. Initially, the vast majority of Distributors will only have a single zone. For each zone there are 24 samples of total consumption data for the zone and the corresponding spot price. Each sample given in the transaction represents an hour of the day beginning with the hour between midnight and 1:00am EST.Response No form of an acknowledge transaction such as an Application Advice response is required for this transaction. The only response back from a NSLS Daily transaction will be a Functional Acknowledgement. Rules Any NSLS information re-sent for a specific day will replace all older copies of the data. Because of this, no cancel transaction is required. To correct invalid data, the Distributor simply creates a new NSLS Daily transaction with valid data and re-sends this to the Retailers. vER Version 0.15 May 24July 20, 2005 Page 125 GDAR EBT STANDARDS DOCUMENT5.6 CSV TransportDefinition/Purpose The CSV Transport transaction allows the transmission of Comma Separated Value (CSV) data through the EBT infrastructure to ensure proper logging, security and archiving as required by the EBT Standards. Sending CSV files outside the EBT system using email may compromise the security of any confidential data being sent.This transaction is intended to be used temporarily to transmit data between Distributors and Retailers in reaction to situations requiring rapid changes to the EBT system while proper XML-based EBT transaction changes are developed, implemented and tested.Flow The CSV Transport transaction can be sent from Distributor to Retailer or from Retailer to Distributor. This transaction can be used for purposes that are defined and approved by the industry using the normal method of Working Group development and Working Group, Advisory Committee and OEB approval. This transaction can also be used between any pair of Retailer and Distributor market participants by their mutual definition and agreement.Data This transaction will transport CSV data in a secure manner using the EBT system. No specific uses for the CSV Transaction have been approved. When specific uses are approved, the global issue defining the use will also define the data format and conventions to be used.The CSV Transaction can also be used by any pair of Distributor and Retailer market participants by their mutual agreement. In this situation, it is up to the market participants to define the data formats and conventions to be used.For recipients of the CSV Transport transaction, it is anticipated that tools would be developed for the recipient’s spoke or point that would enable placing CSV data into a folder for manual processing. For senders of CSV Transport transactions, it is similarly anticipated that tools would be developed for the sender’s spoke or point to enable loading of CSV data into the CSV Transport transaction. In some cases, market participants may automate the processing of CSV data, and may wish to pass the CSV data to and from their CIS for that purpose.Response No response is defined at the application level for this transaction. The usual Functional Acknowledgement shall be returned at the transport level as with all transactions.Rules The CSV Transport transaction is intended to be used temporarily when new market requirements dictate that data needs to be sent between market participants during the period when proper XML-based transaction changes are being developed and vER Version 0.15 May 24July 20, 2005 Page 126 GDAR EBT STANDARDS DOCUMENT implemented. In this case, a plan to develop the proper XML-based EBT transaction changes should be documented together with the details for the CSV Transport solution. The transaction may also be used to transmit data for temporary situations where the cost of developing and implementing modifications to the XML-based transactions is not warranted. When a pair of trading partners mutually agrees to use the CSV Transport transaction for their own defined purposes, it is suggested that the GlobalIssue attribute be set to 754 for this use.TRANSACTION FLOW CSV-1: CSV TransportRETAILER HUB DISTRIBUTOR 1. CSV Transport 1. CSV Transport***There is no Application Advice to be sent for the above transactions to indicate an accept or reject of the transaction.Flow: Market Participant sends CSV Transport to the other Market Participant. No response other than Functional Acknowledgement is expected.Rules: Either Retailer or Distributor can send CSV Transport, so this process flow is bi-directional. vER Version 0.15 May 24July 20, 2005 Page 127 GDAR EBT STANDARDS DOCUMENT5.7 Application AdviceThe sections below define the definition/purpose, flow, response and business rules around implementing the Application Advice. This transaction is in response and returned by the recipient for every Meter Data, Invoice, Payment Advice and Status Advice transaction to notify the sender that the transaction was either accepted or rejected at their application level. If the transaction was accepted, no further action is needed. If the transaction is rejected, the originator of the transaction must send a corrected transaction in the case of Meter Data, Invoice or Payment Advice transactions. In the case that a Status Advice transaction is rejected, the Reject Reason provided in the AA Reject will determine the corrective action to be taken by the sender of the Status Advice.Definition/purpose This is an application level transaction that is in response to a Meter Data, Invoice, Payment Advice and/or Status Advice transaction to acknowledge whether the transaction was either accepted or rejected within the receiver’s system. For clarity, an Application Advice Reject notifies the sender of the request/notification transaction (e.g. a Usage transaction or Status Advice transaction) that the request transaction was not processed by the recipient’s system. Therefore, the underlying transaction (i.e. that referred to by the AA-R) is treated by the receiver as though that underlying transaction was never processed by the receiver.Flow The Trading Partner sends a Meter Data, Invoice, Payment Advice or Status Advice to the other Trading Partner. The originating Trading Partner will get an Application Advice for each one of the transactions that was sent. See flow AA-1 for details.Response The only response back from an Application Advice will be a Functional Acknowledgement because the Application Advice is a response transaction. Rules An Application Advice must be sent no later than two business days after each Meter Data, Invoice, Payment Advice or Status Advice transaction. Both Retailers and Distributors can send an Application Advice.Only one Application Advice transaction can be sent in response to any request (e.g. Usage or IBR) received. Where the sending party has made an error in the type of Application Advice transmitted (e.g. an AA Accept was transmitted instead of an AA Reject), the offending party must notify the receiving party of the error immediately and both Market Participants must work out a fix as mutually agreed.If an expected Application Advice transaction is not received, the receiving party who expected the Application Advice transaction, as a business rule (not an EBT Standard), should follow-up with the party who didn’t send it. The recipient of the expected Application Advice transaction should assume that the transaction generating the vER Version 0.15 May 24July 20, 2005 Page 128 GDAR EBT STANDARDS DOCUMENT expected Application Advice response was accepted until they receive the Application Advice transaction.TRANSACTION FLOW AA-1: Application Advice “Reject or Accept”1. Meter Data, 1. Meter Data, Invoice, Invoice, RETAILER Payment Advice HUB Payment DISTRIBUTOR and Status Advice and Advice Status Advice 2. Application Advice 2. Application Advice (reject/accept)Flow: 1. The Retailer will send an EBT (Meter Data, Invoice, Payment Advice or Status Advice) to the Distributor. 2. The Distributor will return to the Retailer an Application Advice (reject/accept) in response to each EBT (Meter Data, Invoice, Payment Advice or Status Advice). Rules: 1. Application Advice is sent no later than 2 business days after receipt of each Meter Data, Invoice, Payment Advice or Status Advice transaction.TRANSACTION FLOW AA-2: Application Advice “Reject or Accept”1. Meter Data, 1. Meter Data, Invoice, Invoice, Payment Payment Advice or Advice or RETAILER HUB DISTRIBUTOR Status Advice Status Advice 2. Application Advice 2. Application Advice (reject/accept) (reject/accept)Flow: 1. The Distributor will send an EBT (Meter Data, Invoice, Payment Advice or Status Advice) to the Retailer. 2. The Retailer will return to the Distributor an Application Advice (reject/accept) in response to each EBT (Meter Data, Invoice, Payment Advice or Status Advice). Rules: 1. Application Advice is sent no later than 2 business days after receipt of each Meter Data, Invoice, Payment Advice or Status Advice transaction. vER Version 0.15 May 24July 20, 2005 Page 129 GDAR EBT STANDARDS DOCUMENT5.8 Status AdviceDefinition/Purpose The Status Advice (SA) transaction is used by a Trading Partner for an informational change in status/response to an originating STR or Meter Data transaction. The SA is sent on an as needed basis. It contains contact information, effective processing dates and descriptions of status changes.Flow The Status Advice may flow from any Trading Partner to any other Trading Partner. For an example, see the flows in the STR and Meter Data sections.Data The information contained in the Status Advice includes the status codes, the reference to an Original Transaction Reference Number if appropriate, new effective date, and any contact information that may assist the recipient. Some example reasons for the Status Advice include:Contest Period Over-Lost This Status advice is sent by a Distributor to inform a losing Retailer that the 20-business day contest is now closed. The effective date field should be loaded with the date that the contest period ended. Examples of its use can be found under STR-3 and STR-4.Contest Period Over-Won This Status advice is sent by a Distributor to inform a winning Retailer that the 20- business day contest is now closed. The effective date field should be loaded with the date that the contest period ended. Examples of its use can be found under STR-3 and STR-4.Change Consumer Location This Status advice can be sent by the current Retailer to inform the Distributor that the Consumer is moving. The effective date field should be loaded with the date that the Consumer will disconnect from the old service. Examples of its use can be found under STR-21.New Effective Date This Status Advice can be sent by any party to modify a previously arranged effective date. The effective date field should be loaded with the new expected operation date for the transaction. For example, this transaction can be used to change the effective date of a meter read, power flow date, or drop date. Any scheduled date can be modified through the use of this Status Advice. Examples include STR-20, STR-22, STR-24, STR-25 (Change Consumer Location), STR-26 (Drop to SSS), and MDT-6 (Historical usage request). In the event that a Retailer should choose to consider transmitting SA-NED vER Version 0.15 May 24July 20, 2005 Page 130 GDAR EBT STANDARDS DOCUMENT transactions, a Global Item should be opened by the Working Group to outline business rules and example flows for acceptance.Notice of Pending Switch This Status Advice is sent by a Distributor to inform the current or prospective Retailer that a contest for a Consumer is starting. The date of this notice begins the 20-business day hold period also known as the contest period. The effective date field should be populated with the proposed switch date. Examples of its use can be found under STR-3 through STR-7, inclusive.Terminate Transfer Request This Status Advice can be sent by any party to terminate a previously requested activity, if allowed. For example, it can be used:  As a notice that the Consumer has informed whoever sends this Status Advice that the Consumer wants to cancel the switch request and remain with Retailer A; or  To cancel a request for enrolment before the power has begun to flow with the new Retailer.The effective date field should be loaded with the date that the original transaction was cancelled. Examples of its use can be found under STR-5, STR-6, and STR-7 (for Enrol Request), STR-20 (for Consumer Change Location), STR-28 (for drop to SSS).The Status Advice contains contact information to be used when the request comes from the Consumer and may need to be validated by the other party. It also contains contact information for resolution with specific Account Managers at the Retailer or the Distributor. Validation occurs for only the "Account Validator". Response The response back from a Status Advice will be an Application Advice. Therefore, the party receiving the SA transaction now has a means by which to acknowledge receipt of a valid transaction, or to acknowledge receipt of an invalid transaction, back to the sender of the SA. The sender of the SA transaction will now receive a positive acknowledgement that the SA has been received by the intended party, and whether the transaction is acceptable or has failed for any reason.The responsibility for identifying errors or exceptions with the processing of Status Advice transactions lies with the party who has received the transaction. Where an SA fails, either with the content of a given SA transaction, or where the SA has been sent in error, the receiver will notify the sender of the transaction using an Application Advice Reject transaction. Once the sender has been thus notified, the receiver may continue processing as if the transaction had never been received. The sender and the receiver should resolve the discrepancy in a mutually agreeable manner. vER Version 0.15 May 24July 20, 2005 Page 131 GDAR EBT STANDARDS DOCUMENTPossible Reject Reasons can be found using the reference in Appendix A, and the rules applying to Reject Reasons can be found in Section 5.0 under the heading “Technical Rules for All Transaction Sets’.Rules When the Status Advice is sent to a third party (not the originator) the original transaction number is “blocked”. This prevents the sharing of one Trading Partner’s information with another Trading Partner in a possibly inappropriate manner.Use of the Original Transaction Reference Number FieldThe Original Transaction Reference Number Field is required when the Status Advice is part of a series of transactions with a specific trading partner. The original transaction reference number must be one that the receiver can know of and associate with the Status Advice. This is an issue during contests when there are two Retailers involved, as only one of them knows of the enrol request causing the contest.The reference to the Original Transaction Reference Number must be supplied unless the Status Advice being sent is starting the transaction flow (for example, in the case of the Notice of Pending Switch sent to the current Retailer to notify of the start of a contest). In this case, there is no Original Transaction Reference Number preceding this Status Advice. Consequently, the Original Transaction Reference Number is “optional” in the schemas, even though it is “mandatory” if an Original Transaction Reference Number does exist. This conditional logic (i.e. “mandatory” if it exists, “optional” if it does not exist) cannot be expressed in the schemas in any other way than declaring the item “optional”.The table below (see Table 1) contains the complete set of Status Advice scenarios and which transaction reference number should be used as the Original Transaction Reference Number. Certain Status Advice transactions can have different Original Transaction Reference Numbers, depending upon the relationship of sender and receiver. Those transactions have multiple listings in the table. vER Version 0.15 May 24July 20, 2005 Page 132 GDAR EBT STANDARDS DOCUMENTTable 1Status Advice Situation Sender Receiver Original Transaction Reference Number document 1 New Effective Date Any time a scheduled Distributor Retailer The Transaction Reference Number of the date has to be adjusted Retailer Distributor transaction that started the sequence of events, such as the Enrol Request from the Retailer, or the Drop Request from either the Retailer or the Distributor.In a contest,  If there is a change to the date for the CPO Won for Retailer B, then the SA NED will reference the Enrol Request. If the current Retailer gets the CPO lost, the SA NED references the NPS transaction. 2 Change Consumer Notify Distributor of Current Distributor No Original Transaction Number Location Consumer’s change of Retailer location 3 Notice of Pending Notify current Retailer Distributor Current Retailer No Original Transaction Number. Switch of contest (This is the originating notification transaction for the Contest process). 4 Notice of Pending Notify prospective Distributor Prospective Retailer Transaction Reference Number of the prospective Switch Retailer of contest Retailer’s Enrol Request.5 Contest Period Over Notify current Retailer Distributor Current Retailer Notice of Pending Switch originally sent to of contest period over current Retailer. 6 Contest Period Over Notify prospective Distributor Prospective Retailer Enrol Request sent by prospective Retailer Retailer of contest period over 7 Terminate Transfer Notify current Retailer Distributor Current Retailer Notice of Pending Switch transaction originally Request of switch cancellation sent to current Retailer. 8 Terminate Transfer Notify prospective Distributor Prospective Retailer Enrol Request sent by prospective Retailer Request Retailer of switch cancellation 9 Terminate Transfer Notify Distributor of Current Distributor Notice of Pending Switch transaction originally Request cancellation of switch Retailer sent to current Retailer. 10 Terminate Transfer Notify Distributor of Prospective Distributor Enrol Request transaction sent by prospective Request cancellation of switch Retailer Retailer.11 Terminate Transfer To cancel an accepted Distributor Retailer only Transaction Number of the Change Consumer Request Change Consumer only Location Request transaction that is being Location Request rescinded. 12 Terminate Transfer To cancel a previously Retailer Distributor Only Transaction Reference Number of the SA CCL Request sent SA CCL Only 13 Terminate Transfer To cancel a Drop Distributor Retailer The Transaction number of the Drop Request Request Request Retailer Distributor Transaction 14 Terminate Transfer To cancel a previously Distributor Retailer This is not allowed. Request sent SA TTR Retailer Distributor vER Version 0.15 May 24July 20, 2005 Page 133 GDAR EBT STANDARDS DOCUMENT5.9 Functional AcknowledgementThe sections below define the definition/purpose, flow, response, and business rules around implementing the Functional Acknowledgement. Every Trading Partner and the Hubs send this transaction for every PIPE Document (which contains one or more PIP Transactions i.e.: STR, Meter Data, Invoice, Payment Advice, and Application Advice transactions) that is received by them.Purpose/DefinitionThe Functional Acknowledgement transaction is used to indicate the results of the syntactical analysis of the XML encoded PIPE document as well as validation of the Trading Partner (i.e. is this a valid trading partner). This transaction does not cover the semantic meaning of the information contained in the transaction sets. The result of the transaction is to notify the Trading Partners and the Hubs that the PIPE Document was either “accepted” or “rejected” at either the PIPE Document or PIP Transaction level due to the syntactical analysis of the document content as well as other Trading Partner validations. A PIPE Document contains one or more PIP Transactions (e.g., STR, Meter Data, Invoice, Payment Advice, and Application Advice transactions). There are three levels of the Functional Acknowledgement: A PIPE Document is “accepted” when no further action is needed. (PIPE document can contain one or more PIP transactions.)  A PIPE Document is “rejected” when the document is not readable and the sender of this document needs to resubmit the document.  A PIPE Document partial acceptance is sent when the overall PIPE Document is readable, but contains at least one rejected PIP Transaction. The partial acceptance will indicate the specific PIP transactions that are rejected with reject reasons. The partial acceptance will also indicate all PIP transactions (STR, Meter Data, Invoice, Payment Advice, and Application Advice transactions) that are accepted as well.FlowThe Functional Acknowledgement is sent by each recipient (being the Trading Partner as well as the Hubs) of a PIPE Document (PIPE document can contain one or more PIP transactions). See flow FA-1 and FA-2 for details.Data Each PIPE Document has a reference number assigned by the originator that uniquely identifies the document. The Functional Acknowledgement identifies this PIPE Document reference number on all correspondence. Also within each PIPE Document, each PIP Transaction will have a transaction reference number assigned to it as well. This number will be used in the event of a partial “accept” and/or “reject” of a Functional Acknowledgement. vER Version 0.15 May 24July 20, 2005 Page 134 GDAR EBT STANDARDS DOCUMENTIt is a requirement that participants entering the Ontario Electricity Market as of October 1, 2003 shall use a document reference number such that the sender of the document is uniquely identifiable. One possible method that could be used to achieve this requirement is to include the market participant’s OEB License Number (which is unique to that market participant) in the document reference number. Market Participant OEB License Numbers can be found using the reference in Appendix A.Rules A Functional Acknowledgement will be sent from the Hub within four business hours of receipt of the PIPE Document. A Functional Acknowledgement from the Trading Partner will be sent within one business day from the day of receipt of the original transaction. A Functional Acknowledgement is sent in response to each PIPE Document that is sent between the Trading Partner and a Hub.The originator of the Functional Acknowledgement is the entity that last received the file. Rule 1: When a Hub is required to send a Functional Acknowledgement in response to a PIPE Document, the sending Hub should fill in the sender field with sending Hub’s name, the sending Hub’s pseudo OEB-licence number and a participant type of 'hub'. Rule 2: Likewise for situations where a trading partner is sending a Functional Acknowledgement to a Hub, the originating trading partner should fill in the recipient field with the destination Hub’s name, the destination Hub’s pseudo OEB-licence number and a participant type of 'hub'.The above rules apply in the following cases:  When a Hub is sending a Functional Acknowledgement to a Spoke or Point, apply rule 1.  When a Spoke or Point is sending a Functional Acknowledgement to a Hub, apply rule 2.  When a Functional Acknowledgement is being sent from one Hub to another, apply both rules.A document reject Functional Acknowledge is used where all transactions are bad in the originating PIPE Document.The full set of rules for the Functional Acknowledgement transaction (FA) is:Accept FA: Used when all transactions are good. In Hub situations, the Hub will forward all transactions. DocReject FA: Used when the EBT PIPE Document cannot be read. In Hub situations this is also used when all transactions are bad and the Hub is forwarding none of the transactions. As much detail with respect to each transaction vER Version 0.15 May 24July 20, 2005 Page 135 GDAR EBT STANDARDS DOCUMENT is presented in the FA, including errors for each of the transactions if all failed.Partial FA: Used when there is a mix of good and bad transactions. In Hub situations, the Hub will only forward the good transactions. There are elements describing each transaction and whether it was good or failed. A Hub will remove messages that fail XML validation against the relevant schema from the EBT document before placing it in the intended recipient's mailbox. These messages will be acknowledged in a PIPEFunctionalAcknowledgement of type partialTRANSACTION FLOW FA-1: Functional Acknowledgement 1. PIPE Document TRADING HUB PARTNER 2. Functional AcknowledgementFlow: 1. The Trading Partner sends a PIPE Document (which contains one or more PIP Transactions i.e.: STR, Meter Data, Invoice, Payment Advice, and Application Advice transactions) to a Hub. 2. The Hub will send back to the Trading Partner a Functional Acknowledgement that states at which of the three levels the PIPE Document was either “accepted” or “rejected”.Rules: Trading Partners and the Hubs must send a Functional Acknowledgment for all PIPE Documents that are received. vER Version 0.15 May 24July 20, 2005 Page 136 GDAR EBT STANDARDS DOCUMENTTRANSACTION FLOW FA-2: Functional Acknowledgement 1. PIPE DocumentTRADING HUB PARTNER 2. Functional AcknowledgementFlow: 1. A Hub sends a PIPE Document (which contains one or more PIP Transactions i.e.: STR, Meter Data, Invoice, Payment Advice, and Application Advice transactions) to the Trading Partner. 2. The Trading Partner will send back to the Hub a Functional Acknowledgement that states at which of the three levels the PIPE Document was either “accepted” or “rejected”.Rules: Trading Partners and the Hubs must send a Functional Acknowledgment for all PIPE Documents that are received. vER Version 0.15 May 24July 20, 2005 Page 137 Appendix AService Transaction Lead Times GDAR EBT STANDARDS DOCUMENTEnro l1. The effective date of an Enrol Request Transaction (that is, the date the gas will flow with the Vendor of Record) will be the first of a month. (Exceptions will be rare, but may be negotiated between the parties outside the EBT system.)2. The Enrol Request Transaction must be submitted at least 45 calendar days prior to the effective date to guarantee Vendor supply on the stated effective date, or such lesser amount of time as agreed by the Distributor. Distributors able to process an Enrol Request Transaction with less lead time as of September 6, 2005 should continue their current practice.3. The Enrol Request Transaction may not be submitted earlier than 120 calendar days prior to the effective date.4. The Enrol Request Transaction must be responded to by the Distributor with an Enrol Response (Enrol Accept, or an Enrol Reject with the applicable reason code) within 7 calendar days.5. The Enrol Request Transaction is considered pending from the time it is received by the Distributor (whether or not an Enrol Response has been sent) until the specified effective date.6. There can be only one Enrol Request Transaction pending at any point in time; therefore, if an Enrol Request Transaction is pending, any subsequent Enrol Request Transaction will be rejected (with the applicable reason code).7. The Enrol Request Transaction may not be cancelled within 15 calendar days of the effective date, or such lesser amount of time as agreed by the Distributor. Distributors able to process an Enrol Cancel Transaction with less lead time as of September 6, 2005 should continue their current practice.DropNOTE: Need to determine whether the transaction lead times are different for a Consumer-initiated drop vs a Vendor-initiated drop.1. The effective date of a Drop Request Transaction (that is, the date the gas flow with the Vendor of Record will cease, and the Consumer will return to System Gas) will be the first of a month. (Exceptions, including time and data transfer, may be negotiated between the parties.)2. The Drop Request Transaction must be submitted at least 15 calendar days prior to the effective date to guarantee return to System Gas on the stated effective date, or such lesser amount of time as agreed by the Distributor. vER Version 0.15 May 24July 20, 2005 Page 139 GDAR EBT STANDARDS DOCUMENTDistributors able to process a Drop Request Transaction with less lead time as of September 6, 2005 should continue their current practice.3. The Drop Request Transaction may not be submitted earlier than 120 calendar days prior to the effective date.4. The Drop Request Transaction must be responded to by the Distributor with a Drop Response (Drop Accept, or a Drop Reject with the applicable reason code) within 7 calendar days.5. The Drop Request Transaction may not be cancelled within 15 calendar days of the effective date, or such lesser amount of time as agreed by the Distributor. Distributors able to process a Drop Cancel Transaction with less lead time as of September 6, 2005 should continue their current practice. (NOTE: Union agreed to consider whether they were able to meet the Enbridge lead time of 3 calendar days.)SwitchBrenda will provide lead times for this Service Transaction Request.If Vendor A is the Vendor of Record on the effective date of an Enrol Transaction Request submitted by Vendor B, a potential Vendor to Vendor Switch is created, and the transfer process is subjected to a Contest Period of 30 calendar days. The switch is effected through an Enrol Transaction Request and a Drop Transaction Request. The Service Transaction Lead Time for the Enrol Transaction Request in the case where switch may occur is therefore increased by the Contest Period. vER Version 0.15 May 24July 20, 2005 Page 140 </div> <div class="ft-cover"> <a href="#" id="scrollLink"> Load more</a> </div> </div> </div> </div> </div> </div> <div class="about-item" data-tab-item="article"> <div class="article-container" id="loader"></div> <div class="load-content flex-column-center"> </div> <div id="downTop"> <div class="reader-tools-bar"> <div class="tools flex-justify"> <a href="javascript:void(0);" title="previous page" class="tools-prev flex-justify"> </a> <input type="text" class="page-cur" value="1" /> 140 <a href="javascript:void(0);" title="next page" class="tools-next flex-justify"></a> </div> <div class="bar-download"> <a href="javascript:;" id="copyLink"> Copy Link</a> </div> </div> </div> </div> </div> </div> </article> <section class="recommend"> <div class="panel-box"> <div class="panel-success"> <div class="panel-heading"> <div class="panel-flex"> <div class="panel-left"> Recommended publications </div> </div> </div> <div class="panel-body"> <ul class="panel-body-ul"> </ul> </div> </div> </div> </section> </div> <div class="rw-right row-pd" id="side-right"> <aside class="side" id="side-list"> <div class="side-download"> <a href="/download/13850094/ontario-ebt-standards-document" class="side-load-a flex-justify" title="Download"> Download </a> </div> <div class="side-tag"> <ul class="side-tag-ul"> <li><a href="javascript:;" data-tab-target="featured" class="active">Featured</a></li> <li><a href="javascript:;" data-tab-target="last" class="">Last Commenis</a> </li> <li><a href="javascript:;" data-tab-target="popular" class="">Popular</a></li> </ul> <div class="tab-items"> <div class="tab-item active" data-tab-item="featured"> <ul> <li><a href="/doc/13850093/a-the-problem-of-discrimination-review-of-legislation">A. the Problem of Discrimination; Review of Legislation</a></li> <li><a href="/doc/13850092/adoption-info-paper">Adoption Info Paper</a></li> <li><a href="/doc/13850091/dept-of-vet-public-health-meat-hygiene-division">Dept. of Vet. Public Health/ Meat Hygiene Division</a></li> <li><a href="/doc/13850090/how-zara-grew-into-the-world-s-largest-fashion-retailer">How Zara Grew Into the World S Largest Fashion Retailer</a></li> <li><a href="/doc/13850089/114-gifted-education-pg-4">114. GIFTED EDUCATION - Pg. 4</a></li> <li><a href="/doc/13850088/reading-comprehension-s2">Reading Comprehension s2</a></li> </ul> </div> <div class="tab-item" data-tab-item="last"> <ul> <li><a href="/doc/13850087/this-electronic-data-interchange-agreement-the-agreement-is-made-as-of">THIS ELECTRONIC DATA INTERCHANGE AGREEMENT ( the Agreement ) Is Made As Of</a></li> <li><a href="/doc/13850086/songs-of-hope-project-participant-application">Songs of Hope Project - Participant Application</a></li> <li><a href="/doc/13850085/revised-proposal-for-inclusion-of-thea-2423-dramatic-analysis-in-the-new-msu-core-curriculum">Revised Proposal for Inclusion of THEA 2423 Dramatic Analysis in the New MSU Core Curriculum</a></li> <li><a href="/doc/13850084/cobb-county-school-district-s4">Cobb County School District s4</a></li> <li><a href="/doc/13850083/Conference-Title-Presentation-on-Myanmar">Conference Title: Presentation on Myanmar</a></li> <li><a href="/doc/13850082/pike-county-local-foods-coalition-meeting">Pike County Local Foods Coalition Meeting</a></li> </ul> </div> <div class="tab-item" data-tab-item="popular"> <ul> </ul> </div> </div> </div> <div class="adspace"> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-8519364510543070" data-ad-slot="2167091933" data-ad-format="auto"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> <div class="side-message"> <ul> </ul> </div> </aside> </div> </div> </div> </main> <script> var totalPage = 140; var dId = 13850094; var docId = '75024b62d3fffd3530897b85da66c65b'; </script> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script> <script src="/js/article.js"></script> <footer> <div class="container-fluid"> <a href="#Top" data-toggle="tooltip" data-original-title="TO TOP"> </a> © 2024 Docslib.org <a href="/help/feedback">Feedback</a> </div> </footer> <script> $(".nav-menu").click(function () { $(".menu-list").toggle(); }); </script> <script type="text/javascript"> var sc_project = 11552861; var sc_invisible = 1; var sc_security = "b956b151"; </script> <script type="text/javascript" src="https://www.statcounter.com/counter/counter.js" async></script> </body> </html>