north american energy standards board · 2019-09-30 · home page: _____ req/rgq business practices...

NORTH AMERICAN ENERGY STANDARDS BOARD

Executive Committee Meeting – WEQ, REQ, RGQ, WGQ Meeting Materials August 23-25, 2005

Retail Quadrants

TAB 10

Retail Subcommittee Updates

• The information provided in Tab 10 is for information, discussion and review. No direct action is requested of the retail ECs at this time. Should in the discussion, it be determined that a specific action is needed that would require an EC vote, it would be a simple majority vote of each quadrant.

• For the Business Practices Subcommittee, included are a July letter from Dan Jones and the May and June minutes.

• For the Information Requirements Subcommittee, included are minutes from June and July.

• For the Technical Electronic Implementation Subcommittee, included are minutes from May, June and July.

• For the Glossary Subcommittee, included is the August, July and June work papers,

• For the Contracts Subcommittee, no meetings have been held yet.

• There have been no actions taken by the Glossary Subcommittee or Standards Review Subcommittee since the last EC meeting in May.

• The materials in Tab 10 correspond to agenda item 3 for the Retail ECs agenda.

Adobe Page 260 of 571

Meeting Announcement Letter from Dan Jones Dear REQ/RGQ Business Practices Subcommittee Participants: Documents have been posted on the REQ/RGQ Business Practices Subcommittee web site for the July 26th and 27th, 2005 meeting in Baltimore, Maryland. The documents posted will be used at the meeting as follows: # 1C - Definitions Approved by the Glossary Subcommittee - Definitions for Customer Information Set, Customer-specific Information Request, Mass Customer List, and Validation Elements were approved at the July 18th meeting of the Glossary Subcommittee. We will review these definitions and incorporate them into the Customer Information MBP. # 2C - Proposed Executive Summary and Introduction - We will review/revise this document and incorporate it into the Customer Information MBP. # 3C - Latest Customer Information MBP Working Document - We will incorporate documents # 1C and # 2C into this document and will make any other necessary revisions to bring this document to a balanced vote. # 4C - TIBP For Billing and Payment - Rick Alston and/or George Behr will review this document with us and raise associated issues that should be addressed by BPS. # 5C - First Draft - Customer Enrollment, Switching, and Dropping - This is the document Ed Ogletree prepared from the UBP document on these topics. This document has been posted for our last two meetings but has not been discussed. # 6C - Second Draft - Customer Enrollment, Switching, and Dropping - This is a document I have prepared which includes most sections in Ed Ogletree's document and has additional sections which address specific enrollment, switching, dropping, and information change scenarios. I have not completed this document, but we might want to consider this as a template for developing additional MBPs on these topics. I have incorporated scenarios described in the Ohio Electric Choice EDI Guidelines (Document # 7C). # 7C - EDI Guideline Example - This document is the Ohio Electric Choice EDI Guidelines. The scenarios described for enrollment, switching, dropping, and information changes are very closely aligned with the MBP we are developing. The examples shown through page 17 are related to our current task. I have also posted three new documents under the Business Practices Subcommittee Reference Document Link. These are examples of EDI transactions for Enrollments, Drops, and Changes. The eamples give EDI details, but what will help us is the right hand side of each page where the business information included in the EDI string is described in layperson's terms. I look forward to seeing all of you on July 26th! Sincerely, Dan Jones REQ Co-chair, BPS

Adobe 61 of 571

North American Energy Standards Board

1301 Fannin, Suite 2350, Houston, Texas 77002 Phone: (713) 356-0060, Fax: (713) 356-0067, E-mail: [email protected]

Home Page: www.naesb.org

____________________________________________________________________________________________ REQ/RGQ Business Practices Subcommittee Meeting Minutes – June 30, 2005

Page 1

TO: REQ/RGQ BPS members, Posting for Other Interested Industry Participants

FROM: Todd Oncken, NAESB Deputy Director

RE: REQ/RGQ BPS Conference Call Draft Minutes - June 30, 2005

DATE: July 13, 2005 North American Energy Standards Board

REQ/RGQ Joint Business Practices Subcommittee (BPS) Conference Call with web conferencing

Thursday, June 30, 2005; 9:00 a.m. to 3:00 p.m. Central Draft Minutes

1. Administrative

Mr. Jones called the meeting to order and welcomed participants. Mr. Oncken gave the antitrust advice. Participants introduced themselves. Mr. Jones reviewed the draft agenda. Mr. Barkas moved, seconded by Ms. Edwards, to adopt the agenda as drafted. The motion passed unanimously.

The draft minutes from May 24-25, 2005 were reviewed and minor changes were offered by Ms. McCain. Mr. Eynon moved, seconded by Ms. Allen, to adopt the revised draft minutes. The motion passed unanimously.

2. Discussion on 2005 Annual Plan Item No. 3 – Customer Information

Develop recommended definitions for the consideration of the Glossary Subcommittee: Work paper #3B Proposed Definitions for Defined Terms in the Customer Information MBP. The subcommittee worked on the following definitions (to be forwarded to the RXQ Glossary Subcommittee): Pre-Enrollment Customer Specific Information Request; Customer Information Set; Validation Elements; and Mass Customer List. The revised definitions are shown in attachment 2 to these minutes. The subcommittee made several changes to the proposed definitions, and all changes are reflected in redline in the attachment.

Develop Model Business Practices for customer specific information requests and mass customer lists: Work papers #1B The Latest Working Document for Customer Information; #2B Proposed Changes to Barbara Alexander's Comments; Redline Comments from Southern Company; Mass Customer List 6/30/05.

The subcommittee worked through each of the redlines offered in the comments submitted by Southern Company and adopted those comments where appropriate. Additionally, participants raised additional comments on other sections that were also incorporated. The revised draft Customer Information MBPs are shown in attachment 1 to these minutes. Ms. Edwards volunteered to draft an Executive Summary and Introduction for the subcommittee to review during its next meeting.

In addition to the proposed language changes, the comments submitted by Southern Company contained several questions. The subcommittee’s response to those questions is shown below:

• RXQ.5.1.3: The utilities and suppliers language was deleted as the result of discussion during the previous meeting.

• RXQ.5.2: Each defined term will be included in the MBPs at publication. However, only the new terms being defined for this MBP will be included in the recommendation






Page 2

to the Executive Committees.

• RXQ.5.3.1: Customer Authorization Process is not a defined term, but should be capitalized because it is the title of a section.

• RXQ.5.3.2.1: This section does not limit an organization’s ability to not use Uniform Electronic Transactions, but does indicate that the transmittal media should match (i.e., a UET request gets a UET response).

There was significant effort spent developing the inclusive list contained in proposed MBP 5.3.2.5. Mr. Jones stated the proposed MBP models the response sent when a supplier makes a request for the 12-month usage history on a particular account (currently the 867 HU). During discussion it was noted that the pieces of information transmitted were different in different jurisdictions, and determined it would be a better solution to make an inclusive list of items that could be included. It was noted that the sub-bullets indicated the information would be provided on the meter level instead of the account level. Mr. Barkas suggested including telephone number in the proposed MBP, but the subcommittee did not include the reference.

When working on proposed MBP RXQ.5.3.3, Mass Customer Lists, the subcommittee incorporated the changes discussed at the last meeting as reflected in work paper #2B Proposed Changes to Barbara Alexander's Comments. Additionally, the subcommittee discussed the proposed additional MBPs submitted by Mr. Jones in the Mass Customer List 6/30/05 work paper. Mr. Wolf noted that the subcommittee should consider whether the proposed MBPs would work for both “opt-in” and “opt-out” states, and suggested that modifications should be made if the intention was that it apply to both types. If the MBPs are intended to be applicable to only “opt-out” states, the MBPs should note that applicability.

3. Continue discussion on Customer Information

See discussion above.

4. Discussion on 2005 Annual Plan Item No. 4 – Customer Enrollment, Switching & Dropping

This item was not discussed.

5. Next Steps

Arrangements for the REQ/RGQ BPS meeting in Baltimore on July 26-27: The meeting arrangements were discussed and are available for download from the NAESB web site.

Future meeting schedule: No additional meetings were scheduled at this time.

6. Adjourn

The conference call adjourned at 3:35 p.m. Central.






Page 3

7. Attendance

Name Organization Quadrant

Barbara Alexander State of Maine Public Advocate REQ

Eartha Allen Gulf Power Company REQ

Bill Barkas Dominion Retail REQ

Osman Bholat Savannah Electric REQ

Mary Edwards Dominion VA Power REQ

Patrick Eynon Ameren REQ

Dan Jones Cinergy REQ

Todd Oncken NAESB

Angela Thomason NAESB

Bill Wolf Baltimore Gas & Electric REQ





____________________________________________________________________________________________ BPS Meeting FinalMinutes May 24-25, 2005

Page 1

TO: REQ/RGQ BPS members, Posting for Other Interested Industry Participants


RE: REQ/RGQ BPS Meeting Final Minutes - May 24-25, 2005

DATE: June 10, 2005 NORTH AMERICAN ENERGY STANDARDS BOARD

REQ/RGQ Joint Business Practices Subcommittee (BPS) Meeting May 24-25, 2005; Houston, TX hosted by NAESB

FINAL MINUTES

1. Administrative

Mr. Jones called the meeting to order and welcomed attendees. Mr. Oncken gave the antitrust advice. Participants introduced themselves. The draft agenda was reviewed and the following modifications were made: 1) add a section for opening remarks under agenda item 1; and 2) rearrange the agenda on day two so that discussion on Customer Information would occur first but the original time allocation would be unchanged. Mr. Precht moved, seconded by Mr. Wolf, to adopt the agenda as modified. The motion passed unanimously. [The numbering schema used in these minutes correlates to the order in which agenda items were addressed, not the original numbering of the agenda.]

The draft minutes from April 13-14, 2005 were reviewed and grammatical edits were offered. Ms. Edwards moved, seconded by Mr. Ledford, to adopt the revised draft minutes. The motion passed unanimously.

Opening Remarks: Mr. Precht provided an update on the RXQ publication and procedures for explanatory changes to the publications in light of the May 10 Executive Committee meetings. Mr. Precht stated changes to the explanatory material (such as introduction and executive summary sections) of the publication did not have to go through the ratification process. He added that it was decided the BPS should finish its work on the introductions and executive summaries so the Executive Committees could approve the language and publication could proceed. Additionally, he noted it was decided that an additional book should be created, RXQ Book 6 – Contracts, to house the Trading Partner Agreement and the model agreements contained in the other model business practices. He added that relocation of the agreements and outlines was not a substantive change, so it could be accomplished administratively by the NAESB Office.

2. Discussion on R05008 – Dominion Virginia Power Request

Workpapers posted: (1A) Request R05008; (2A) December 6, 2004 CPS Redlined Workpaper; (3A) Latest Billing & Payment MBP approved by BPS on April 13, 2005.

Ms. Edwards led discussion on Request R05008. Significant discussion was based on workpaper 2A, since the majority of the request was finishing work that had been begun by the CPS. Each of the proposed modifications that were not addressed through Recommendation R04034 (Cinergy Request) was discussed, as shown below.

Proposed MBP RXQ.3.3.1.9: Mr. Ledford expressed concern that the proposed MBP would not be adequate if two payments were received on the same day. There was significant discussion on this issue. Ms. McCain suggested that was an issue better suited for the technical implementation rather than the business MBPs. After discussion it was determined not to add the proposed MBP, but Ms. Edwards agreed to follow up with Mr. Alston, former co-chair of the






Page 2

CPS, to see if he could provide additional information on why it was proposed.

Proposed MBP RXQ.3.3.1.10 - Proposed MBP RXQ.3.3.1.12: This group of proposed MBP addresses procedures for rejecting certain meter data. The applicability of the concept, and how it is currently implemented, were discussed. Participants agreed that parties should have the right to reject data for numerous reasons, and should send a rejection notice to the provider of that data. The three proposed MBPs were combined into one MBP (new Proposed MBP RXQ.3.3.1.10), and the following language was developed:

After a receiving party examines a Uniform Electronic Transaction and determines that it contains invalid information, the Uniform Electronic Transaction should be rejected by the receiving party. Rejection, accompanied by appropriate uniform error code(s), should be communicated via the appropriate Uniform Electronic Transaction within one (1) Business Day of receipt of the file.

Proposed MBP RXQ.3.3.1.13: After discussion it was determined not to add the proposed MBP.

Proposed MBP RXQ.3.3.1.14: The proposed MBP addressed the timing of acknowledgment of receipt of an electronic file. Modifications were made to make the language more broad, and the language for new Proposed MBP RXQ.3.3.1.9 reads as follows:

Upon receipt of a file via Uniform Electronic Transaction, the receiving party should acknowledge receipt of the file via Uniform Electronic Transaction within one (1) Business Day.

Modify all references to meter reading and meter usage data to usage data: Each reference to meter reading and meter usage data was reviewed and appropriate changes were made.

For the RGQ, Ms. McCain moved, seconded by Mr. Zollars, to approve the modifications made to the RXQ Billing and Payments MBPs on May 24, 2005 and forward the revised MBPs to the RXQ Information Requirements (IR) Subcommittee, as follows: new MBP RXQ.3.3.1.9, RXQ.3.3.1.10; changes in the following MBPs related to the terminology for usage data 3.3.2.3, 3.3.2.4, 3.3.6.2, 3.3.6.3, 3.3.6.4; and the striking of the Billing Services Agreement outline from the models section. The motion passed unanimously.

For the REQ, Ms. Edwards moved, seconded by Mr. Wolf, to approve the modifications made to the RXQ Billing and Payments MBPs on May 24, 2005 and forward the revised MBPs to the RXQ IR Subcommittee, as follows: new MBP RXQ.3.3.1.9, RXQ.3.3.1.10; changes in the following MBPs related to the terminology for usage data 3.3.2.3, 3.3.2.4, 3.3.6.2, 3.3.6.3, 3.3.6.4; and the striking of the Billing Services Agreement outline from the models section. The motion passed unanimously.

3. Recess for the day

Day one recessed at 4:00 p.m. Central.

4. Administrative

The chair noted that the antitrust guidelines discussed on day one are still in effect. The subcommittee addressed the remaining agenda items on day two, with the discussion on Customer Information occurring first (see discussion above).

5. Discussion on 2005 Annual Plan Item No. 3 – Customer Information

Workpaper posted: (15A) Customer Information MBP workpaper from April 14 meeting; Comments Submitted by Barbara Alexander.






Page 3

Ms. Alexander submitted comments that pertain to the discussion on Customer Information MBPs at the previous RXQ BPS meeting. Each of the points made in Ms. Alexander’s comments were discussed by the subcommittee, and many of the proposed changes were incorporated into the revised draft. During discussion it was noted that terms to be defined should be identified and forwarded to the RXQ Glossary Subcommittee.

RXQ.5.3.1 - Customer Authorization Process: Ms. Alexander commented that the word ‘verifiable’ in proposed MBP RXQ.5.3.1.1 and RXQ.5.3.1.3 was confusing, so the reference was deleted. Ms. Alexander noted that these proposed MBPs did not discuss the exchange of data. Ms. Edwards and Mr. Wolf opposed automating the customer authorization process. An open question is whether there should be a different method for customer authorization for each of the models.

RXQ.5.3.2 - Pre-Enrollment Customer Specific Information Requests: It was determined to define the terms “Pre-Enrollment Customer Specific Information Request” and “Validation Element.” Regarding proposed MBP RXQ.5.3.2.1, it was determined that if a request was sent via Uniform Electronic Transaction, then the response should be sent via Uniform Electronic Transaction. The subcommittee did not decide whether a request should be sent via Uniform Electronic Transaction. In addition to the conforming and grammatical changes made in proposed MBP RXQ.5.3.2.2, the second sentence discussing response times for exceptions was deleted.

There was significant discussion on validation elements and the treatment of an invalid customer information request. Discussion revealed that validation elements are different in different jurisdictions. Mr. Wolf noted that the proposed MBPs do not state that a response of invalid should generate a rejection. The subcommittee developed replacement language for proposed MBP RXQ.5.3.2.4 that defines the minimum and allowable secondary validation elements.

Subcommittee members took the homework assignment of developing a proposed customer information set that combines the elements in proposed MBP RXQ.5.3.2.5 and RXQ.5.3.2.5. It was suggested that participants use the 867-HU as a starting point.

RXQ.5.3.3 - Mass Customer Lists: Ms. Alexander generally introduced her comments, but discussion was deferred until the next meeting. Ms. Edwards noted that sometimes both mass lists and Uniform Electronic Transactions are used, and while they many contain the same information, each has its own specific list of elements.

6. Review Market Participant Interactions MBP

Workpapers posted: (4A) MBP Numbering Format – BGE document from March 9, 2005; (5A) Reformatted Master List of Ratified Defined Terms; (6A) Ratified Market Participant Interactions MBP – original numbering; (7A) Reformatted, Ratified Market Participant Interactions MBP; (8A) Proposed Executive Summary and Introduction for MPI MBP.

Ms. Edwards reviewed the workpaper containing the proposed Executive Summary and Introduction for the Market Participant Interactions MBPs. She explained the proposed language was based on the language the subcommittee had developed for the Billing and Payments MBPs at its last meeting. She noted the proposed language would replace the current language in each of the sections, and would also delete the ‘overview’ section. There were additional edits to the proposed language. The final language is attached to these minutes. During discussion it was noted that when “model business practices” is used as a generic term it should not be capitalized, except when it is included in a title.






Page 4

After the language was agreed upon, the subcommittee reviewed the numbering of the MBPs. There was extended discussion on how the numbering scheme should be applied to principles and definitions, since those areas do not lend themselves to 4-digit numbering. It was decided that principles and definitions should be assigned 3-digit numbers. The numbering example maintained by Mr. Precht should be modified accordingly. Additionally, it was proposed that the models section of each MBP contain a table indicating the location and number of applicable models.

7. Review Creditworthiness MBP

Workpapers posted: (9A) Ratified Creditworthiness MBP – original numbering; (10A) Reformatted, Ratified Creditworthiness MBP; (11A) Proposed Executive Summary & Introduction for Creditworthiness MBP.

Ms. Edwards reviewed the workpaper containing the proposed Executive Summary and Introduction for the Creditworthiness MBPs. There was significant discussion regarding whether the proposed Executive Summary should be made more general (ie. changing the references to creditor and applicant). Mr. Newbold stated the intent of the subcommittee while drafting the MBPs was the relationship between a regulated utility and a non-regulated supplier. Mr. Ledford stated that the MBPs would not work in all instances, particularly since his organization groups third party suppliers with BGS auction winners in default situations since load is not being served. However, Mr. Ledford noted that his concerns were addressed since the intention of the MBP was between distribution companies and suppliers. Mr. Ledford will consider whether the MBP should be modified, and if so, will draft a request to modify the MBP. There were additional edits to the proposed language. The final language is attached to these minutes.

8. Review Distribution Company – Supplier Disputes MBP

Workpapers posted: (12A) Ratified Distrib. Company – Supplier Disputes MBP – original numbering; (13A) Reformatted, Ratified Distribution Company – Supplier Disputes MBP; (14A) Proposed Executive Summary & Introduction for Disputes MBP.

Ms. Edwards reviewed the workpaper containing the proposed Executive Summary and Introduction for the Distribution Company – Supplier Disputes MBPs. There were additional edits to the proposed language. The final language is attached to these minutes.

9. Continue discussion on Customer Information

RXQ.5.3.3 - Mass Customer Lists (continued): After the subcommittee finished the other agenda items, it continued discussion on the Customer Information MBPs. It was determined that a definition should be developed for “Mass Customer List.” The subcommittee reviewed Ms. Alexander’s comments on proposed MBP RXQ.5.3.3.1 and drafted alternate language. The alternate language is shown in the attachment.

10. Discussion on 2005 Annual Plan Item No. 4 – Customer Enrollment, Switching & Dropping

Workpaper posted: (16A) Draft MBP – Reformatted UBP document.

This item was not discussed.






Page 5

11. Next Steps

Future meeting schedule:

• June 30, 2005 – conference call with web – 9:00 a.m. to 3:00 p.m. Central • July 27-28, 2005 – meeting in Baltimore, MD • September 1, 2005 - conference call with web – 9:00 a.m. to 3:00 p.m. Central • September 29, 2005 - conference call with web – 9:00 a.m. to 3:00 p.m. Central • November 1-2, 2005 – meeting – location TBD • December 7, 2005 - conference call with web – 9:00 a.m. to 3:00 p.m. Central

12. Adjourn

The meeting adjourned on day two at 3:25 p.m. Central.

13. Attendance

Name Organization Quadrant/Segment

Day 1 Day 2 Vote?

Barbara Alexander Maine Public Advocate REQ/E Phone Phone Y

Eartha Allen Gulf Power Company REQ/D Phone

Bill Barkas Dominion Retail REQ/SU Phone Phone

Yvette Camp Southern Company REQ/D Phone Phone

Mary Edwards Dominion VA Power REQ/D In Person In Person Y

Patrick Eynon Ameren REQ/D Phone Y

Dan Jones Cinergy REQ/D In Person In Person Y

Calvin Ledford PSE&G REQ/D In Person In Person Y

Marcy McCain Duke Energy Gas Transmission

RGQ/SU In Person Phone Y

Bill Newbold Detroit Edison REQ/D Phone Phone Y

Todd Oncken NAESB NA In Person In Person

Phil Precht BGE RGQ/D Phone Y

Denise Rager NAESB NA In Person

Judy Ray Alabama Power Co. REQ/D Phone Phone Y

Ken Thiry Wisconsin Public Service

REQ/D Phone Y

Angela Thomason NAESB NA In Person

Bill Wolf BGE REQ/D In Person In Person Y

Richard Zollars Dominion Retail RGQ/D Phone Y





REQ/RGQ Information Requirements Subcommittee Meeting – June 7, 2005 Page 1 of 3

June 2, 2005

TO: NAESB Retail Gas Quadrant (RGQ) and Retail Electric Quadrant (REQ) Information Requirements Subcommittee (IR) Participants and Interested Parties


RE: REQ/RGQ Information Requirements Subcommittee Meeting Minutes - June 7, 2005

DATE: July 5, 2005

NORTH AMERICAN ENERGY STANDARDS BOARD REQ/RGQ Information Requirements Subcommittee Meeting

June 7, 2005 – 10:00 a.m. to 4:00 p.m. Eastern Hosted by Old Dominion Electric Coop - Richmond, VA

Final Minutes

1. Welcome & Administration

Mr. Alston called the meeting to order and welcomed participants. Mr. Oncken gave the antitrust advice. Participants introduced themselves. Mr. Alston reviewed the draft agenda and the order of the items was changed. Approval of the January 6 and May 5 draft minutes was deferred until the next meeting. Mr. Behr moved, seconded by Ms. Wise, to adopt the agenda as modified. The motion passed unanimously.

2. Review IR work done on MBP to date

Mr. Behr reviewed the current work paper to familiarize participants with the deliverable of the subcommittee, which include: the technical implementation, sample paper transaction, additional work on the data dictionary, and defining the code value dictionaries. Mr. Behr noted that the work on Billing and Payments is approximately 90 percent complete, since a significant amount of work was completed by the TEIS before the IR was created.

3. Review Model Business Practices

Determine technical portions that require further development: The IR worked from the Billing and Payment (RXQ BPS 5/24/05) work paper. Ms. Edwards discussed the changes the RXQ Business Practices Subcommittee (BPS) made to the Billing and Payments MBPs since the last IR meeting, and each change was reviewed to determine whether changes to the technical MBPs should be made. During discussion on proposed MBP RXQ.3.3.1.10, it was noted that the subcommittee would have to determine how to send a notice of reject when flat files are used, because sending electronic notifications is not a common practice when flat files are used.

4. Edit and approve to forward to TEIS

Edit and approve to forward to TEIS: Each section of the draft technical MBPs for Billing and Payments was reviewed. It was noted that the references to the specific Billing and Payments MBPs should be updated since the MBPs have been renumbered. Mr. Behr suggested that inclusion of UET in the MBPs should alert the IR that potential development could be required. Discussion of each section is noted below.

Billing Usage: It was decided that the term ‘usage’ should be used consistently in the TIBP, instead of ‘load’. It was also determined that data elements should not be included in the definitions of defined terms. Mr. Rothfuss and Ms. Wise volunteered to review the sample paper transactions to verify their accuracy.






In terms of work flow, Mr. Behr stated the RXQ BPS should begin the work on the data dictionary – supplying values for item, number, name, description, and condition. Next the RXQ IR would build on the RXQ BPS work and apply the X12 mapping. He added that the RXQ IR should make sure the end result works with the existing markets and should be grouped in logical order.

It was determined that the value in column one should be deleted and the final data dictionary should be organized alphabetically. The subcommittee reviewed each of the data elements and made appropriate changes. Changes are reflected in the attachment to these minutes. The code values dictionary should be built for each of the areas of the TIBP. Assignment of work is also noted in the attachment to these minutes.

Invoice For Cons. Billing Bill-Ready (CBBR): During discussion Ms. Wise noted the MBPs do not discuss ‘reversals’ and ‘reissues’ of invoices. After Ms. Wise’s description of reversals and reissues, Mr. Rothfuss suggested that ‘cancels’ and ‘rebills’ could serve the same purpose. Ms. Wise stated that using cancels/rebills would not work in detail in her state’s market. There was extensive discussion on the methods in which invoices are currently transmitted. Ms. Wise will probably submit a Request for Standards to include RXQ Billing and Payments MBPs for reversals/reissues. There were no changes to the data dictionary. Mr. Rothfuss and Ms. Wise volunteered to review the sample paper transactions to verify their accuracy.

Invoice For Cons. Billing Rate Ready (CBRR): This was discussed in detail and changes were made to the explanatory language. Mr. Rothfuss and Ms. Wise volunteered to review the sample paper transactions to verify their accuracy.

Payment: Mr. Rothfuss and Ms. Wise volunteered to review the sample paper transactions to verify their accuracy. There were no open items in the data dictionary. Work will continue on the code values table.

Termination of Billing Services: Mr. Rothfuss and Ms. Wise volunteered to review the sample paper transactions to verify their accuracy. There were no open items in the data dictionary. Work will continue on the code values table.

Application Advice: During discussion it was noted that the MBPs did not provide for an ‘Invoice Success’ transmittal, as indicated in the TIBP, so information related to invoice success was deleted. Since this would be a valuable practice, it is anticipated that a Request for Standards will be filed on this issue. Mr. Rothfuss and Ms. Wise volunteered to review the sample paper transactions to verify their accuracy.

Ms. Edwards, Mr. Dodson and Mr. Behr will complete a final read-through of the RXQ Billing and Payments MBPs to verify that the IR has addressed all issues needing attention.

The subcommittee discussed how to accommodate flat files in the technical implementation of the MBPs. Mr. Behr noted that there were several approaches for the contents of the flat files, including some cases where usage and invoice data is transmitted together. After extended discussion it was determined that a more efficient practice would be to post separate files, because presumably there would be fewer costs associated with separate files. This was just an item for discussion – no vote was taken. The subcommittee struggled with the format and content of flat files, and their desirability and usefulness. An additional issue was the treatment of duplicated data elements. It was noted that the WGQ created its flat file formats by duplicating the EDI standards. The subcommittee will investigate creating flat files out of the data elements at a future meeting.






Mr. Behr moved, seconded by Mr. Rothfuss, to forward the IR’s work on RXQ Billing and Payments MBPs to TEIS for further processing. During discussion it was noted that the work would be done subject to additional editing as noted above. The motion passed unanimously.

5. Next Steps/Other Business

The next IR meeting was scheduled for July 11 from 9:00 a.m. to noon Eastern in Richmond, VA (host to be determined.)

6. Adjourn

The meeting adjourn at 2:48 p.m. Eastern.

7. Attendance

Name Organization Comments

Rick Alston Old Dominion Electric Coop. In Person

Bill Barkas Dominion Retail Phone

George Behr Energy Services Group In Person

Bill Brooks PEPCO In Person

Greg Dodson Dominion In Person

Mary Edwards Dominion In Person

Todd Oncken NAESB Phone

Dan Rothfuss Cinergy In Person

Ken Thiry Wisconsin Public Service Phone

Barbara Wise Baltimore Gas & Electric In Person

Richard Zollars Dominion Retail Phone





REQ/RGQ Information Requirements Subcommittee Meeting – July 11, 2005 Page 1 of 2

July 21, 2005

TO: NAESB Retail Gas Quadrant (RGQ) and Retail Electric Quadrant (REQ) Information Requirements Subcommittee (IR) Participants and Interested Parties

FROM: Todd Oncken, Deputy Director

RE: REQ/RGQ Information Requirements Subcommittee Meeting Minutes – July 11, 2005

DATE: July 21, 2005 NORTH AMERICAN ENERGY STANDARDS BOARD

REQ/RGQ Information Requirements Subcommittee Meeting July 11th – 9:00 a.m. to noon Eastern in Richmond, VA

DRAFT MINUTES


Mr. Behr called the meeting to order and welcomed participants. Mr. Oncken gave the antitrust advice. Participants introduced themselves. Mr. Alston reviewed the draft agenda and a discussion of strategy regarding the Customer Information MBPs was added to other business. Mr. Behr moved, seconded by Mr. Rothfuss, to accept the draft agenda as modified. The motion passed unanimously. Mr. Behr moved, seconded by Mr. Rothfuss, to accept the January 6, 2005, May 5, 2005 and June 7, 2005 draft minutes as written. The motion passed unanimously.

2. Review and Finalize IR Specifications for TEIS

The subcommittee worked through the RXQ Billing and Payments TIBP that resulted from the last meeting. Numerous changes were made to the document. Mr. Behr accepted the working redlines, but left items that could be of interest to the RXQ BPS in redline. The revised workpaper is attached to these minutes.

At the end of discussion the subcommittee determined that the document should be forwarded to the RXQ TEIS for further development. It was noted that the TEIS received a working copy after the last meeting. The document will also be forwarded to the RXQ BPS for review at their next meeting. Moving forward, Mr. Behr suggested the IR should send its work product back to the RXQ BPS before it is forwarded to RXQ TEIS for further development. Some participants stated concern that the proposed procedure would slow down development and noted that was different than the way work proceeded through the WGQ subcommittees. There was not consensus on the proposed procedure.


The subcommittee discussed how it should work with the RXQ BPS to manage its work flow in the future. Ms. Edwards noted that the RXQ BPS was currently working on the Customer Information MBPs, and a final work product should be produced soon. Mr. Behr suggested it would be appropriate for the IR to become engaged when there is a draft work product instead of a final BPS work product. Mr. Behr will work with the RXQ BPS leadership to be added to the BPS agenda for the September 1 and 29 RXQ BPS meetings to discuss any IR work on the Customer Information MBPs.

The subcommittee also briefly discussed flat files, but it was noted that flat files is a TEIS issue, not an IR issue. It was suggested that the parties that are interested in flat files should drive that discussion.





REQ/RGQ Information Requirements Subcommittee Meeting – July 11, 2005 Page 2 of 2

4. Adjourn

The meeting adjourned at 11:50 a.m. Eastern.

5. Attendance

Name Organization Comments

Rick Alston ODEC In Person

George Behr Energy Services In Person

Bill Brooks Pepco In Person


Mary Edwards Dominion VA Power In Person



Barbara Wise Baltimore Gas & Electric Phone





TO: NAESB REQ/RGQ TEIS Participants and Interested Parties


RE: REQ/RGQ TEIS Conference Call Draft Minutes – May 27, 2005

DATE: June 16, 2005

NORTH AMERICAN ENERGY STANDARDS BOARD REQ/RGQ TEIS CONFERNCE CALL with WEB CONFERENCING

May 27, 2005 – 9:00 a.m. to 11:00 a.m. Central DRAFT MINUTES


Mr. Behr called the meeting to order and welcomed participants. Mr. Oncken gave the antitrust advice. Mr. Behr noted that this was a single topic agenda to address the comments submitted to the Executive Committees on the RXQ QEDM model business practices. Adoption of the 2/24/05 and 3/10/05 draft minutes was deferred until the June 8 meeting. Mr. Rothfuss moved, seconded by Ms. Moreno, to adopt the draft agenda.

2. Review Revised RXQ QEDM in light of comments at the May REQ & RGQ Executive Committee meeting

Mr. Behr stated the Executive Committees did an initial review of the RXQ QEDM model business practices at the May meeting, but determined the model business practices were not ready for a vote. He added that there were several comments submitted that the TEIS should review and accommodate, if appropriate, and the MBPs should be reorganized as Book 5 instead of included in Book 0. All changes to the RXQ QEDM were captured during the webcast, and the revised document is attached.

The TEIS reviewed the reorganized MBPs and then addressed the changes proposed in each set of comments.

Comments submitted by Dominion VA Power: The TEIS reviewed and accepted most of the proposed changes. Action was not taken on the first comment on page 8, because the TEIS did not understand the comment. There was considerable discussion about the proposed changes to principle 2 (RXQ.5.1.2), as Ms. Alexander also addressed the proposed principle in her comments. The TEIS did not support making the changes because the original language mirrors the language contained in the WGQ standards, and those standards have been on file with the Federal Energy Regulatory Commission for many years. Additionally, Mr. Jarrett questioned the value that making the proposed change would add to the MBPs. Mr. Behr noted that the glossary terms that were specific to the MBP were included in the MBP, and subcommittee leadership had submitted those terms to the RXQ Glossary subcommittee for further processing. Ms. Moreno opposed adding the following phrase to proposed MBP RXQ.5.3.3.6: unless otherwise stipulated in the Billing Services Agreement. The phrase was not added. Mr. Behr noted that while there is a definition for Business Day, the TEIS did not use that defined term in its proposed MBPs. Regarding the comments on the related standards (Internet ET), Mr. Behr noted that the subcommittee was not in the position to reference those numbers since they have not been assigned by the NAESB Office. The TEIS did not add the proposed MBP on testing.

Comments submitted by Barbara Alexander: Many of the changes proposed in Ms. Alexander’s comments were also raised in the previous set of comments and accepted. The proposed change to principle 2 (RXQ.5.1.2) was not made (see discussion above). The proposed change to principle 7 (RXQ.5.1.8) was made.





Comments submitted by Marcy McCain: Change were made to the document consistent with Ms. McCain’s comments.

Additional comments submitted by Barbara Alexander: The issues raised in these comment were discussed above.

3. Vote to send the revised RXQ QEDM to the REQ and RGQ Executive Committees

Mr. Rothfuss moved, seconded by Mr. Jarrett, to modify the RXQ QEDM Recommendation as noted in the meeting today and forward the revised recommendation to the Executive Committees. The motion passed unanimously.


No other business was discussed.

5. Adjourn

The conference call adjourned at 10:25 am Central.

6. Attendance

Name Organization

George Behr ESG

Mark Jarrett Southern Company

Annunciata Marino Pennsylvania Public Utilities Commission

Todd Oncken NAESB

Dan Rothfuss Cinergy


North American Energy Standards Board 1301 Fannin, Suite 2350, Houston, Texas 77002

Phone: (713) 356-0060, Fax: (713) 356-0067, E-mail: [email protected] Home Page: www.naesb.org

RXQ TEIS Draft Minutes – June 8, 2005



RE: REQ/RGQ TEIS Meeting Draft Minutes – June 8, 2005


REQ/RGQ TEIS MEETING June 8, 2005 – 9:00 a.m. to 3:00 p.m. Eastern hosted by ODEC

Draft Minutes


Mr. Behr called the meeting to order and welcomed participants. Mr. Oncken gave the antitrust advice. Mr. Behr reviewed the draft agenda. Mr. Rothfuss moved, seconded by Ms. Wise, to adopt the draft agenda without modification. The motion passed unanimously. Ms. Wise moved, seconded by Mr. Jarrett, to adopt the draft minutes from February 4, 2005 and March 10, 2005 as drafted. The motion passed unanimously.

2. Review TEIS processes

Mr. Behr reviewed the RXQ MBP development process. He noted the RXQ BPS drafts the business practices, and the RXQ IR drafts the sample paper transaction, data dictionary, and code values dictionary. Further, he added that the TEIS should continue the work of the RXQ IR and more fully develop the transaction standards, including developing a cross reference table for X12, a sample X12 transaction and edism sef files. Also, he said the TEIS should limit its work to the business specifications forwarded by the RXQ IR. It was noted that the TEIS work was challenging and tedius, because there are nine transactions to create and there could be some variations within each transaction. The subcommittee used the technical implementation standards for the WGQ Nominations as an example of the work that the TEIS should complete.

The subcommittee decided to maintain the existing work assignments and either create the edism sef files through their own Foresight software, or redline documents that are in other formats that the NAESB Office could input into the Foresight software. The subcommittee will then review the completed files to verify they are accurate. The subcommittee decided to complete the work on X12 before working on the flat file transactions.

The subcommittee will use the transactions from FREDI or individual states as the basis for its work. Mr. Behr suggested Texas as a model, because Texas is the only state with current edism sef files. During discussion it was noted that edism does not do a good job of handling the instructional notes contained in many of the state transactions, which generally contain business rules that are addressed in the MBPs, so any notes not addressed in the MBPs should be forwarded to the RXQ BPS for future inclusion.

It was also determined that the sample transactions should only address the mandatory fields.

3. Complete initial technical review of IR specifications

The TEIS completed the technical implementation markup (X13 EDI Subtab) for Consolidated Billing Bill-Ready Invoice (attached). The TEIS used this process as the model for their individual assignments. It took approximately three hours to complete this process.




RXQ TEIS Draft Minutes – June 8, 2005

A remaining item for this section was the sample X12 transaction. Existing sample transactions should be reviewed (and modified as appropriate) for consistency with the technical implementation. It was decided that no transaction set tables would be developed.

4. Assign work to members for completion

The following assignments were made: Mr. Behr – billing usage, termination of billing services; Ms. Wise – consolidated billing bill-ready invoice, payments; Mr. Brooks – payment notification (collections); Mr. Dodson – application advice; Mr. Rothfuss – consolidated billing rate-ready invoice.


The next TEIS meeting is scheduled for July 11-12, 2005 in Richmond, VA hosted by Dominion. A follow-up conference call was scheduled for July 19, 2005 from noon to 2:00 Central.

6. Adjourn

The meeting adjourned at 2:09 pm Eastern.

7. Attendance

Name Organization In Person/Phone

Rick Alston Old Dominion Electric Coop. In Person

George Behr Energy Services Group In Person

Bill Brooks PEPCO In Person


Mary Edwards Dominion Virginia Power In Person

Dave Eichenlaub VA State Corporation Commission In Person

Mark Jarrett Southern Company In Person

Diane Jenkins VA State Corporation Commission In Person



Barbara Wise Baltimore Gas & Electric In Person





RXQ TEIS Draft Minutes – July 11-12, 2005 1 of 2



RE: REQ/RGQ TEIS Meeting – July 11-12, 2005


REQ/RGQ TEIS MEETING July 11-12, 2005; hosted by Dominion in Richmond, VA

Draft Minutes


Mr. Behr called the meeting to order and welcomed attendees. Mr. Oncken gave the antitrust advice. Participants introduced themselves. Mr. Behr reviewed the draft agenda and no modifications were offered. Mr. Rothfuss moved, seconded by Mr. Alston, to adopt the agenda. The motion passed unanimously.

Adoption of the June 8, 2005 minutes was deferred until the next meeting.

2. Work on Billing and Payments Technical Transactions

The subcommittee reviewed the technical transactions completed since the last meeting. To prepare the technical transactions, the subcommittee compiled several existing documents, including the technical transactions from Texas, the FREDI documents, and the technical transactions for the home state of the drafters. A current redline of each of the transactions in shown in the attachment to these minutes.

Payment Notification (RXQ 248): This draft document was reviewed and numerous additional changes were made. An outstanding item is to create the examples. The examples from the Texas model should be used, if applicable, because sef files already exist. During discussion the TEIS posed the following question to RXQ BPS:

Some of the technical standards used to develop the transactions included the ability to cancel a write-off but that capability is not included in the NAESB MBPs. Should an MBP be developed for that purpose?

Termination of Billing (568): This draft document was reviewed and additional changes were made.

Consolidated Billing – Bill Ready Invoice (810BR): This document was not discussed since it was developed during the last TEIS meeting.

Application Advice (824): This draft document was reviewed and additional changes were made. It was noted that EDISM does not provide the ability to group items, so the groupings contained in the draft (and the FREDI document) would probably not be maintained. There were still several issues to be resolved on this transaction, including updating the code values table.

Consolidated Billing – Rate Ready Invoice (810RR): The completed work for Consolidated Billing – Bill Ready Invoice was used as the basis for this transaction.

Billing Usage (867): This draft document was reviewed and additional changes were made. It was decided that the REF Q5 and REQ 12 should be merged for this transaction. During discussion participants were sensitive to maintaining the ERCOT data elements.

Payment Remittance (820): This draft document was reviewed and additional changes were made. It was noted that this is a remittance only transaction. During discussion it was noted that several





RXQ TEIS Draft Minutes – July 11-12, 2005 2 of 2

items from the data dictionary were not accounted for, including: discount amount, customer payment posting date, and money collected.

3. Assign work to members for completion

The work assignments from the last meeting were maintained.


The next conference call is scheduled for August 11 from 1:00 Eastern to 4:00 p.m. Eastern. The following should be completed before the next conference call:

• Update the Code Value Tables for each transaction. These should be forwarded to Mr. Behr for incorporation into the RXQ IR document.

• Review RXQ Billing and Payments MBPs to identify each place where UET is referenced and verify all references are represented in the technical transactions. Mr. Alston volunteered for this task.

• Reconcile the data elements for each of the transactions.

5. Adjourn

The meeting adjourned on day two at 3:04 p.m. Eastern.

6. Attendance

Name Organization Day One Day Two

Rick Alston ODEC In Person In Person

George Behr Energy Services In Person In Person

Bill Brooks Pepco In Person In Person

Greg Dodson Dominion In Person In Person

Mary Edwards Dominion VA Power In Person

Todd Oncken NAESB Phone Phone

Dan Rothfuss Cinergy In Person In Person

Barbara Wise Baltimore Gas & Electric Phone Phone


Term Proposed Definition

Customer Information Set

Customer-specific identifiers and usage data provided by a Distribution Company (or other Market Participant responsible for the retention and maintenance of individual Customer data in a given Distribution Company's service territory) in response to a Customer-specific Information Request from a Supplier or other Market Participant.

Customer Specific Information Request

A transaction submitted by a Supplier or other Market Participant to the Distribution Company (or other Market Participant responsible for the retention and maintenance of individual Customer data in a given Distribution Company's service territory) to obtain the Customer Information Set for the purposes authorized by the Applicable Regulatory Authority.

Mass Customer ListA listing of Customer-specific data for most or all Customers within a Distribution Company's service territory made available upon request to Suppliers and other Market Participants as authorized and specified by the Applicable Regulatory Authority.

08-11-05 Glossary Subcommittee Meeting Workpaper

Proposed definitions submitted by the Business Practices Subcommittee


07-18-05 Glossary Subcommittee Meeting Workpaper

Proposed definitions submitted by the Business Processes Subcommittee

Term Proposed Definition

Customer Information Set

Customer- specific identifiers and usage data provided via Uniform Electronic Transaction by a Distribution Company (or other authorized Market Participant responsible for the retention and maintenance of individual customer data in a given Distribution Company’s service territory) in response to a Customer- sSpecific Information Request from a Supplier or other authorized Market Participant.

Customer Customer-sSpecific Information Request

A Uniform Electronic Transaction submitted by a Supplier or other authorized Market Participant to the Distribution Company (or other authorized Market Participant responsible for the retention and maintenance of individual customer data in a given Distribution Company’s service territory) in order to obtain the Customer Information Set for the purposes authorized by the Applicable Regulatory Authority.

Mass Customer List

An electronic data set containing listing Customer- specific data for most or all customers within a Distribution Company’s service territory made available upon request to Suppliers and other authorized Market Participants via an internet-based download or a CD-ROM, as authorized and specified by the Applicable Regulatory Authority.

Validation Elements

Customer Customer-specific data required in a Uniform Electronic Transaction request from a Supplier or other authorized Market Participant in order for the Distribution Company (or another authorized Market Participant responsible for the retention and maintenance of individual customer data in a given Distribution Company’s service territory) to accept and respond to the Uniform Electronic Transaction request... such as a Customer-Specific Information Request or a Switch Request.


8/18/2005 1

2. Glossary These definitions are echoed in this book for convenience. Where there are discrepancies due to editing or maintenance, definitions in this RXQ Glossary are official. Glossary Term Model Business

Practice Definition

Batch Flat-file [TBD] The term used within the FF/EDM to describe Tthe automated computer-to-computer transfer of Flat-files.

Business Rule Change [TBD]

Any change in: aA) change in the presence and/or the acceptable content of a data element sent by the changing party, bB) a new business response to an accepted data element received by the changing party; cC) a new business response to the acceptable content of a data element received by the changing party; dD) a new intended business result.

D-U-N-S® Number

The D-U-N-S® Number is a 9-digit number assigned to companies by the Dun & Bradstreet Corporation .The D-U-N-S®+4 Number is a 10- to 13-digit number, where characters 10 through 13 are arbitrarily assigned by the owner of the D-U-N-S® Number.

EDI/EDM [TBD]

Electronic Data Interchange/Electronic Delivery Mechanism. The term used to Ddescribes ANSI ASC X12 computer-to-computer electronic data interchange of information in files as mapped from the RXQ. x.4.z RXQ model business practices in the NAESB RXQ Implementation Guides and communicated between trading partners over the Internet using the NAESB Internet Electronic Transport.(ET)

Entity [TBD]

A person or organization with sufficient legal standing to enter into a contract or arrangement with another such person or organization (as such legal standing may be determined by those parties) for the purpose of conducting and/or coordinating energy transactions.

Entity Common Code [TBD]

The number used as the common company identifier, including D-U-N-S® Number or D-U-N-S®+4.Number The DUNS number is a 9-digit number assigned to companies by the Dun & Bradstreet Corporation (D&B). The DUNS+4 number is a 10- to 13-digit number, where characters 10 through 13 are arbitrarily assigned by the owner of the DUNS number. Entity common codes should be ‘legal entities,’ that is, Ultimate Location, Headquarters Location, and/or Single Location in Dun & Bradstreet terms.

FF/EDM [TBD] The term used toFlat file/Electronic Delivery Mechanism Ddescribes a standardized Fflat-file electronic data interchange of information in files as mapped from the x.4.z RXQ .x.4.z model business practices.

Flat-file [TBD] An RXQEDM Flat-file is an ASCII comma-separated-value (CSV) file with the characteristics as defined in the RXQEDM model business practices.

Interactive Flat-file [TBD] The term used within Describes the the FF/EDM to describe the transfer of Flat-

files using an interactive browser.

RXQEDM [TBD] Electronicic Delivery Mechanism model business practices for the NAESB RGQ and REQ quadrants that govern package payload file contents, including X12 EDI, Flat-file and other formats.

Testing [TBD]

Verification that trading partners have the system capabilities in place for Testing between trading partners includes testing of: : a(A) intended business results, b(B) proposed electronic transport, including security, enveloping, cryptography; and c(C) Eelectronic Ddelivery Mmechanisms (xxxEDI/EDM or FF/EDM), including data validity, model business practice compliance, etc.

Trading Partner [TBD] A party that enters into an agreement with another party to transact business electronically using NAESB model business practices.

Translator [TBD] A program or set of programs that process the contents of payloads, applying ANSI X12 and other model business practices, and transforms the information to other formats.




Retail Quadrants

TAB 11

2005 Annual Plans

• The 2005 plans as approved by the Board of Directors on June 22 are included. Should the REQ or RGQ EC determine that changes are to be made to the plan as a result of the subcommittee updates, a motion to approve the changes for forwarding to the Board for approval (September 22) would be required. The motion would require a simple majority to pass.





NAESB Retail Electric Quadrant 2005 Annual Plan Approved by the Board of Directors on June 22, 2005


2005 ANNUAL PLAN – RETAIL ELECTRIC QUADRANT1 Approved by the Board of Directors June 22, 2005

Item Number & Description Completion2 Assignment3

1 Billing & Payment Data Dictionaries and Models

a. Develop the Data Sets for the Billing & Payments MBPs

Status: Underway

3rd Qtr

2005

IR

b. Modify Billing & Payments MBPs pursuant to Request R04034.

Status: Completed.

3rd Qtr

2005

BPS

c. Technical Electronic Implementation Standards – Billing & Payments

Status: Pending, Discussion Underway

3rd Qtr

2005

TEIS

2 Market Participant Interactions

Develop model practices to support interactions between Distribution Companies and/or registration agents and Suppliers, such as supplier registration processes, governing documents, and roles and obligations of both Distribution Company and/or registration agent and Supplier (e.g. content and framework of governing documents or orders).

Status: Completed

1st Qtr.

2005

SUIS/BPS

3 Customer Information

Develop practices for exchanging customer information necessary for interactions prior to enrollment and billing, i.e., customer authorization procedures, identifying types of customer information necessary for pre-enrollment activities, and methodologies for exchanging information.

Status: Underway.

4th Qtr.

2005

BPS

4 Customer Enrollment, Switching & Dropping

Develop practices for submitting and receiving, processing and fulfilling a customer’s request to enroll with or leave a supplier (including suppliers dropping customers) and for maintaining current customer account information, and for notifying affected parties.

4th Qtr.

2005

BPS

1 As outlined in the NAESB Bylaws, the REQ will also address requests submitted by members and assigned to the REQ through the Triage Process. 2 Dates in the completion column are by end of the quarter for completion by the assigned committee. The dates do not necessarily mean that the standards are fully staffed so as to be implementable by the industry, and/or ratified by membership. If one item is completed earlier than planned, another item can begin earlier and possibly complete earlier than planned. There are no begin dates on the plan. 3 Assignments are subject to approval of the proposal to restructure the subcommittees.







Item Number & Description Completion2 Assignment3

5 Examine Wholesale Gas Quadrant Non-EDM Standards

Review NAESB Wholesale Gas Quadrant Non-EDM manuals to determine whether the standards within should be modified and/or adopted for use in the Retail Quadrants.

Ongoing BPS

Technical Electronic Implementation Subcommittee4

6 Quadrant EDM

Establish the Quadrant specific EDM (QEDM) standards for REQ and RGQ.

Status: Underway.

2nd Qtr.

2005

Technical Electronic Implementation

Provisional Activities

Review security standards as may be deemed necessary; Public Key Infrastructure (PKI).

“Energy Day” Standard - including assessment of changes to existing NAESB standards.

Electronic Customer Billing - Develop practices for the provision electronically of billing information.

Future Activities

Customer Inquiries

Develop procedures for responding to customer inquiries directed to Distributors and/or Suppliers and for notification of the other party.

TBD

Supplier Certification

Develop practices for Distribution Companies to register/certify new Suppliers when they seek to begin doing business in the Distribution Company’s service area.

TBD

Retail Meter Data Validation, Editing & Estimating

Develop procedures for insuring the integrity and validity of retail customer metering data that is needed by utilities and suppliers for billing, load profiling, settlement, etc. Issues related to unbundled or competitive metering are not to be considered.

TBD

Load Profiling

Develop practices for using statistical methods to estimate interval consumption by customers who do not have interval meters.

TBD

Settlement Process

Reconcile energy schedules and energy delivered by suppliers within a given market. Note:

TBD

4 The TEIS is assigned the completion of any technical work forwarded to them by the business development subcommittees ideally one quarter after receipt of forwarded work.







Item Number & Description Completion2 Assignment3 will need to be coordinated with the WEQ.

Program of Standards Maintenance & Fully Staffed Standards Work5

Business Practice Requests Ongoing Assigned by the EC on a request by request basis

Information Requirements and Technical Mapping of Business Practices Ongoing Assigned by the EC on a request by request basis

Ongoing Interpretations for Clarifying Language Ambiguities Ongoing Assigned by the EC on a request by request basis

Ongoing Maintenance of Code Values and Other Technical Matters Ongoing Assigned by the EC on a request by request basis

Ongoing Development and Maintenance of Definitions Ongoing Glossary Subcommittee

5 This work is considered routine maintenance and thus the items are not separately numbered.

Adobe 7 of 571

North American Energy Standards Board 1301 Fanin, Suite 2350, Houston, Texas 77002

Phone: (713) 356-0060, Fax: (713) 356-0067, E-mail: [email protected]


NAESB Retail Gas Quadrant 2005 Annual Plan Approved by the Board of Directors on June 22, 2005

NORTH AMERICAN ENERGY STANDARDS BOARD 2005 ANNUAL PLAN – RETAIL GAS QUADRANT1

Approved by the Board of Directors June 22, 2005

Item Number & Description Completion2

Subcommittee3

Assignment

1 Billing & Payment Datasets and Models

a. Develop the Data Dictionaries for the Billing & Payments MBPs Status: Underway

3rd Qtr

2005

IR

b. Modify Billing & Payments MBPs pursuant to Request R04034.

Status: Completed. 3rd Qtr

2005

BPS

c. Technical Electronic Implementation Standards – Billing & Payments

Status: Pending, Discussion Underway

3rd Qtr

2005

TEIS

2 Market Participant Interactions

Develop model practices to support interactions between Distribution Companies and/or registration agents and Suppliers, such as supplier registration processes, governing documents, and roles and obligations of both Distribution Company and/or registration agent and Supplier (e.g. content and framework of governing documents or orders).

Status: Completed

1st Qtr.

2005

SUIS/BPS

3 Customer Information

Develop practices for exchanging customer information necessary for interactions prior to enrollment and billing, i.e., customer authorization procedures identifying types of customer information necessary for pre-enrollment activities, and methodologies for exchanging information.

Status: Underway.

4th Qtr.

2005

BPS

4 Customer Enrollment, Switching & Dropping

Develop practices for submitting and receiving, processing and fulfilling a customer’s request to enroll with or leave a supplier (including suppliers dropping customers) and for maintaining current customer account information, and for notifying affected parties.

4th Qtr.

2005

BPS

5 Examine Wholesale Gas Quadrant Non-EDM Standards

Review NAESB Wholesale Gas Quadrant Non-EDM manuals to determine whether the standards within should be modified and/or adopted for use in the Retail Quadrants.

Ongoing BPS

1 As outlined in the NAESB Bylaws, the RGQ will also address requests submitted by members and assigned to the RGQ through the Triage Process. 2 Dates in the completion column are by end of the quarter for completion by the assigned committee. The dates do not necessarily mean that the standards are fully staffed so as to be implementable by the industry, and/or ratified by membership. If one item is completed earlier than planned, another item can begin earlier and possibly complete earlier than planned. There are no begin dates on the plan. 3 Assignments are subject to approval of the proposal to restructure the subcommittees.






NORTH AMERICAN ENERGY STANDARDS BOARD 2005 ANNUAL PLAN – RETAIL GAS QUADRANT1

Approved by the Board of Directors June 22, 2005

Item Number & Description Completion2

Subcommittee3

Assignment

Technical Electronic Implementation Subcommittee4

6 Quadrant EDM

Establish the Quadrant specific EDM (QEDM) standards for REQ and RGQ.

Status: Underway

2nd Qtr.

2005

Technical Electronic Implementation

Provisional Activities

Review security standards as may be deemed necessary; Public Key Infrastructure (PKI).

“Energy Day” Standard - including assessment of changes to existing NAESB standards.

Electronic Customer Billing - Develop practices for the provision electronically of billing information.

Future Activities

Customer Inquiries

Develop procedures for responding to customer inquiries directed to Distributors and/or Suppliers and for notification of the other party.

TBD

Supplier Certification

Develop practices for Distribution Companies to register/certify new Suppliers when they seek to begin doing business in the Distribution Company’s service area.

TBD

Program of Standards Maintenance & Fully Staffed Standards Work5

Business Practice Requests Ongoing Assigned by the EC on a request by request basis

Information Requirements and Technical Mapping of Business Practices Ongoing Assigned by the EC on a request by request basis

4 The TEIS is assigned the completion of any technical work forwarded to them by the business development subcommittees ideally one quarter after receipt of forwarded work. 5 This work is considered routine maintenance and thus the items are not separately numbered.






Ongoing Interpretations for Clarifying Language Ambiguities Ongoing Assigned by the EC on a request by request basis

Ongoing Maintenance of Code Values and Other Technical Matters Ongoing Assigned by the EC on a request by request basis

Ongoing Development and Maintenance of Definitions Ongoing Glossary Subcommittee




Retail Quadrants

TAB 12

Recommendations for Vote – Annual Plan Item #6, R04030

• Recommendation for Annual Plan Item #6 and R04030 are attached. The comment period R04030 ended on May 27 and no comments were received. For Annual Plan Item #6, the Retail ECs instructed the subcommittee on May 11 to make changes as noted in that meeting. The revised work product is attached.

• To approve the recommendations would require 67% of each of the retail EC members) and 40% of each segment’s EC members.



North American Energy Standards Board 1301 Fannin, Suite 2350, Houston, Texas 77002 Phone: (713) 356-0060, Fax: (713) 356-0067, E-mail: [email protected]


via email and posting TO: NAESB Retail Electric Quadrant (REQ), Retail Gas Quadrant (RGQ), and Wholesale Gas Quadrant (WGQ) Members and Interested Industry Participants FROM: DeDe Kirby, Meeting/Project Manager RE: REQ, RGQ, and WGQ Request for Comments DATE: April 28, 2005 An industry comment period begins today, April 28, 2005 and ends on May 27, 2005 for one RGQ, REQ, and WGQ recommendation:

Recommendation R04030 - Addition of one new data element to the MIME content header of the NAESB EDM POST – http://www.naesb.org/pdf2/r04030_rec.doc.

All interested parties, regardless of membership status within NAESB are eligible to submit comments for consideration. The REQ & RGQ Executive Committee (EC) will review this recommendation and consider it for vote as NAESB REQ and RGQ standard on August 24, 2005 and in that consideration will review all submitted comments. The WGQ EC will review this recommendation and consider it for vote as NAESB WGQ standard on August 25, 2005 and in that consideration will review all submitted comments. All comments received by the NAESB office by end of business on May 27, 2005 will be posted on the Home Page (http://www.naesb.org/request.asp) and forwarded to the REQ, RGQ, and WGQ EC members for their consideration. If you have difficulty downloading the recommendation, please call the NAESB office at (713) 356-0060. The recommendation is also attached for your convenience. Best Regards,

DeDe Kirby cc: Rae McQuade, Executive Director




NAESB Retail Electric and Retail Gas Quadrant Members as of April 12, 2005

Quadrant Seg Organization Contact

REQ d Ameren Services Company Patrick Eynon

REQ d Baltimore Gas & Electric Co. Ruth Kiselewich Johnny Magwood

REQ su Calpine Energy Services, LP Janet Dixon

REQ d Cinergy Services, Inc. Paul K. Jett

REQ d Consolidated Edison Company of NY Hollis Krieger

REQ e Defense Energy Support Center Lisa Robert

REQ d Detroit Edison Company William J. Newbold, Jr.

REQ su Direct Energy Business Services David Booty

REQ su Dominion Retail William Barkas Richard Zelenko

REQ d Dominion Virginia Power David F. Koogler Mary Edwards

REQ s EC Power International Judy Bailey J. Cade Burks

REQ su Electric America Joseph C. Macek

REQ s Electric Reliability Council of Texas (ERCOT)

Sam R. Jones Rob Connell Ray Giuliani

REQ d Exelon Energy Delivery Bill Walsh

REQ s Foley & Lardner Bryan S. Anderson

REQ d Georgia Power Company Ernestine McNair Yvette Camp

REQ d Gulf Power Company Joel Thomas Kilgore Yvette Camp

REQ d MidAmerican Energy James E. Wilson

REQ d Mississippi Power Company Dorman Davis Yvette Camp

REQ e Office of Public Advocate, State of Maine Barbara Alexander

REQ e Ohio Consumers Council Randy Corbin

REQ e Pennsylvania Office Of Consumer Advocate

Tanya J. McCloskey Sonny A. Popowsky

REQ s PPLSolutions, LLC James M. Minneman

REQ d Public Service Electric & Gas Terrence Moran





REQ su Reliant Energy Retail Services, LLC Derek Mauzy

REQ d Savannah Electric and Power Company Osman Bholat

REQ s Southern Company Services Mark S. Jarrett Yvette Camp

REQ s Structure Group Stacey Wood

REQ su TXU Energy Retail Felecia Lokey

REQ d Wisconsin Public Service Corporation William L. Bourbonnais Les Nishida Ken Thiry

RGQ d AGL Resources Inc. Katrina Bond

RGQ d Baltimore Gas & Electric Company Steven Zavodnick

RGQ su Center Point Energy Minnegasco Andrea Newman

RGQ s Commerce Energy Group Greg Lander

RGQ su Dominion Retail, Inc. Richard A. Zollars

RGQ su Duke Energy Gas Transmission, LLP Richard Kruse Marcy L. McCain

RGQ s Energy Services Group, Inc. George Behr

RGQ su Exelon Energy Barb Fatina

RGQ e Indiana Office of Utility Consumer Counselor Matthew Parsell

RGQ s International LNG Alliance (Sweet Strategies) David Sweet

RGQ d KeySpan Energy Delivery Nancy Cianflone

RGQ s Latitude Technologies Leigh Spangler

RGQ d National Fuel Gas Distribution Corporation Mike Novak

RGQ d Niagara Mohawk James Dillon

RGQ d Northern Indiana Pulic Service Company (NiSource Inc.) Mark T. Maassel

RGQ e Northwest Industrial Gas Users Paula E. Pyron

RGQ e Ohio Consumers Council Bruce M. Hayes

RGQ e Pennsylvania Office of Consumer Advocate

Tanya J. McCloskey Stephen Keene

RGQ d Peoples Gas System Rachel Gebhardt





RGQ d Philadelphia Gas Works (APGA billing: Bert Kalisch)

Joe Stengel Craig White

RGQ d Public Service Electric & Gas Company Terrence Moran

RGQ s R. J. Rudden Associates, Inc. Richard J. Rudden John D. Charbonneau Don Sytsma

RGQ su Shell Energy Services Harry Kingerski

RGQ s SunGard EnForm Consulting David F. Pfeifer

RGQ s Systrends Dave Darnell

RGQ su UBS Energy LLC Suzanne Calcagno

RGQ d UGI Utilities, Inc. Paul Szykman

RGQ d Union Gas Greg Tetreault

RGQ d Wisconsin Public Service Corporation William Bourbonnais Glen R. Schwalbach Les Nishida

RGQ d Xcel Energy Don Basler




NAESB Wholesale Gas Quadrant Members as of April 13, 2005 Organization Segment Contact

8760 s Jim Buccigross

AEP Energy Services, Inc. s Cathy Szasz

Alliance Pipeline LP pl Neil Coghlan

Ameren Corporation l Scott Glaeser

Apache Corporation pr Michele Markey

Arizona Public Service Company e Gary Duede Kelly Daly Curt Brechtel

Atmos Energy pl Steve Easley

Ballard Natural Gas, LLC s Susan Thibodeaux

Baltimore Gas & Electric Co. l Phil Precht

Barclays Bank PLC s Guy Kern-Martin

BG LNG Services, LLC s Martha Braddy

Boeing Company, The e Tina Burnett

BP Energy pr Bill Benham Lauren Kaestner

Bridgeline Gas Marketing pl Georgia Blanchard

Burlington Resources pr Paul Keeler

Calpine Energy Services, LP e Janet Dixon Craig Chancellor

Cargill Incorporated s Kathy Gerken

Cascade Natural Gas Corporation l Mark Sellers-Vaughn

CenterPoint Energy Gas Services, Inc. s James G. Beste

CenterPoint Energy Gas Transmission Company pl Larry Thomas

CenterPoint Energy Mississippi River Transmission Corp.

pl Robert Trost

Chandeleur Pipe Line Company pl Janice E. Rogers

Chevron/Texaco pr Randy Mills

Cinergy e John Procario

Cinergy Marketing and Trading s Maribeth Bedevian




Organization Segment Contact

Columbia Gas Transmission pl Carl Levander

Columbia Gulf Transmission Co. pl Carl Levander

Comprehensive Energy Services e Jim Templeton

ConocoPhillips Gas and Power pr Peter Frost

Consolidated Edison Company of NY l Mary Jane McCartney Jim Stanzione

Constellation Energy Commodities Group, Inc. s Robert McKay

Dauphin Island Gathering Partners pl Katie Rice

Defense Energy Support Center e Veronica Jones Kevin Ahern

Department of Energy e Christopher Freitas

Dominion Exploration and Production, Inc. pr David Ogden Gary Weaver Sheri Heslington

Dominion Resources l Craig Colombo

Dominion Transmission, Inc. pl Gary Sypolt Iris King

Duke Energy Gas Transmission - Texas Eastern pl Richard Kruse

Edison Mission Marketing and Trade e Christian Hnat William Roberts

El Paso Eastern Pipelines pl Larry Smith Mark Gracey

El Paso Natural Gas pl William Griffith

El Paso Production Company pr Bill Hebenstreit

Enbridge Energy Company, Inc. pl Terry McGill

EnCana Corporation pr Keith Sappenfield

EnCana Marketing (USA) Inc. s Keith Sappenfield

Energy East Management Corporation l Marjorie Perlman

Energy Velocity s Konni Keuter

Entergy Services, Inc. e Arlynn Kelleher Terry Shields

Equitable Gas Company l Steve Rafferty

Equitrans, L.P. pl Mina Speicher





ExxonMobil Gas Marketing pr Richard Smith

Florida Power & Light Company e Dona Gussow

Florida Reliability Coordinating Council e Joe Stepenovitch

Gas Transmission Northwest Corporation pl Jay Story

Great Lakes Gas Transmission pl Gene Fava

Group 8760 s Jim Buccigross

Gulf South Pipeline pl Claire Burum Randy Young

H S Resources Inc. pl Carol Hall

Imperial Irrigation District e William Rapp

Iroquois Gas Transmission System pl Tom Gwilliam

Kern River Gas Transmission Company pl Janie Nielsen

Kerr-McGee Oil and Gas Company pr Charles (Chuck) Johnson

KeySpan Energy l Dolores Chezar

Laclede Gas Co. l Kenneth Neises

Latitude Technologies s Leigh Spangler

Louis Dreyfus Energy Services L.P. s Mary Ellen Bell Ruby H. Melton

Lower Colorado River Authority e Mickey Bell

Oxadel Consulting, LLC s Lyn Maddox

Marathon Oil Company pr Robin Perrine

Mewbourne Oil Company pr Michael F. Shepard

National Fuel Gas Distribution l Michael Novak

National Fuel Gas Supply Corp. pl Joseph Kardas

Natural Gas Pipeline Co of America pl Paul Love

New Jersey Natural Gas Company l Douglas C. Rudd

Niagara Mohawk Power Corporation l Bruce Garcy

Nicor Gas l Nancy Brucher





NiSource Inc. l M. Christopher Maturo

NJR Energy Services Company s Ginger Richman

Northern Natural Gas pl Mary Darveaux

Northern Plains Natural Gas Company, Inc. pl Scott Coburn

Northwest Natural Gas Company l Randolph Friedman

NOVA Gas Transmission Ltd. pl Doug Miller

Occidental Energy Marketing Inc. (OEMI) pr Carol Wilson

Pacific Gas & Electric l John Breen

Panhandle Eastern Pipe Line pl Bill (William) Grygar Kim Van Pelt

PECO Energy Co. l Reed R. Horting Amy Hamilton

Pemex Gas Y Petroquimica Basica s Juan Enrique Gonzales Azuara

Peoples Gas Light & Coke Co. l Tom Zack

Platts s Bill Murphy

Portland General Electric pl Kathy Davies

Portland Natural Gas Transmission System pl David Haag

PPL EnergyPlus, LLC e Anne Lovett

Promet Energy Partners, LLC s Gregory R. White

Public Service Electric & Gas l David Wohlfarth

Questar Pipeline Co. pl Scott Hansen

Quorum Business Solutions Inc. s Douglas Allen

Sabine Pipe Line LLC pl Jan Rogers

Salt River Project Agricultural Improvement & Power District

e Diane McVicker

SCANA Corporation pl Jacquelyn Gettle

Sempra Energy - Southern California Gas Co. l Lee Stewart Rodger Schwecke

Sequent Energy Management, L.P. s Pat Metteauer

Shell Gas Transmission, LLC pl Chuck Cook





SolArc Inc. s Tim Curtis

Southern California Edison Company e Roman Bakke

Southern Company Services, Inc. e Carl Haga

Southern Natural Gas Co. pl Renee Hyde Ronnie L. Martin

Southern Star Central Gas Pipeline pl James L. Harder Dale Sanders

Southwest Gas Corporation l Larry Black

SunGard Energy Systems s Chuck McClure Jennifer Chen

Telvent s William (Bill) Morrow

Tennessee Valley Authority e Valerie Crockett

Texas Gas Transmission, LLC pl Jeff Bittel

Tiger Natural Gas s Tracy Phillips

Suez Energy Marketing, NA, Inc. s Mark Hodges

TransCanada Pipelines pl Doug Miller

Trinity Apex Solutions, Inc. s Richard (Dick) Couron

UBS Energy LLC s Suzanne Calcagno

Vector Pipeline L.P. pl Amy Bruhn

Washington Gas Light Co. l Adrian Chapman Tim Sherwood

Westfield Gas & Electric Light Dept. l Joyce Bodak

Williams Gas Pipeline pl Dale Davis Ron Mucci

Williston Basin Interstate Pipeline pl Keith Tiggelaar

Wisconsin Public Service Corporation l Patrick Fox


RECOMMENDATION TO NAESB WGQ/RGQ/REQ EXECUTIVE COMMITTEES For Quadrant: Retail Electric Quadrant Retail Gas Quadrant Wholesale Gas Quadrant Requesters: TDTWG - ERCOT_Working Group Request No.: R04030 Request Title: Addition of one new data element to the MIME

content header of the NAESB EDM POST request as Modified by the REQ/RGQ TEIS, and WGQ EDM on February 23, 2005.

10

1. RECOMMENDED ACTION: EFFECT OF EC VOTE TO ACCEPT RECOMMENDED ACTION:

Accept as requested X Change to Existing Practice X Accept as modified below Status Quo Decline

2. TYPE OF MAINTENANCE

Per Request: Per Recommendation:

Initiation Initiation X Modification X Modification Interpretation Interpretation Withdrawal Withdrawal

Principle (x.1.z) Principle (x.1.z) Definition (x.2.z) Definition (x.2.z) Business Practice Standard (x.3.z) Business Practice Standard (x.3.z) X Document (x.4.z) X Document (x.4.z) X Data Element (x.4.z) X Data Element (x.4.z) X Code Value (x.4.z) X Code Value (x.4.z) X12 Implementation Guide X12 Implementation Guide Business Process Documentation X Business Process Documentation

3. RECOMMENDATION SUMMARY:

Add a new mutually agreed data element to the Internet Electronic Transport (Internet ET), “refnum-orig”. By adding this data element and the subsequent changes to the data dictionary, standards manuals and errors and warnings messages, it enables parties using the the Internet ET to build an automated process that if mutually agreed, prevents the reprocessing of retransmitted data.

STANDARDS LANGUAGE:

N/A




11

Standards Book: Internet Electronic Transport:

Make the following changes (underline=addition, strike-through=delete to original text) to the Data Dictionary for Internet ET on page 23:

Business Name Definition Format Usage* Condition

refnum used by the party to assign a unique message identifier unique over all time for tracing purposes. For the Sender, this ID should not be duplicated for resends.

maximum 40 character integer value

in Request; MA

May be used by Sender to send tracking information to a recipient. Use of this data element is by mutually agreed. This data element is conceptually similar to a Message-ID filed within RFC 822.

refnum-orig for original send, refnum-orig is identifical to refnum. for resend, refnum-orig is the refnum of the original package.

maximum 40 character integer value

In Request; MA

Used in conjunction with refnum.

BUSINESS PROCESS DOCUMENTATION (for addition, modification or deletion of business process documentation language)




12

Language: On page 26 under the heading: Sender HTTP Request Data Elements add the following 2 data elements (10 and 11) below number 9:

Mutually Agreed Upon Data Elements 8. transaction-set 9. receipt-security-selection 10 refnum 11 refnum-orig

Language: : On page 24 insert the following text above the paragraph titled, Using an Interactive Browser for Internet ET Use of Refnum and Refnum-orig

These data elements are mutually-agreed, so parties must agree to use these data elements.

The first time a package is sent the refnum and refnum-orig should be identical 40-digit or less integers. The refnum data element is always unique over time.

If a party does not receive the NAESB response, the package should be resent with a new refnum, and with the refnum-orig equal to the original refnum used in the initial transmittal of the package.

Refnum and Refnum-orig Example Package Send refnum refnum-orig

First send 123467890123456 123467890123456 First resend 223467890123457 123467890123456 Second resend 323467890123458 123467890123456




13

Language: On page 48 under the heading: Internet ET Standard Error Codes and Messages Insert the following error messages to the end of the error codes

EEDM120 Mutually agreed element refnum-orig not present

refnum-orig mutually agreed

EEDM121 Duplicate refnum received refnum mutually agreed

Insert the following warning message to the end of the warning codes

WEDM105 Refnum-orig received but not mutually agreed; ignored

refnum-orig mutually agreed

4. SUPPORTING DOCUMENTATION a. Description of Request:

Add a new data element, as requested: refnum-orig

The “refnum” data element contains a transaction identifier from the senders system (transaction id/number). The “refnum” data element is already defined within the NAESB guidelines. Usage is mutually agreed. Data type defined as Integer 40 characters maximum. The requested “refnum-orig” data element would contain a transaction identifier from the senders system (transaction id/number) that referenced the “refnum” of an original attempt to exchange when an exchange failure was received or no response was received for a previous transmission. Usage for “refnum-orig” is mutually agreed. The data type is defined as Integer 40 character maximum to be the same as “refnum”. When using the the “refnum-orig” data element, it will always have a value. On an original POST it would match the “refnum” data element (both numbers are the same number; the original) Additional warning and error messages were requested as follows:

WEDM1XX – refnum-orig received but not expected




14

WEDM1XX – duplicate received EEDM1XX – refnum-orig not received but expected

b. Description of Recommendation:

Request R04030, submitted October 13, 2004, by TDTWG - ERCOT_Working Group proposed a change that would, on a mutually agreed basis, give the ability to build a process to prevent the processing of the retransmitted data preventing the potential overload on a backend system. This process is done by matching the “refnum-orig” transaction number to an id that was received in the initial transmission (ref-num) to determine if the file needs to be processed or simply archive as received data but then not process it.

MOTION:

Adopt the above modifications to the Intenet Electronic Transport, Data Dictionary, Standard Error Codes and Messages, as well as business text necessary to implement R04030.

WGQ EDM Vote Balancing Balanced Balanced Balanced For Against Total Determinant For Against Total End Users 0 0 0 0 0.00 0.00 0LDCs 0 0 0 0 0.00 0.00 0Pipelines 2 0 2 2 2.00 0.00 2Producers 0 0 0 0 0.00 0.00 0Services 1 0 1 1 0.00 0.00 1 3 0 3 3 3.00 0.00 3

RGQ/REQ TEIS Vote Balancing Balanced Balanced Balanced For Against Total Determinant For Against Total End Users 0 0 0 0 0.00 0.00 0Distributors 2 0 2 2 2.00 0.00 2Suppliers 2 0 2 2 2.00 0.00 2Services 2 0 2 2 2.00 0.00 2 6 0 6 6 6.00 0.00 6




15

c. Business Purpose:

This recommendation is the result of a collaborative effort between the REQ/RGQ TEIS and EDM subcommittees that resulted in the subcommittees recommending a revision to the existing RGQ/REQ/WGQ Internet ET that could seamlessly be utilized in both wholesale and retail settings if mutually agreed.

RGQ/REQ TEIS and WGQ EDM Subcommittees

The WGQ EDM and RGQ/REQ TEIS subcommittees met jointly in Richmond, Virginia on February 23, 2005 to clarify issues and to consider proposed changes to the existing jointly developed Internet ET that serves all three Quadrants.

d. Commentary/Rationale of Subcommittee(s)/Task Force(s):

The proposed changes were developed in a consensus-oriented process open to all interested parties. Members from all three impacted Quadrants participated in the discussions. The REQ/RGQ TEIS and WGQ EDM subcommittees reviewed the existing Internet ET and agreed to language that would enable the retail quadrants to benefit from the requested changes without forcing change to an established wholesale market installation.

Please reference the following sets of minutes for further information:

February 23, 2005 http://www.naesb.org/pdf2/req_rgq_teis022305dm.doc

April 21, 2005 http://www.naesb.org/pdf2/req_rgq_teis042105dm.doc


D R A F T W O R K P R O D U C T -- R E T A I L T E I S, 5-27-05

NORTH AMERICAN ENERGY STANDARDS BOARD Retail Electric Quadrant

Retail Gas Quadrant

1100 Louisiana1301 Fannin, Suite 36252350 Houston, Texas 77002

(713) 356-0060 (713) 356-0067 Fax

E-mail: [email protected] www.naesb.org

RETAIL ELECTRIC QUADRANT / RETAIL GAS QUADRANT

QUADRANT-SPECIFIC ELECTRONIC DELIVERY MECHANISM (QEDM)

MODEL BUSINESS PRACTICES

RXQ.5

Copyright © 1996-2004 North American Energy Standards Board, Inc. All rights reserved.

Version 1.0 [Month] [Day] [Year]


R E L E A S E C A N D I D A T E

RXQ.5 RXQ Quadrant-Specific Electronic Delivery Mechanisms

D R A F T W O R K P R O D U C T -- R E T A I L T E I S, 5-27-05 2 of 41

Special Thanks and Acknowledgments to: NAESB REQ AND RGQ MEMBER COMPANIES

For donating significant staff time to coordinate the publication of the ANSI ASC X12 guidelines. NAESB WGQ SUBCOMMITTEES

For support and materials describing the business practices, related data sets, data set organization, data elements and data element formats, implementation guides and mapping.

FORESIGHT CORPORATION

For software used to develop the ANSI ASC X12 transaction sets.

The North American Energy Standards Board (“NAESB”) disclaims and excludes, and any user of the NAESB standard acknowledges and agrees to NAESB’s disclaimer of, any and all warranties, conditions or representations, express or implied, oral or written, with respect to the standard or any part thereof, including any and all implied warranties or conditions of title, non-infringement, merchantability, or fitness or suitability for any particular purpose (whether or not NAESB knows, has reason to know, has been advised, or is otherwise in fact aware of any such purpose), whether alleged to arise by law, by reason of custom or usage in the trade, or by course of dealing. Each user of the standard also agrees that under no circumstances will NAESB be liable for any special, incidental, exemplary, punitive or consequential damages arising out of any use of, or errors or omissions in, the standard.





1 – EXECUTIVE SUMMARY Provides a brief outline of this guide and the industry context for its use

This North American Energy Standards Board (NAESB) Retail Electric Quadrant (REQ) and Retail Gas Quadrant (RGQ) Quadrant-Specific Electronic Delivery Mechanism (QEDM) General Standards Model Business Practice manual details high-level model business practices that apply to all REQ/RGQ (RXQ) electronic delivery business practices. The QEDM model business practices establish the framework for the electronic dissemination and communication of information between parties in the North American retail gas and electric marketplaces. Specifically, the Retail Electric Quadrant Gas and the Retail Gas Quadrant of the North American Energy Standards Board haves standardized five several methods of communication that can be implemented by market participants. The five methods are:

1. EDI/EDM Transfer - The transfer of EDI files, as defined by the ANSI-based NAESB REQ/RGQ WGQ file formats standardsmodel business practices, transferred via the Internet using the NAESB Internet Electronic Transport (Internet ET) mechanism.

2. FF/EDM Transfer - The transfer of "flat files", as defined by the NAESB REQ/RGQ WGQ file formats standardsmodel business practices, transferred via the Internet using the NAESB Internet ET mechanism.

For each of these areas, this document provides a high-level guide to development, implementation, and testing. This guide is not intended to be a comprehensive, in-depth manual.





2 – VERSION NOTES Contains notes about the current version and a summary of changes from preceding versions

Date Version Summary of Change

5/27/05 Version 1





3 – INTRODUCTION Provides a background statement about NAESB’s Mission and the design of this guide

NAESB is a voluntary, non-profit organization comprised of members from all aspects of the energy industry. Within NAESB, the Retail Electric Quadrant (REQ) and the Retail Gas Quadrant (RGQ) focus on issues impacting the retail sale of energy to end-use customers. REQ/RGQ Model Business Practices are intended to provide guidance to Distribution Companies, Suppliers, and other Market Participants involved in providing competitive energy services to end-use customers. The focus of these Model Business Practices are Electric Delivery Mechanisms (EDMs).

NAESB Model Business Practices are voluntary and do not address policy issues that are the subject of state legislation or regulatory decisions. NAESB’s mission is to take the lead in developing and implementing standards across the energy industry to simplify and expand electronic communication, and to streamline business practices. This will lead to a seamless North American energy marketplace, as recognized by its customers, the business community, industry participants and regulatory bodies.

NAESB standardsmodel business practices are written as ‘minimums’. A trading party may offer to ‘exceed the minimum standardmodel business practice’ by offering additional functions or features as options, but should not require their use. Such additional features or functions are termed “mutually agreed to” in that, if both trading partners agree on the inclusion, the additional feature requirements will be met. However, if either trading party does not agree to the inclusion of additional features, then the partners must allow for transmission and receipt of data using the minimum standardsmodel business practices. NAESB defines ‘exceed the minimum standardmodel business practice’ to mean surpassing the standardsmodel business practices without negative impact on contracting and non-contracting parties.

All of the standardsmodel business practices have been adopted with the anticipation that as the industry evolves and uses the standardsmodel business practices, additional and amended NAESB standardsmodel business practices will be necessary. Any industry participant seeking additional or amended standardsmodel business practices (including principles, definitions, standardsmodel business practices, data elements, process descriptions, technical implementation instructions) should submit a request to the NAESB office detailing the change so that the appropriate process may take place to amend the standardsmodel business practices. Standards are grouped in books according to activity in the retail market. Each book is organized according to the outlined below:








4 – BUSINESS PROCESSES AND PRACTICES Provides an overview of business processes and NAESB RXQ approved principles, definitions and model business practices related to this guide

5 – RELATED MODEL BUSINESS PRACTICES Provides an overview of related model business practices A. Internet Electronic Transport (ET) B. Entity Common Code C. Trading Partner Agreement

6 – TECHNICAL IMPLEMENTATION Provides quadrant-specific information related to the implementation of different electronic delivery mechanisms A. General Electronic Delivery Mechanism B. X12 Electronic Data Interchange (EDI/EDM) C. Flat-file (FF/EDM) D. Interactive Flat-file (FF/EDM) E. Electronic Bulletin Board (EBB/EDM) F. Web (Web/EDM) G. XML (XML/EDM) H. Web Services (WS/EDM)

7 – TESTING AND DEPLOYMENT Provides an overview of the testing model business practices for RXQ implementations

8 – APPENDICES

A – Reference Guide B – Frequently Asked Questions C – Sample Technical Exchange Worksheet (TEW) D – RXQEDM / Internet ET 2.0 Cross-Reference




4 – BUSINESS PROCESSES AND PRACTICES





Provides an overview of business processes and NAESB RXQ approved principles, definitions and model business practices related to this guide

5 – RELATED MODEL BUSINESS PRACTICES Provides an overview of related model business practices A. Internet Electronic Transport (ET) B. Entity Common Code C. Trading Partner Agreement

6 – TECHNICAL IMPLEMENTATION Provides quadrant-specific information related to the implementation of different electronic delivery mechanisms A. General Electronic Delivery Mechanism B. X12 Electronic Data Interchange (EDI/EDM) C. Flat-file (FF/EDM) D. Interactive Flat-file (FF/EDM) E. Electronic Bulletin Board (EBB/EDM) F. Web (Web/EDM) G. XML (XML/EDM) H. Web Services (WS/EDM)


8 – APPENDICES

A – Reference Guide B – Frequently Asked Questions C – Sample Technical Exchange Worksheet (TEW) D – RXQEDM / Internet ET 2.0 Cross-Reference





4 – BUSINESS PROCESSES AND PRACTICES

Provides an overview of business processes and NAESB RXQ approved principles, definitions and model business practices related to this guide

1. Principles RXQ.0RXQ.5.1.12 There should be a unique Entity Common Code for each Entity name and

there should be a unique Entity name for each Entity Common Code.

RXQ.0RXQ.5.1.23 RXQ standardsmodel business practices do not pick winners, but rather create an environment where the marketplace can dictate a winner(s).

RXQ.0RXQ.5.1.34 RXQ solutions should be cost effective, simple and economical.

RXQ.0RXQ.5.1.45 RXQ solutions should provide for a seamless marketplace for energy.

RXQ.0RXQ.5.1.56 Electronic communications between parties should be done on a non-discriminatory basis, whether through an agent or directly with any party.

RXQ.0RXQ.5.1.67 Trading Partners should mutually select and use a version of the NAESB RXQ standardsmodel business practices under which to operate, unless specified otherwise by the Applicable Regulatory Authority.government agencies. Trading Partners should also mutually agree to upgrade or adopt later versions of RXQ standardsmodel business practices as needed, unless specified otherwise by the Applicable Regulatory Authoritygovernment agencies.

RXQ.0RXQ.5.1.78 Market participantTrading Partners s should post clear and precise business processing rules at a designated site, and/or in writing upon request.

RXQ.0RXQ.5.1.89 For Electronic Delivery Mechanisms (EDM), there should be at least one standard automated computer-to-computer exchange of transactional data for each defined transaction data exchange format.

RXQ.0RXQ.5.1.910 For EDM, transaction content and usage should reasonably correspond to defined data dictionaries regardless of mechanism, e.g. FF/EDM, EDI/EDM, etc.

RXQ.0RXQ.5.1.101 For EDM, automated business processes should use Internet ET. 2. Glossary RXQ maintains this glossary of definitions as the central location for definitions used throughout all RXQ standards books. These definitions are may be echoed in this each book for convenience. Where there are discrepancies due to editing or maintenance, definitions in this RXQ.0 RXQ Glossary are official.

Glossary Term StandardModel

Business Practice

Definition

Batch Flat-file [TBD] The term used within the FF/EDM to describe tThe automated computer-to-computer transfer of Flat-files.

Business Rule Change [TBD] Any change in: Aa) change in the presence and/or the acceptable content of a

data element sent by the changing party, Bb) a new business response to an





Glossary Term StandardModel

Business Practice

Definition

accepted data element received by the changing party; Cc) a new business response to the acceptable content of a data element received by the changing party; Dd) a new intended business result.

D-U-N-S® Number

The D-U-N-S® Number is a 9-digit number assigned to companies by the Dun & Bradstreet Corporation .The D-U-N-S®+4 Number is a 10- to 13-digit number, where characters 10 through 13 are arbitrarily assigned by the owner of the D-U-N-S® Number.

EDI/EDM [TBD]

Electronic Data Interchange/Electronic Delivery Mechanism. The term used to describe Describes ANSI ASC X12 computer-to-computer electronic data interchange of information in files as mapped from RXQ.the x.4.z RXQ standardmodel business practices in the NAESB RXQ Implementation Guides and communicated between trading partners over the Internet using the NAESB Internet Electronic Transport (ET).

Entity [TBD]

A person or organization with sufficient legal standing to enter into a contract or arrangement with another such person or organization (as such legal standing may be determined by those parties) for the purpose of conducting and/or coordinating energy transactions.

Entity Common Code [TBD]

The DUNS® or DUNS+4 number used as the common company identifier, including D-U-N-S® or D-U-N-S®+4 Number. The DUNS number is a 9-digit number assigned to companies by the Dun & Bradstreet Corporation (D&B). The DUNS+4 number is a 10- to 13-digit number, where characters 10 through 13 are arbitrarily assigned by the owner of the DUNS number. Entity common codes should be ‘legal entities,’ that is, Ultimate Location, Headquarters Location, and/or Single Location (in Dun &Bradstreet terms).

FF/EDM [TBD] Flat File/Electronic Delivery Mechanism. The term used to dDescribes a standardized Fflat-file electronic data interchange of information in files as mapped from the RXQ. x.4.z RXQ standardmodel business practices.

Flat-file [TBD] An RXQEDM Flat-file is an ASCII comma-separated-value (CSV) file with the characteristics as defined in the RXQEDM standardmodel business practices.

Interactive Flat-file [TBD] Describes theThe term used within the FF/EDM to describe the transfer of Flat-

files using an interactive browser.

RXQEDM [TBD] Electronic Delivery Mechanism standardmodel business practices for the NAESB RGQ and REQ quadrants that govern package payload file contents, including X12 EDI, Flat-file and other formats.

Testing [TBD]

Verification that trading partners have the system capabilities in place forTesting between trading partners includes testing of: (Aa) intended business results, (Bb) proposed electronic transport, including security, enveloping, cryptography; and (Cc) electronic Electronic delivery Delivery mechanisms Mechanisms (xxxEDI/EDM or FF/EDM), including data validity, standardmodel business practices compliance, etc.

Trading Partner [TBD] A party that enters into an agreement with another party to transact business electronically using NAESB standardmodel business practices.

Translator [TBD] A program or set of programs that process the contents of payloads, applying ANSI X12 and other standardmodel business practices, and transforms the information to other formats.




D R A F T W O R K P R O D U C T -- R E T A I L T E I S, 5-27-05 1

3. Model Business Practices RXQ.5.3.0.1 Entity common codes should be ‘legal entities’, that is, Ultimate Location,

Headquarters Location, and/or Single Location in Dun & Bradstreet Corporation (D&B) terms. However, in the following situations, a Branch Location, in D&B terms, can also be an entity common code: 1) when contracting party provides a DUNS® number at the Branch Location level; OR 2) to accommodate accounting for an entity that is identified at the Branch Location level. ............................... 232

RXQ.5.3.2.1 RXQEDM relies on the NAESB Internet ET to enforce the privacy, authentication, integrity, and non-repudiation (PAIN) security principles................................... 131

RXQ.5.3.2.2 All RXQEDM payloads should be encrypted with a minimum 128-bit key when sent on unsecured networks (Internet). This encryption is built into transportation using the NAESB Internet ET. Where other transport options are used, a 128-bit Secure Sockets Layer (SSL) encryption should be used. ................................. 131

RXQ.5.3.2.3 Trading partners should retain transaction data for at least 24 months for audit purposes or as specified by Applicable Regulatory Authority............................ 131

RXQ.5.3.2.4 Timestamps that indicate the time transactions were received by a party should be the ‘time-c’ timestamp from the Internet ET Response. ............................... 232

RXQ.5.3.2.5 RGQ and REQ require the use of the Internet ET Response ‘time-c-qualifier’ data element to identify the time-zone of the Receiver’s timestamp. ........................ 232

RXQ.5.3.2.6 Timestamps used within RXQEDM transactions should be generated using clocks that are synchronized with the localized prevailing National Institute of Standards and Technology (NIST) time to mitigate discrepancies between the clocks of the Sender and Receiver. Computer clocks should be synchronized as often as necessary to ensure a +/- 5 second variance with an atomic clock. Specific business processes may have tighter synchronization requirements.. 232

RXQ.5.3.2.7 When Internet ET is used, the Internet ET Receipt timestamp supersedes any EDM timestamps with respect to official time the document was received by the Receiver. ...........................................................................................................232

RXQ.5.3.2.8 When Internet ET is not used, the receipt timestamp is defined by each specific EDM. .................................................................................................................232

RXQ.5.3.2.9 RXQEDM ‘date’ data elements should be formatted as YYYYMMDD. .............232 RXQ.5.3.2.10 RXQEDM ‘time’ data elements should be specified in a 24 hour format, formatted

as HH:MM or HH:MM:SS. .................................................................................232 RXQ.5.3.2.11 RXQEDM ‘date/time’ data elements that have date and time expressed in one

data element should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS, with exactly one space between the day (DD) and the hour (HH). 232

RXQ.5.3.2.12 Where they exist for the same business function, Flat-files, EDI and other EDMs should use the same nomenclature for data set names, data element names, code values and/or code value descriptions, abbreviations and message text. 232

RXQ.5.3.2.13 Trading partners should use common codes for legal entities for RXQEDM envelope data elements. ...................................................................................332





RXQ.5.3.2.15 To the extent that multiple EDMs are used (e.g. EDI or Flat-files), the same business result should occur. ................................................................................ 3

RXQ.5.3.2.16 Non-NAESB Internet ET packages (e.g. PDF files) will have the ‘input-format’ tag set to ‘PAYLOAD’ to indicate the format is found in the payload MIME segment. Inside the MIME segment and the ‘content-type’ header will be set to an appropriate MIME content type. ............................................................................ 3

RXQ.5.3.3.1 NAESB is a member of ANSI and will strive to remain fully-compliant with ANSI ASC X12 standards...........................................................................................434

RXQ.5.3.3.2 EDI Translators generate the ASC X12 file, including control numbers and counts that will appear within the ISA/IEA outer envelope segments, and within the GS/GE inner envelope segments. .....................................................................434

RXQ.5.3.3.3 The ISA is the interchange control segment to be used on all NAESB X12 model business practices.............................................................................................434

RXQ.5.3.3.4 The Receiver should send a 997 FA for each X12 file received........................ 636 RXQ.5.3.3.5 Inbound EDI transactions should be processed every day business is conducted.

The 997 should be sent within one day of business, as defined by the Receiver, of the receipt of the X12 file...............................................................................636

RXQ.5.3.3.6 When Internet ET is used, the Internet ET receipt timestamp is the official receipt timestamp. Without Internet ET, the 997 timestamp is the official receipt timestamp..........................................................................................................636

RXQ.5.3.3.7 RXQEDM uses X12 Version 4010 standards unless otherwise noted. ............. 636 RXQ.5.3.4.1 FF/EDM records are separated by a carriage return/line feed (CRLF or \r\n or

ASCII 10 and 13). ..............................................................................................737 RXQ.5.3.4.2 The first record of an FF/EDM Flat-file should be the standard abbreviations for

RXQ data elements in the order the corresponding data appears in subsequent rows. The data element order is at the option of the sender. ........................... 737

RXQ.5.3.4.3 If an FF/EDM Flat-file data element abbreviation is not recognized, the entire Flat-file should be rejected. ...............................................................................737

RXQ.5.3.4.4 Each transaction (e.g. Enrollment) should be contained in a single FF/EDM Flat-file record...........................................................................................................737

RXQ.5.3.4.5 FF/EDM data elements are separated by commas. ..........................................737 RXQ.5.3.4.6 FF/EDM data elements that may contain a comma should be enclosed by

double-quotes....................................................................................................737 RXQ.5.3.4.7 FF/EDM data elements should not contain double-quotes................................ 737 RXQ.5.3.4.8 FF/EDM data elements that contain negative numbers should have the minus

sign precede the number...................................................................................737 RXQ.5.3.4.9 FF/EDM data elements that contain decimal precision should include the decimal

point within the data element.............................................................................737 RXQ.5.3.4.10 FF/EDM data elements that contain numeric data with one or more significant

leading zeros should preserve these zeros within the data element. ................ 737





RXQ.5.3.4.11 FF/EDM ‘date’, ‘time’, and ‘date/time’ data elements should conform to RXQEDM and ISO model business practices: date=YYYYMMDD, time=HH:MM:SS, date/time=YYYYMMDD HH:MM:SS..................................................................737

RXQ.5.3.4.12 FF/EDM data elements should be no longer than 256 characters. ................... 837 RXQ.5.3.4.13 FF/EDM Flat-files should not contain mixed record formats in a single file (e.g. a

single file with both Enrollments and Invoices)..................................................838 RXQ.5.3.4.14 FF/EDM payloads should be encrypted prior to Internet transport when not using

Internet ET. SSL encryption is sufficient...........................................................838 RXQ.5.3.4.15 Transactions sent using FF/EDM should produce the same business result as

other EDMs (e.g. EDI/EDM). .............................................................................838 RXQ.5.5.1.1 When a party implements a Business Rule Change that will apply to documents,

changes systems used to process transactions, or changes third-party service providers, it should notify its trading partners at least thirty (30) days in advance of the change(s). The notification should identify the nature of the changes being made, the data element(s) that are changing, the intended business result of such change(s) in the business rule(s), and the scheduled effective date of such change(s). .........................................................................................................131

RXQ.5.5.1.2 Trading partners implementing changes should provide testing of change(s) prior to the implementation of the change(s). ............................................................131

RXQ.5.5.1.3 Trading partners are permitted to cancel or postpone scheduled changes. Notice of cancellation or postponement should be provided to trading partners at least one business day prior to the scheduled effective date.....................................131

RXQ.5.5.1.4 Trading partners should use dedicated testing systems that mirror production systems. ............................................................................................................131

4. Interpretations NAESB has no interpretations of standardmodel business practices that relate to RXQEDM.





5 – RELATED STANDARDSMODEL BUSINESS PRACTICES

Provides an overview of related model business practices

A. INTERNET ELECTRONIC TRANSPORT (ET)

In NAESB business processes, the RXQEDM standardmodel business practices are generally used in conjunction with the Internet ET transport standardmodel business practices.

Related Definitions from Internet ET These definitions are used in this document. For exact definitions, please refer to the Internet ET standardmodel business practices manual.

[10].2.13 ‘Electronic Package’. A data stream sent via HTTP POST that contains envelope header information and Payload File(s). The Payload Files are encrypted using defined Internet ET encryption techniques.

[10].2.20 ‘Internet EDM’. The GISB and NAESB WGQ standards up to and including Version 1.7. ‘Internet ET’ standards and ‘RXQEDM’ standardmodel business practices are derived from these EDM standards.

[10].2.24 ‘Exchange Failure’. An exchange failure is when a sending party’s NAESB Internet ET server has had three or more protocol failures over a period of time no less than thirty minutes and no more than two hours.

[10].2.25 ‘QEDM’. Quadrant-specific Electronic Delivery Mechanism; the set of standards or model business practices for each NAESB quadrant that define the EDM standards/model business practices for EDI, Flat-files, electronic bulletin boards, and other technologies. The QEDM excludes electronic transport practices and standards. The QEDMs were derived from the GISB and NAESB WGQ Internet EDM standards.

[10].2.26 ‘Receipt’. The HTTP Response sent from the Receiver to the Sender that includes the ‘gisb-acknowledge-receipt’ section with a timestamp and OK/error status.

[10].2.30 ‘Technical Exchange Worksheet’ or ‘TEW’. A document or worksheet used to communicate important information related to the technical implementation of Internet ET; includes information such as URLs, contacts and Public Key policies.

Related Standards from Internet ET [10].3.5 A timestamp designates the time a file is received at the Receiver’s designated

site. The timestamp consists of the ‘time-c’ data element, and in some cases the ‘time-c-qualifier’ data element. Refer to QEDM standardmodel business practices for use of the ‘time-c-qualifier’.





B. ENTITY COMMON CODE

REQ and RGQ use the DUNS® or DUNS+4 number as the common company identifier for the HTTP Request and Response data dictionary ‘to’ and ‘from’ HTTP header elements. The DUNS® number is a 9-digit number assigned to companies by the Dun & Bradstreet Corporation (D&B). The DUNS+4® number is a 10- to 13-digit number, where characters 10 through 13 are arbitrarily assigned by the owner of the DUNS® number. For RXQEDM Common Code purposes, an entity will use one and only one DUNS® number. Entity common codes should be ‘legal entities,’ that is, Ultimate Location, Headquarters Location, and/or Single Location (in D&B terms). However, in the following situations, a Branch Location (in D&B terms) can also be an entity common code: 1. When the contracting party provides a DUNS® number at the Branch Location level. 2. To accommodate accounting for an entity that is identified at the Branch Location level. Since D&B offers customers the option of carrying more than one DUNS® number per entity, please refer to NAESB’s Web Page for directions on determining the one and only one DUNS® number constituting the NAESB Entity Common Code.

RXQ.0RXQ.5.1.2 There should be a unique entity common code for each entity name and there should be a unique entity name for each entity common code.

RXQ.0RXQ.5.3.0.1 Entity common codes should be ‘legal entities’, that is, Ultimate Location, Headquarters Location, and/or Single Location in Dun & Bradstreet Corporation (D&B) terms. However, in the following situations, a Branch Location, in D&B terms, can also be an entity common code: 1) when contracting party provides a DUNS® number at the Branch Location level; OR 2) to accommodate accounting for an entity that is identified at the Branch Location level.

C. TRADING PARTNER AGREEMENT

Importance of the Trading Partner Agreement When Using Internet ET and WGQ QEDM

The Trading Partner Agreement (TPA) specifies what functions each party should perform in electronic transactions. The QEDM contains an optional Technical Exchange Worksheet in the appendix that outlines basic QEDM information between trading partners. Additionally, the Internet ET contains an optional Technical Exchange Worksheet that outlines basic connectivity information between trading partners. The specifications in the TPA should be tested before reliance on the production implementation for business transactions.





6 – TECHNICAL IMPLEMENTATION Provides quadrant-specific information related to the implementation of different electronic

delivery mechanisms

A. GENERAL ELECTRONIC DELIVERY MECHANISM

Open Standards

The “open” technology standards selected by NAESB WGQ are designed to provide flexibility and scalability. The business benefits gained from adherence to open standards are:

• Provides the framework to electronically trade with others (e.g., electric utilities, banks, suppliers, retail customers).

• Encourages marketplace development of off-the-shelf software solutions to support NAESB WGQ QEDM.

• Strengthens security and integrity of electronic communication.

Privacy/Authentication/Integrity/Non-repudiation

RXQ.0RXQ.5.3.2.1 RXQEDM relies on the NAESB Internet ET to enforce the privacy, authentication, integrity, and non-repudiation (PAIN) security principles.

RXQ.0RXQ.5.3.2.2 All RXQEDM payloads should be encrypted with a minimum 128-bit key when sent on unsecured networks (Internet). This encryption is built into transportation using the NAESB Internet ET. Where other transport options are used, a 128-bit Secure Sockets Layer (SSL) encryption should be used.

Audit Trails

RXQ.0RXQ.5.3.2.3 Trading partners should retain transaction data for at least 24 months for audit purposes or as specified by Applicable Regulatory Authority.. This data retention requirement does not otherwise modify statutory, regulatory, or contractual record retention requirements.

Receipt Timestamps Similar to certified postal mail, many Senders are interested in knowing that their document was received, and at what time the document was received. One aspect of ‘non-repudiation’ says that the Receiver cannot deny receiving the document. The use of an electronic receipt provides the Sender with a level of non-repudiation. The primary timestamp in NAESB standardmodel business practices is the ‘time-c’ data element found in the ‘gisb-acknowledgement-receipt’ in Internet ET Responses. When Internet ET is used, this timestamp should serve as the primary timestamp for non-repudiation purposes.





When Internet ET is not used, refer to each EDM for the receipt convention. EDI/EDM uses the date and timestamps in the ISA segment. FF/EDM does not have any current timestamp standardmodel business practices.

RXQ.0RXQ.5.3.2.4 Timestamps that indicate the time transactions were received by a party should be the ‘time-c’ timestamp from the Internet ET Response.

RXQ.0RXQ.5.3.2.5 RGQ and REQ require the use of the Internet ET Response ‘time-c-qualifier’ data element to identify the time-zone of the Receiver’s timestamp.

RXQ.0RXQ.5.3.2.6 Timestamps used within RXQEDM transactions should be generated using clocks that are synchronized with the localized prevailing National Institute of Standards and Technology (NIST) time to mitigate discrepancies between the clocks of the Sender and Receiver. Computer clocks should be synchronized as often as necessary to ensure a +/- 5 second variance with an atomic clock. Specific business processes may have tighter synchronization requirements.

When Internet ET is used, Internet ET timestamps take precedence over EDM timestamps such as those found in the EDI 997. When Internet ET is not used, other timestamps are defined by the EDM (e.g. EDI/EDM or FF/EDM).

RXQ.0RXQ.5.3.2.7 When Internet ET is used, the Internet ET Receipt timestamp supersedes any EDM timestamps with respect to official time the document was received by the Receiver.

RXQ.0RXQ.5.3.2.8 When Internet ET is not used, the receipt timestamp is defined by each specific EDM.

ISO Date and Time Data Elements RXQEDM data elements should use the following date and time standardmodel business practices:

RXQ.0RXQ.5.3.2.9 RXQEDM ‘date’ data elements should be formatted as YYYYMMDD.

RXQ.0RXQ.5.3.2.10 RXQEDM ‘time’ data elements should be specified in a 24 hour format, formatted as HH:MM or HH:MM:SS.

RXQ.0RXQ.5.3.2.11 RXQEDM ‘date/time’ data elements that have date and time expressed in one data element should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS, with exactly one space between the day (DD) and the hour (HH).

Other

RXQ.0RXQ.5.3.2.12 Where they exist for the same business function, Flat-files, EDI and other EDMs should use the same nomenclature for data set names, data element names, code values and/or code value descriptions, abbreviations and message text.





RXQ.0RXQ.5.3.2.13 Trading partners should use common codes for legal entities for RXQEDM envelope data elements.

RXQ.0.3.2.14 Requests for standardization of additional services and/or data elements should be submitted to the appropriate NAESB quadrant Executive Committee.

RXQ.0RXQ.5.3.2.15 To the extent that multiple EDMs are used (e.g. EDI or Flat-files), the same business result should occur.

Internet Electronic Transport for Non-NAESB Packages RXQEDM supports use of Internet ET for transportation of files other than EDI X12 and flat-files. Examples may include reports, load profiles and PDF files. Current Internet ET standards do not accommodate efficient processing of these formats. The following standardmodel business practice enables receiving companies to efficiently support these conventions, and eliminates NAESB intervention when a new type of file is to be transmitted. Non-NAESB payloads sent using RXQEDM standardmodel business practices should have the following information in the header:

• Internet ET ‘input-format’ data element = ‘PAYLOAD’. This indicates that the format for the file is found in the MIME payload segment.

• MIME header ‘content-type’ data element = appropriate MIME content-type.

RXQ.0RXQ.5.3.2.16 Non-NAESB Internet ET packages (e.g. PDF files) will have the ‘input-format’ tag set to ‘PAYLOAD’ to indicate the format is found in the payload MIME segment. Inside the MIME segment and the ‘content-type’ header will be set to an appropriate MIME content type.





B. X12 ELECTRONIC DATA INTERCHANGE (EDI/EDM)

ANSI ASC X12 Standards RXQ standardmodel business practices reflect industry use of the American National Standards Institute (ANSI) ASC X12 standards maintained by the Data Interchange Standards Association, Inc. (DISA). Parties using RXQ X12 EDI standards should have a copy of the ANSI ASC X12 Standards Reference document for a full understanding of the X12 requirements. NAESB members may purchase an ANSI reference document through NAESB by contacting the NAESB office. Non-NAESB industry participants may purchase the reference document by contacting the Manager of Publications at DISA (www.disa.org, 703.548.7005) RXQ EDI technical implementation documents are subsets of ANSI ASC X12 standards.

RXQ.0RXQ.5.3.3.1 NAESB is a member of ANSI and will strive to remain fully-compliant with ANSI ASC X12 standards.

RXQ.0.3.3.2 RXQ EDI/EDM standards are X12 compliant. RXQ.0.3.3.3 Where the X12 standard does not fully meet a need, NAESB will add interim usages and code values when required. When used, NAESB will submit interim usage/code values to ANSI and the appropriate ANSI organizations for acceptance of the interim solution. ANSI’s final solution may provide a usage or code value different from the interim solution. NAESB standardmodel business practices will be updated to reflect the final solution. ASC X12 architecture is designed for fully-automated and auditable end-to-end communications.

RXQ.0RXQ.5.3.3.24 EDI Translators generate the ASC X12 file, including control numbers and counts that will appear within the ISA/IEA outer envelope segments, and within the GS/GE inner envelope segments.

These numbers and counts are part of the inner and outer envelopes that allow the translator to ensure that all of the segments and all of the data elements have been received and that the transmission was complete.

ISA Outer Envelope The ISA segment marks the beginning of an X12 document. It can be equated to an envelope that a paper document would come in via the mail. The envelope may contain one or more ‘inner envelope’ functional groups (defined by the GS segment) and one or more transaction sets.

RXQ.0RXQ.5.3.3.35 The ISA is the interchange control segment to be used on all NAESB X12 standardmodel business practices.

The ISA segment identifies the sender and receiver of the document. The Interchange Sender ID/Interchange Receiver ID is published by both the sender and receiver for other parties to use





as the sender/receiver ID to route data to them. The sender must always code the sender’s ID in the sender element and the designated receiver’s ID in the receiver ID. This sender and receiver information is specified in the Technical Exchange Worksheet (TEW) or a Trading Partner Agreement. There are additional elements in the ISA segment. These elements are traditionally assigned by the sending party’s translator. These elements inform the receiver of the date/time that the envelope was generated, the X12 version number being utilized, whether the transmission is for test or production purposes, and what characters were used to designate the end of a sub element, element or segment. The ISA also defines characters for the sub element (ISA position character 105), element (ISA character position 4), and segment delimiters (ISA character position 106). These delimiting characters must never appear in the data. The ISA is the only fixed-length X12 segment as it uses specific positions in the segment to identify the delimiter characters. The Technical Exchange Worksheet (TEW) provides a section for parties to define their default delimiters. However, receiving parties should always check the above ISA character positions for EDI/EDM delimiters. An outer envelope always begins with an ISA segment and ends with an IEA segment.

GS/GE ‘Functional Group Header/Trailer’ Inner Envelopes The GS segment indicates the beginning of a functional group and provides control information for the data that follows it. A functional group can be defined as a group of transactions related to one business application. An inner envelope always begins with a GS segment and ends with a GE segment. An outer envelope may have multiple inner envelopes. For example, within an ISA outer envelope, there may be a GS inner envelope of enrollments and a second GS inner envelope of drops. Each of these inner envelopes is sent within its own GS ‘Functional Group Header’ and a GE ‘Functional Group Trailer’. The Sender provides the Application Sender’s Code that the Receiver will reflect back on acknowledging documents. The Receiver provides the Application Receiver’s Code that the Sender will include in the transmission for the Receiver to use in routing to internal applications. Group Control Numbers are originated and maintained by the Sender of the document.

997 ‘Functional Acknowledgment’ The 997 ‘Functional Acknowledgment (FA)’ transaction set is used to indicate the results of the syntactical analysis of contents of an X12 file, including the ISA/IEA outer envelope, the GS/GE functional groups, and the transaction sets (ST/SE). The 997 FA standard covers all of the X12 and NAESB standardmodel business practice criteria that the receiver of the document has incorporated into the receiver’s translator. The translator may be set to accept all information into the receiver’s application processing, it may be set to accept only ANSI ASC X12 compliant information into the receiver’s application processing, or it may be set to accept only ANSI ASC X12 and NAESB compliant information into the receiver’s





application processing. Compliance checking in a translator may be set to any of several levels. NAESB recommends that compliance checking be set to the element level in the Functional Acknowledgement. The 997 informs the originator of the transaction whether the translator accepted the file, accepted it with errors, or rejected it. When errors occur, the 997 identifies the location and type of error that was encountered. Once a transaction passes the translator, the 997 is sent to the originator of the transaction and the data (if accepted) is passed on to the receiver’s business application for processing.

RXQ.0RXQ.5.3.3.46 The Receiver must should send a 997 FA for each X12 file received.

RXQ.0RXQ.5.3.3.57 Inbound EDI transactions should be processed every day business is conducted. The 997 should be sent within one day of business, as defined by the Receiver, of the receipt of the X12 file.

The 997 includes a timestamp of when the file was translated.

RXQ.0RXQ.5.3.3.68 When Internet ET is used, the Internet ET receipt timestamp is the official receipt timestamp. Without Internet ET, the 997 timestamp is the official receipt timestamp.

The 4010 version of X12 standards was the Year 2000 compliant-version of the standards. Note that in this standard the ISA date elements only have a 2-digit year format.

RXQ.0RXQ.5.3.3.79 RXQEDM uses X12 Version 4010 standards unless otherwise noted.





C. FLAT-FILE (FF/EDM)

The FF/EDM provides a common set of guidelines for the exchange of transactions formatted as a Flat-files. ‘Flat-file’ is a commonly-used description of files that have records of a single record structure. While Flat-files are almost always text files, text files are not always Flat-files. While comma-separated-value (CSV) files are often Flat-files, they can also be of different record structures. The NAESB FF/EDM standardmodel business practices attempt to make it easy to create Flat-files using a spreadsheet without significant programming.

FF/EDM StandardModel business practices:

RXQ.0RXQ.5.3.4.1 FF/EDM records are separated by a carriage return/line feed (CRLF or \r\n or ASCII 10 and 13).

RXQ.0RXQ.5.3.4.2 The first record of an FF/EDM Flat-file should be the standard abbreviations for RXQ data elements in the order the corresponding data appears in subsequent rows. The data element order is at the option of the sender.

RXQ.0RXQ.5.3.4.3 If an FF/EDM Flat-file data element abbreviation is not recognized, the entire Flat-file should be rejected.

RXQ.0RXQ.5.3.4.4 Each transaction (e.g. Enrollment) should be contained in a single FF/EDM Flat-file record.

RXQ.0RXQ.5.3.4.5 FF/EDM data elements are separated by commas.

RXQ.0RXQ.5.3.4.6 FF/EDM data elements that may contain a comma should be enclosed by double-quotes.

RXQ.0RXQ.5.3.4.7 FF/EDM data elements should not contain double-quotes.

RXQ.0RXQ.5.3.4.8 FF/EDM data elements that contain negative numbers should have the minus sign precede the number.

RXQ.0RXQ.5.3.4.9 FF/EDM data elements that contain decimal precision should include the decimal point within the data element.

RXQ.0RXQ.5.3.4.10 FF/EDM data elements that contain numeric data with one or more significant leading zeros should preserve these zeros within the data element.

RXQ.0RXQ.5.3.4.11 FF/EDM ‘date’, ‘time’, and ‘date/time’ data elements should conform to RXQEDM and ISO standardmodel business practices: date=YYYYMMDD, time=HH:MM:SS, date/time=YYYYMMDD HH:MM:SS.





RXQ.0RXQ.5.3.4.12 FF/EDM data elements should be no longer than 256 characters.

RXQ.0RXQ.5.3.4.13 FF/EDM Flat-files should not contain mixed record formats in a single file (e.g. a single file with both Enrollments and Invoices).

RXQ.0RXQ.5.3.4.14 FF/EDM payloads should be encrypted prior to Internet transport when not using Internet ET. SSL encryption is sufficient.

RXQ.0RXQ.5.3.4.15 Transactions sent using FF/EDM should produce the same business result as other EDMs (e.g. EDI/EDM).





D. INTERACTIVE FLAT-FILE (FF/EDM)

No RXQEDM business processes currently use interactive Flat-files.

E. ELECTRONIC BULLETIN BOARD (EBB/EDM)

No RXQEDM business processes currently use electronic bulletin boards.

F. WEB (WEB/EDM)

No RXQEDM business processes currently use web pages.

G. XML (XML/EDM)

No RXQEDM business processes currently use XML.

H. WEB SERVICES (WS/EDM)

No RXQEDM business processes currently use web services.






Testing and deployment is necessary any time a party introduces and updates their systems. Each party determines the level of testing required for a given implementation. In some cases Governing Documents dictate testing requirements.

RXQ.0RXQ.5.5.1.1 When a party implements a Business Rule Change that changes the business rule(s) it will apply to documents, changes systems used to process transactions, or changes third-party service providers, it should notify its trading partners at least thirty (30) days in advance of the change(s). The notification should include identify the nature of the changes being made, the identification of the data element(s) that are changing, the intended business result of such change(s) in the business rule(s), and the scheduled effective date of such change(s).

RXQ.0RXQ.5.5.1.2 Trading partners implementing changes Business Rule Changes should provide testing of change(s) prior to the implementation of the change(s).

RXQ.0RXQ.5.5.1.3 Trading partners are permitted to cancel or postpone scheduled changes. Notice of cancellation or postponement should be provided to trading partners at least one business day prior to the scheduled effective date.

RXQ.0RXQ.5.5.1.4 Trading partners should use dedicated testing systems that mirror production systems.

Additional testing requirements can be found in either A) the Internet ET standard, or B) the specific standardmodel business practice for the business process(es) to be implemented.





8 – APPENDICES

A – REFERENCE GUIDE

NAESB

NAESB Web Site: (Error! Hyperlink reference not valid.www.naesb.org). Primary reference for energy industry standards and model business practices.

Time Synchronization

Time synchronization is required to assure that all trading partners’ transaction times are accurate. Testing has shown that the clocks on all computer systems drift. Time accuracy is dependent on how much a system’s clock drifts, how frequently it is resynchronized and the accuracy of the source used for synchronization.

Each NAESB business process may have unique time-synchronization requirements. Refer to the QEDM for time-synchronization standardmodel business practices for target markets. Servers need to be time-synchronized according to the standards and model business practices needed for the most-restrictive target market: that is, the one with the smallest drift allowance.

Authoritative time synchronization is now being provided by governmental agencies around the world based on a synchronized network of atomic clocks. In the United States this includes the U. S. Naval Observatory and the National Institute of Standards and Technology.

An easy way to obtain the current time is from the U. S. Naval Observatory’s Web site at tycho.usno.navy.mil/cgi-bin/timer.pl. The output from this page can easily be edited and reformatted to set a local system’s time. Commercial, shareware and public domain packages are also available to synchronize system times, including IETF NTP, Internet daytime, nisttime / usnotime.

Further information on time synchronization may be found at the following Web sites: http://tycho.usno.navy.mil/ntp.html www.ccd.bnl.gov/xntp

Relevant URL’s MIME Standards RFC 2045: ftp://ftp.rfc-editor.org/in-notes/rfc2045.txt RFC 1767: ftp://ftp.rfc-editor.org/in-notes/rfc1767.txt ASC X12 Standards www.x12.org





B – FREQUENTLY ASKED QUESTIONS

Q1: Use of ‘time-c-qualifier’ across quadrants. We understand that the retail quadrants require the ‘time-c-qualifier’ for ‘gisb-acknowledgement-receipt’, while the WGQ does not require this data element. If we participate in multiple quadrants, which standard do we use? ....................................................................................................33317

Q2: How do RXQ markets use the ‘refnum’ and ‘refnum-orig’ data elements? ....................33317 Q3: How does RXQEDM support transporting files that do not conform to NAESB standards

(e.g. load profiles, reports, PDF files, etc)? ...................................................33317 Q4: How does this document relate to the Internet ET standard and the standards developed for

specific business processes (e.g. Billing and Payments)? ............................ 43418

Q1: Use of ‘time-c-qualifier’ across quadrants. We understand that the retail quadrants require the ‘time-c-qualifier’ for ‘gisb-acknowledgement-receipt’, while the WGQ does not require this data element. If we participate in multiple quadrants, which standard or model business practice do we use?

A: You are required to follow the standards or model business practices dictated by the quadrant that governs the transaction or business process. For example, if you are executing a WGQ nomination, then you should adhere to WGQ standards, which do not require the ‘time-c-qualifier’. If you are executing an REQ enrollment, you need to adhere to the REQ standardmodel business practices, which require ‘time-c-qualifier’. Of course, all parties can mutually-agree to use the ‘time-c-qualifier’ or not.

Q2: How do RXQ markets use the ‘refnum’ and ‘refnum-orig’ data elements?

A: First, these data elements are mutually-agreed, so parties must agree to use these data elements.

The first time you send a package, the two refnum data elements (refnum, refnum-orig) should be identical 40-digit or less integers, unique over time in your systems.

If you do not receive your NAESB response, you should resend the package with a new refnum (again unique over time), and with the refnum-orig equal to the original send of the package.

The refnum data element is always unique over time. The refnum-orig always refers to a refnum that was used in a previous send.

Refnum Example Package Send refnum refnum-orig First send 123467890123456 123467890123456 First resend 223467890123457 123467890123456 Second resend 323467890123458 123467890123456

Q3: How does RXQEDM support transporting files that do not conform to NAESB standardsmodel business practices (e.g. load profiles, reports, PDF files, etc)?

A: First, sending files using RXQEDM that do not conform to NAESB RXQEDM





standardmodel business practices is supported, though on a mutually-agreed-upon basis. Non-NAESB payloads sent using RXQEDM standards should have the following information in the header: Internet ET ‘input-format’ data element = ‘PAYLOAD’. This indicates that the format

for the file is found in the MIME payload segment. MIME header ‘content-type’ data element = ‘application/consent’. This is the MIME

default for ‘other’ formats. MIME header ‘content-ID’ = [agreed upon name]. This is a text string that defines

what type of payload is being sent. For example, ERCOT may send load profile data with this value set to ‘ERCOT Load Profile’.

Q4: How does this document relate to the Internet ET standard and the standardmodel business practices developed for specific business processes (e.g. Billing and Payments)?

A: RXQEDM standardmodel business practices are designed to work in concert with the NAESB Internet ET standards, and with each standardmodel business practices book developed by NAESB REQ and RGQ business subcommittees. The table below summarizes the scope of the different documents:

NAESB Standard / Model Business Practice Scope

Internet Electronic Transport ([10].y.z)

TCP/IP, HTTP, HTTP POST SSL Encryption OpenPGP/PGP Encryption/Decryption MIME Internet ET Testing

REQ/RGQ Quadrant-specific Electronic Delivery Mechanism (RXQEDM) (RXQ.0RXQ.5.y.z)

X12 EDI Conventions Batch Flat-files Interactive Flat-files Electronic Bulletin Board

Informational Postings Web/HTML Web Services XML

Business Process Standards (e.g. Billing, Nominations, etc) (x.3.z)

Data Dictionaries Code Values X12 Transactions Sets (e.g. 810, 820, etc) XML Schemas Business Process Testing





APPENDIX C – SAMPLE TECHNICAL EXCHANGE WORKSHEET (TEW)

This appendix recommends data elements that should be exchanged by trading partners when using NAESB RXQ model business practicesstandards. These data elements may be included in a technical worksheet profile, or as an exhibit in a TPA.

EDM Specifications Test Production Identify your Entity Common Code / DUNS/DUNS+4 Number

Will you send X12 EDI/EDM Documents?

Identify your default EDI/EDM Segment Terminator (character 106 in ISA).

Identify your default EDI/EDM Data Element Terminator (character 4 in ISA).

Identify your default EDI/EDM Composite Element Separator (character 105 in ISA).

Identify your EDI/EDM ISA08/GS08 values.

Will you send the ‘time-c-qualifier’ in Receipt? (Y/N) Y (required by RXQ) Y (required by RXQ)

Will you send non-NAESB packages (‘input-format’=’PAYLOAD’; e.g. PDF)?

List expected ‘content-ID’ values





APPENDIX D – RXQEDM / INTERNET ET 2.0 CROSS-REFERENCE RxQ RxQ StandardsModel Business

Practices/Definitions/Principal/Interpretations WGQ WGQ 1.7 Original Standards/Definitions/Principal/Interpretation ET Internet ET 2.0

[11]RXQ.5.1.1 RXQEDM standards do not pick winners, but rather create an environment where the marketplace can dictate a winner(s) (4.1.2).

4.1.2 The Electronic Delivery Mechanism does not pick winners, rather it should create an environment where the marketplace can dictate a winner or winners.

[10].1.1 The Internet Electronic Transport (ET) does not pick winners, rather it should create an environment where the marketplace can dictate a winner or winners (4.1.2).

[11]RXQ.5.1.2 RXQEDM solutions should be cost effective, simple and economical (4.1.3).

4.1.3 The solutions should be cost effective, simple and economical. [10].1.2 Internet ET solutions should be cost effective, simple and economical (4.1.3).

[11]RXQ.5.1.3 RXQEDM solutions should provide for a seamless marketplace for energy (4.1.4).

4.1.4 The solutions should provide for a seamless marketplace for natural gas. [101].1.3 Internet ET solutions should provide for a seamless marketplace for energy (4.1.4).

[11]RXQ.5.1.4 Electronic communications between parties to the transaction should be done on a non-discriminatory basis, whether through an agent or directly with any party to the transaction (4.1.7).

4.1.7 Electronic communications between parties to the transaction should be done on a nondiscriminatory basis, whether through an agent or directly with any party to the transaction.

[10].1.5 Electronic communications between parties to the transaction should be done on a non-discriminatory basis, whether through an agent or directly with any party to the transaction (4.1.7).

[11]RXQ.5.1.5 Trading Partners should mutually select and use a version of the NAESB RXQEDM standards under which to operate, unless specified otherwise by government agencies. Trading Partners should also mutually agree to upgrade or adopt later versions of RXQEDM standards as needed, unless specified otherwise by government agencies (4.1.39).

4.1.39 Trading Partners should mutually select and utilize a version of the NAESB WGQ EDM standards under which to operate, unless specified otherwise by government agencies. Trading Partners should also mutually agree to adopt later versions of the NAESB WGQ EDM standards, as needed, again unless specified otherwise by government agencies.

[10].1.10 Trading Partners should mutually select and use a version of the NAESB Internet ET standards under which to operate, unless specified otherwise by government agencies. Trading Partners should also mutually agree to adopt later versions of the NAESB Internet ET standards, as needed, unless specified otherwise by government agencies (4.1.39).

[11]RXQ.5.1.6 Market participants should post clear and precise business processing rules at a designated site, and/or in writing upon request (4.1.9).

4.1.9 Service providers should post clear and precise business processing rules at the designated site, or in writing, upon request.

DOES NOT EXIST

[11]RXQ.5.1.7 There should be at least one standard automated computer-to-computer exchange of transactional data for each defined transaction data exchange format (4.1.10).

4.1.10 There should be at least one standard (computer-to-computer exchange of transactional data) for data exchange format.

DOES NOT EXIST

[11]RXQ.5.1.8 Transaction content and usage should reasonably correspond to defined data dictionaries regardless of mechanism, e.g. FF/EDM, EDI/EDM, etc. (4.1.34x).

4.1.34 For NAESB WGQ FF/EDM, the content and usage of flat files should reasonably correspond to the NAESB WGQ data sets used for NAESB WGQ EDI/EDM.

DOES NOT EXIST

[11]RXQ.5.1.9 Automated business processes should use 4.1.35 If NAESB WGQ FF/EDM is implemented, flat files should be exchanged DOES NOT EXIST





Internet ET, e.g. FF/EDM, EDI/EDM, etc. (4.1.35). via the NAESB WGQ EDI/EDM site or the Customer Activities Web site. [11]RXQ.5.2.1 ‘RXQEDM’. Electric Delivery Mechanism

standards for the NAESB RGQ and REQ quadrants that govern package payload file contents, including X12 EDI, Flat-file and other formats.

DOES NOT EXIST DOES NOT EXIST

[11]RXQ.5.2.2 “EDI/EDM”. The term used to describe ANSI ASC X12 computer-to-computer electronic data interchange of information in files as mapped from the x.4.z RXQ standards in the NAESB RXQ Implementation Guides and communicated between trading partners over the Internet using the NAESB Internet ET (4.2.11x).

4.2.11 “NAESB WGQ EDI/EDM” is the term used to describe ANSI ASC X12 computer-to-computer electronic data interchange of information in files as mapped from the x.4.z NAESB WGQ standards in the NAESB WGQ Implementation Guides and communicated between trading partners over the Internet using the NAESB WGQ Electronic Delivery Mechanism.

DOES NOT EXIST

[11]RXQ.5.2.3 “Translator”. A program or set of programs that process the contents of payloads, applying ANSI X12 and other standards, and transforms the information to other formats.


[11]RXQ.5.2.4 ‘Flat-file’. An RXQEDM Flat-file is an ASCII comma-separated-value (CSV) file with the characteristics as defined in the RXQEDM standards.


[11]RXQ.5.2.5 ‘FF/EDM’. The term used to describe a standardized flat-file electronic data interchange of information in files as mapped from the x.4.z RXQ standards (4.2.12x).

4.2.12 “NAESB WGQ FF/EDM” is the term used to describe a standardized flat file electronic data interchange of information in files as mapped from the x.4.z NAESB WGQ standards. NAESB WGQ FF/EDM is communicated between trading partners over the Internet using the NAESB WGQ Electronic Delivery Mechanism.

DOES NOT EXIST

[11]RXQ.5.2.6 ‘Batch Flat-file’. The term used within the FF/EDM to describe the automated computer-to-computer transfer of Flat-files (4.2.18x).

4.2.18 “Batch Flat File” is the term used within NAESB WGQ FF/EDM to describe the automated computer-to-computer transfer of flat files.

DOES NOT EXIST

[11]RXQ.5.2.7 ‘Interactive Flat-file’. The term used within the FF/EDM to describe the transfer of Flat-files using an interactive browser (4.2.19x).

4.2.19 “Interactive Flat File” is the term used within NAESB WGQ FF/EDM to describe the transfer of flat files using an interactive browser.

DOES NOT EXIST

[11]RXQ.5.2.xx [??LK to research NAESB existing TPA stuff]‘’Trading Partner Agreement’, or ‘TPA’ is a legal agreement between trading parties. The TPA often dictates service level agreements and problem remediation processes. The TPA may include QEDM technical exchange information such as ISA numbers, etc. (4.2.26x) ??defined elsewhere in NAESB? WGQ, IET, etc??.

4.2.26 DOES NOT EXIST [10].2.8 ‘Trading Partner Agreement’, or ‘TPA’ is a legal agreement between trading parties. The TPA often dictates service level agreements and problem remediation processes. The TPA may include technical exchange information such as URLs, et cetera (4.2.26x).

[11]RXQ.5.2.xx ‘Business Rule Change’. Any change in: A) the presence and/or the acceptable content of a data element sent by the changing party, B) a new business response to an accepted data element received by the changing party; C) a new business response to the acceptable content of a data element received by the changing party; D) a new intended business result. (WGQ EDM cross-reference 4.3.87)

4.3.87 When the receiver of: 1) a Nomination, 2) a Pre-determined Allocation, or, 3) a Request for Confirmation, has determined to change the business rule(s) it will apply to the processing of (and/or response to) one or more of these documents; or, when the sender of: 1) a Confirmation Response (solicited and unsolicited), 2) a Scheduled Quantity, 3) a Scheduled Quantity for Operator, 4) an Allocation, 5) a Shipper Imbalance, or, 6) an Invoice has determined to change the business rule(s) it will apply to the generating of (and/or content within) one or more of these documents, then it should notify its trading partners of same at least two weeks in

DOES NOT EXIST





advance of the change(s). The notification should include identification of the data element(s) that are changing (or whose content is changing), the intended business result of such change(s) in the business rule(s), and the effective date of such change(s). For the purposes of this standard, a business rule change is any change in: a) the presence and/or the acceptable content of a data element which is received by the trading partner sending notice; b) a new business response to an accepted data element which is received by the trading partner sending notice; c) a new business response to the acceptable content of a data element which is received by the trading partner sending notice; or, d) a new intended business result to be communicated to a receiver by the trading partner sending notice; Absent mutual agreement between the affected trading partners to the contrary, trading partners notifying their sending or receiving trading partners of a change(s) under this standard should provide the means to test such change(s) during at least a two week time period prior to the effective date of the change(s). Trading partners receiving notice of such change(s) from their trading partner should be prepared not to implement such change(s) even after testing has been completed, as the notifying trading partner is permitted to cancel or postpone such change(s). Notifying trading partners canceling or postponing the effective date of change(s) should provide affected trading partners with notice of cancellation or postponement at least one business day prior to the applicable effective date.

[11]RXQ.5.2.xx Testing between trading partners includes testing of: (A) intended business results, (B) proposed electronic transport, including security, enveloping, cryptography; and (C) electronic delivery mechanisms (xxx/EDM), including data validity, standards compliance, etc. (4.2.20).

4.2.20 Testing data sets between trading partners includes testing of: 1. intended business results, 2. proposed electronic delivery mechanisms, and 3. related EDI/EDM and, where supported, FF/EDM implementation issues. Testing should include enveloping, security, data validity, and standards compliance (e.g. ANSI X12 and NAESB WGQ EDM Related Standards).

[10].2.1 ‘Internet ET Testing’. Testing electronic packages between trading partners includes testing of: A) Connectivity; B) Encryption/Decryption; and C) Digital signatures where appropriate (4.2.20).

[11]RXQ.5.3.1 RXQEDM relies on the NAESB Internet ET to enforce the privacy, authentication, integrity, and non-repudiation (PAIN) security principles.


[11]RXQ.5.3.10 RXQEDM ‘time’ data elements should be specified in a 24 hour format, formatted as HH:MM or HH:MM:SS (4.3.80).

4.3.80 NAESB WGQ FF/EDM flat files should be formatted as ASCII comma separated value (CSV) files. This means: Rows are separated by a carriage return/line feed (CRLF). Fields are separated by commas. When a field contains a comma, the field should be enclosed by double-quotes. Double-quotes should not be used within any data field. When numeric data is negative, the minus sign should precede the number. When numeric data contains decimal precision, the decimal point should be included within the field. When numeric data contains one or more significant leading zeros, these zeros should be preserved in the flat file. Date fields should be formatted as YYYYMMDD. Time fields should be specified in a 24 hour format, formatted as HH:MM or HH:MM:SS, as applicable. Date/Time fields should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS when date and time are expressed in one NAESB WGQ data element. Note that there should be exactly one space between the day (DD) and the hour (HH). The maximum amount of data to be placed in a field should be limited to 256 characters. When a field contains no data, the empty field should result in two delimiters next to each other. Note that there should be no blank spaces between the delimiters.

DOES NOT EXIST





[11]RXQ.5.3.11 RXQEDM ‘date/time’ data elements that have date and time expressed in one data element should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS, with exactly one space between the day (DD) and the hour (HH) (4.3.80).


DOES NOT EXIST

[11]RXQ.5.3.12 Where they exist for the same business function, Flat-files, EDI and other EDMs should use the same nomenclature for data set names, data element names, code values and/or code value descriptions, abbreviations and message text. (4.3.47)

4.3.47 Where they exist for the same business function, flat files and EDI should use the same nomenclature for data set names, data element names, code values and/or code value descriptions, abbreviations and message text. Corresponding Web pages should use data set names, data element names, code value descriptions, abbreviations and message text that correspond to those used in flat files and EDI, where they exist.

DOES NOT EXIST

[11]RXQ.5.3.13 Trading partners should use common codes for legal entities for RXQEDM envelope data elements (4.3.56x, 4.3.21??).

4.3.56 The industry should use common codes for location points and legal entities when communicating via EDI/EDM, EBB/EDM and/or FF/EDM. The corresponding common code name should also be used in EBB/EDM.

[10].3.21 Trading partners should use common codes for legal entities for the Internet ET ‘to’ and ‘from’ data elements (4.3.56x).

[11]RXQ.5.3.14 Requests for standardization of additional services and/or data elements should be submitted to the appropriate NAESB quadrant Executive Committee (4.3.67).

4.3.67 A Transportation Service Provider which determines to provide new services which do not utilize existing transaction sets via NAESB WGQ EBB/EDM, should, prior to implementation, submit a request for standardization to NAESB WGQ including descriptions of the EBB/EDM, EDI/EDM and, as applicable, FF/EDM implementation.

DOES NOT EXIST

[11]RXQ.5.3.15 To the extent that multiple EDMs are used (e.g. EDI or Flat-files), the same business result should occur (4.3.86).

4.3.86 To the extent that multiple electronic delivery mechanisms are used, the same business result should occur.

DOES NOT EXIST

[11]RXQ.5.3.16 [??RXQEDM #012]Non-NAESB Internet ET packages (e.g. PDF files) will have the ‘input-format’ tag set to ‘PAYLOAD’ to indicate the format is found in the payload MIME segment. Inside the MIME segment and , the ‘content-type’ header will be set to an appropriate MIME content-type.‘application/consent’, and the ‘content-ID’ header will be set to a mutually-agreeable string identifying the contents of the package.


[11]RXQ.5.3.2 All RXQEDM payloads should be encrypted with a minimum 128-bit key when sent on unsecured networks (Internet). This encryption is built into transportation using the NAESB Internet ET. Where other transport options are used, a 128-bit

4.3.83 For Interactive Flat File EDM, 128-bit Secure Sockets Layer (SSL) encryption should be used.

[10].3.25 Internet ET Servers should use 128-bit Secure Socket Layer (SSL) encryption (4.3.88).





Secure Sockets Layer (SSL) encryption should be used (4.3.83).

[11]RXQ.5.3.20 NAESB is a member of ANSI and will strive to remain fully-compliant with ANSI ASC X12 standards.


[11]RXQ.5.3.21 RXQ EDI/EDM standards are X12 compliant. DOES NOT EXIST DOES NOT EXIST [11]RXQ.5.3.22 Where the X12 standard does not fully meet a

need, NAESB will add interim usages and code values when required. When used, NAESB will submit interim usage/code values to ANSI and the appropriate ANSI organizations for acceptance of the interim solution. ANSI’s final solution may provide a usage or code value different from the interim solution. NAESB standards will be updated to reflect the final solution.


[11]RXQ.5.3.23 EDI Translators generate the ASC X12 file, including control numbers and counts that will appear within the ISA/IEA outer envelope segments, and within the GS/GE inner envelope segments.


[11]RXQ.5.3.24 The ISA is the interchange control segment to be used on all NAESB X12 standards.


[11]RXQ.5.3.25 The Receiver must send a 997 FA for each X12 file received.


[11]RXQ.5.3.26 Inbound EDI transactions should be processed every day business is conducted. The 997 should be sent within one day of business??RXQEDM #005[GB]- energy day/business day??, as defined by the Receiver, of the receipt of the X12 file.


[11]RXQ.5.3.27 When Internet ET is used, the Internet ET receipt timestamp is the official receipt timestamp. Without Internet ET, the 997 timestamp is the official receipt timestamp.


[11]RXQ.5.3.28 RXQEDM uses X12 Version 4010 standards unless otherwise noted.


[11]RXQ.5.3.3 Trading partners should retain transaction data for at least 24 months for audit purposes. This data retention requirement does not otherwise modify statutory, regulatory, or contractual record retention requirements (4.3.4).

4.3.4 Trading partners should retain transactional data for at least 24 months for audit purposes. This data retention requirement only applies to the ability to recover or regenerate electronic records for a period of two years and does not otherwise modify statutory, regulatory, or contractual record retention requirements.

[10].3.2 Trading partners should retain audit trail data for at least 24 months. This data retention requirement does not otherwise modify statutory, regulatory, or contractual record retention requirements (4.3.4).

[11]RXQ.5.3.4 Timestamps that indicate the time transactions were received by a party should be the ‘time-c’ timestamp from the Internet ET Response (4.3.8).

4.3.8 The minimum acceptable protocol should be HTTP. All sending and receiving parties should be capable of sending and receiving the HTTP versions supported by NAESB WGQ.

[10].3.4 The minimum acceptable protocol should be HTTP. All sending and receiving parties should be capable of sending and receiving the HTTP versions supported by NAESB Internet ET (4.3.8).





[11]RXQ.5.3.40 FF/EDM records are separated by a carriage return/line feed (CRLF or \r\n or ASCII 10 and 13) (4.3.80).


DOES NOT EXIST

[11]RXQ.5.3.41 The first record of an FF/EDM Flat-file should be the standard abbreviations for RXQ data elements in the order the corresponding data appears in subsequent rows. The data element order is at the option of the sender (4.3.81) [??RXQEDM #002]

4.3.81 DOES NOT EXIST DOES NOT EXIST

[11]RXQ.5.3.42 If an FF/EDM Flat-file data element abbreviation is not recognized, the entire Flat-file should be rejected(4.3.80) [??RXQEDM #002].


DOES NOT EXIST

[11]RXQ.5.3.43 Each transaction (e.g. Enrollment) should be contained in a single FF/EDM Flat-file record (4.3.82).

4.3.82 For NAESB WGQ FF/EDM flat files, each transaction (e.g. nomination) should be contained in a single row.

DOES NOT EXIST

[11]RXQ.5.3.44 FF/EDM data elements are separated by commas (4.3.80).

4.3.80 NAESB WGQ FF/EDM flat files should be formatted as ASCII comma separated value (CSV) files. This means: Rows are separated by a carriage return/line feed (CRLF). Fields are separated by commas. When a field contains a comma, the field should be enclosed by double-quotes. Double-quotes should not be used within any data field. When numeric

DOES NOT EXIST





data is negative, the minus sign should precede the number. When numeric data contains decimal precision, the decimal point should be included within the field. When numeric data contains one or more significant leading zeros, these zeros should be preserved in the flat file. Date fields should be formatted as YYYYMMDD. Time fields should be specified in a 24 hour format, formatted as HH:MM or HH:MM:SS, as applicable. Date/Time fields should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS when date and time are expressed in one NAESB WGQ data element. Note that there should be exactly one space between the day (DD) and the hour (HH). The maximum amount of data to be placed in a field should be limited to 256 characters. When a field contains no data, the empty field should result in two delimiters next to each other. Note that there should be no blank spaces between the delimiters.

[11]RXQ.5.3.45 FF/EDM data elements that may contain a comma should be enclosed by double-quotes (4.3.80).


DOES NOT EXIST

[11]RXQ.5.3.46 FF/EDM data elements should not contain double-quotes (4.3.80).


DOES NOT EXIST





[11]RXQ.5.3.47 FF/EDM data elements that contain negative numbers should have the minus sign precede the number (4.3.80).


DOES NOT EXIST

[11]RXQ.5.3.48 FF/EDM data elements that contain decimal precision should include the decimal point within the data element (4.3.80).


DOES NOT EXIST

[11]RXQ.5.3.49 FF/EDM data elements that contain numeric data with one or more significant leading zeros should preserve these zeros within the data element (4.3.80).

4.3.80 NAESB WGQ FF/EDM flat files should be formatted as ASCII comma separated value (CSV) files. This means: Rows are separated by a carriage return/line feed (CRLF). Fields are separated by commas. When a field contains a comma, the field should be enclosed by double-quotes. Double-quotes should not be used within any data field. When numeric data is negative, the minus sign should precede the number. When numeric data contains decimal precision, the decimal point should be included within the field. When numeric data contains one or more significant leading zeros, these zeros should be preserved in the flat file. Date fields should be formatted as YYYYMMDD. Time fields should be specified in a 24 hour format, formatted as HH:MM or HH:MM:SS, as applicable. Date/Time fields should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS when date and time are expressed in one NAESB WGQ data element. Note that there should be exactly one space

DOES NOT EXIST





between the day (DD) and the hour (HH). The maximum amount of data to be placed in a field should be limited to 256 characters. When a field contains no data, the empty field should result in two delimiters next to each other. Note that there should be no blank spaces between the delimiters.

[11]RXQ.5.3.5 RGQ and REQ require the use of the Internet ET Response ‘time-c-qualifier’ data element to identify the time-zone of the Receiver’s timestamp (4.3.9).

4.3.9 For NAESB WGQ EDI/EDM and FF/EDM, there is a time stamp (HTTP Timestamp) that designates the time that a file is received at the designated site. The receiving party should generate a timestamp upon successful receipt of the complete file and send as an immediate response to the sending party. The timestamp should be generated by Common Gateway Interface (CGI) of the receiving party, prior to further processing by the CGI. GPD-DOES NOT MATCH

[10].3.5 and [10].3.7

A timestamp designates the time a file is received at the Receiver’s designated site. The timestamp consists of the ‘time-c’ data element, and in some cases the ‘time-cqualifier’ data element. Refer to QEDM standards for use of the ‘time-c-qualifier’ (4.3.9). and After timestamp generation, the Receiver and sends an immediate HTTP Response to the Sender. The ‘gisb-acknowledgement-receipt’, which includes the timestamp data element(s), is the primary part of the HTTP Response. (4.3.9)

[11]RXQ.5.3.50 FF/EDM ‘date’, ‘time’, and ‘date/time’ data elements should conform to RXQEDM and ISO standards: date=YYYYMMDD, time=HH:MM:SS, date/time=YYYYMMDD HH:MM:SS (4.3.80)


DOES NOT EXIST

[11]RXQ.5.3.51 FF/EDM data elements should be no longer than 256 characters (4.3.80).

4.3.80 NAESB WGQ FF/EDM flat files should be formatted as ASCII comma separated value (CSV) files. This means: Rows are separated by a carriage return/line feed (CRLF). Fields are separated by commas. When a field contains a comma, the field should be enclosed by double-quotes. Double-quotes should not be used within any data field. When numeric data is negative, the minus sign should precede the number. When numeric data contains decimal precision, the decimal point should be

DOES NOT EXIST





included within the field. When numeric data contains one or more significant leading zeros, these zeros should be preserved in the flat file. Date fields should be formatted as YYYYMMDD. Time fields should be specified in a 24 hour format, formatted as HH:MM or HH:MM:SS, as applicable. Date/Time fields should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS when date and time are expressed in one NAESB WGQ data element. Note that there should be exactly one space between the day (DD) and the hour (HH). The maximum amount of data to be placed in a field should be limited to 256 characters. When a field contains no data, the empty field should result in two delimiters next to each other. Note that there should be no blank spaces between the delimiters.

[11]RXQ.5.3.52 FF/EDM Flat-files should not contain mixed record formats in a single file (e.g. a single file with both Enrollments and Invoices).


[11]RXQ.5.3.53 FF/EDM payloads should be encrypted prior to Internet transport when not using Internet ET. SSL encryption is sufficient.

4.3.83 For Interactive Flat File EDM, 128-bit Secure Sockets Layer (SSL) encryption should be used.

DOES NOT EXIST

[11]RXQ.5.3.54 Transactions sent using FF/EDM should produce the same business result as other EDMs (e.g. EDI/EDM)

4.3.86 To the extent that multiple electronic delivery mechanisms are used, the same business result should occur.

DOES NOT EXIST

[11]RXQ.5.3.6 Timestamps used within RXQEDM transactions should be generated using clocks that are synchronized with the localized prevailing National Institute of Standards and Technology (NIST) time to mitigate discrepancies between the clocks of the Sender and Receiver. Computer clocks should be synchronized as often as necessary to ensure a+/- 5 second variance with an atomic clock. Specific business processes may have tighter synchronization requirements (4.3.10x).

4.3.10 The time-stamp should be included in the HTTP response back to the sender of the original HTTP transaction. The server clock generating the time-stamp should be synchronized with the National Institute of Standards and Technology (NIST) time in order to mitigate discrepancies between the clocks of the sender and receiver.

[10].3.8 The Server clock generating the timestamp should be synchronized with the National Institute of Standards and Technology (NIST) time in order to mitigate discrepancies between the clocks of the Sender and Receiver. Computer clocks should be synchronized as necessary to ensure at minimum +/- 5 second synchronization with an atomic clock. Specific business processes may have tighter synchronization requirements (4.3.10x).

[11]RXQ.5.3.60 When a party changes the business rule(s) it will apply to documents, it should notify its trading partners at least two weeks in advance of the change(s). The notification should include identification of the data element(s) that are changing, the intended business result of such change(s) in the business rule(s), and the scheduled effective date of such change(s) (4.3.87).

4.3.87 4.3.87 When the receiver of: 1) a Nomination, 2) a Pre-determined Allocation, or, 3) a Request for Confirmation, has determined to change the business rule(s) it will apply to the processing of (and/or response to) one or more of these documents; or, when the sender of: 1) a Confirmation Response (solicited and unsolicited), 2) a Scheduled Quantity, 3) a Scheduled Quantity for Operator, 4) an Allocation, 5) a Shipper Imbalance, or, 6) an Invoice has determined to change the business rule(s) it will apply to the generating of (and/or content within) one or more of these documents, then it should notify its trading partners of same at least two weeks in advance of the change(s). The notification should include identification of the data element(s) that are changing (or whose content is changing), the intended business result of such change(s) in the business rule(s), and the effective date of such change(s). For the purposes of this standard, a business rule change is any change in: a) the presence and/or the acceptable content of a data

DOES NOT EXIST





element which is received by the trading partner sending notice; b) a new business response to an accepted data element which is received by the trading partner sending notice; c) a new business response to the acceptable content of a data element which is received by the trading partner sending notice; or, d) a new intended business result to be communicated to a receiver by the trading partner sending notice; Absent mutual agreement between the affected trading partners to the contrary, trading partners notifying their sending or receiving trading partners of a change(s) under this standard should provide the means to test such change(s) during at least a two week time period prior to the effective date of the change(s). Trading partners receiving notice of such change(s) from their trading partner should be prepared not to implement such change(s) even after testing has been completed, as the notifying trading partner is permitted to cancel or postpone such change(s). Notifying trading partners canceling or postponing the effective date of change(s) should provide affected trading partners with notice of cancellation or postponement at least one business day prior to the applicable effective date.

[11]RXQ.5.3.61 Trading partners implementing Business Rule Changes should provide testing of change(s) during at least a two-week time period prior to the effective date of the change(s) (4.3.87).

4.3.87 4.3.87 When the receiver of: 1) a Nomination, 2) a Pre-determined Allocation, or, 3) a Request for Confirmation, has determined to change the business rule(s) it will apply to the processing of (and/or response to) one or more of these documents; or, when the sender of: 1) a Confirmation Response (solicited and unsolicited), 2) a Scheduled Quantity, 3) a Scheduled Quantity for Operator, 4) an Allocation, 5) a Shipper Imbalance, or, 6) an Invoice has determined to change the business rule(s) it will apply to the generating of (and/or content within) one or more of these documents, then it should notify its trading partners of same at least two weeks in advance of the change(s). The notification should include identification of the data element(s) that are changing (or whose content is changing), the intended business result of such change(s) in the business rule(s), and the effective date of such change(s). For the purposes of this standard, a business rule change is any change in: a) the presence and/or the acceptable content of a data element which is received by the trading partner sending notice; b) a new business response to an accepted data element which is received by the trading partner sending notice; c) a new business response to the acceptable content of a data element which is received by the trading partner sending notice; or, d) a new intended business result to be communicated to a receiver by the trading partner sending notice; Absent mutual agreement between the affected trading partners to the contrary, trading partners notifying their sending or receiving trading partners of a change(s) under this standard should provide the means to test such change(s) during at least a two week time period prior to the effective date of the change(s). Trading partners receiving notice of such change(s) from their trading partner should be prepared not to implement such change(s) even after testing has been completed, as the notifying trading partner is permitted to cancel or postpone such change(s). Notifying trading partners canceling or postponing the effective date of change(s) should provide affected trading partners with notice of cancellation or postponement at least one business day prior to the applicable effective date.

DOES NOT EXIST

[11]RXQ.5.3.62 Trading partners are permitted to cancel or postpone scheduled changes. Notice of cancellation or postponement should be provided

4.3.87 4.3.87 When the receiver of: 1) a Nomination, 2) a Pre-determined Allocation, or, 3) a Request for Confirmation, has determined to change the business rule(s) it will apply to the processing of (and/or response to)

DOES NOT EXIST





to trading partners at least one business day prior to the scheduled effective date (4.3.87).

one or more of these documents; or, when the sender of: 1) a Confirmation Response (solicited and unsolicited), 2) a Scheduled Quantity, 3) a Scheduled Quantity for Operator, 4) an Allocation, 5) a Shipper Imbalance, or, 6) an Invoice has determined to change the business rule(s) it will apply to the generating of (and/or content within) one or more of these documents, then it should notify its trading partners of same at least two weeks in advance of the change(s). The notification should include identification of the data element(s) that are changing (or whose content is changing), the intended business result of such change(s) in the business rule(s), and the effective date of such change(s). For the purposes of this standard, a business rule change is any change in: a) the presence and/or the acceptable content of a data element which is received by the trading partner sending notice; b) a new business response to an accepted data element which is received by the trading partner sending notice; c) a new business response to the acceptable content of a data element which is received by the trading partner sending notice; or, d) a new intended business result to be communicated to a receiver by the trading partner sending notice; Absent mutual agreement between the affected trading partners to the contrary, trading partners notifying their sending or receiving trading partners of a change(s) under this standard should provide the means to test such change(s) during at least a two week time period prior to the effective date of the change(s). Trading partners receiving notice of such change(s) from their trading partner should be prepared not to implement such change(s) even after testing has been completed, as the notifying trading partner is permitted to cancel or postpone such change(s). Notifying trading partners canceling or postponing the effective date of change(s) should provide affected trading partners with notice of cancellation or postponement at least one business day prior to the applicable effective date.

[11]RXQ.5.3.63 Trading partners should use dedicated testing systems that are representative of production systems.


[11]RXQ.5.3.7 When Internet ET is used, the Internet ET Receipt timestamp supercedes any EDM timestamps with respect to official time the document was received by the Receiver.

[11].3.27 When Internet ET is used, the Internet ET receipt timestamp is the official receipt timestamp. Without Internet ET, the 997 timestamp is the official receipt timestamp.

DOES NOT EXIST

[11]RXQ.5.3.8 When Internet ET is not used, the receipt timestamp is defined by each specific EDM.


[11]RXQ.5.3.9 RXQEDM ‘date’ data elements should be formatted as YYYYMMDD (4.3.80).

4.3.80 NAESB WGQ FF/EDM flat files should be formatted as ASCII comma separated value (CSV) files. This means: Rows are separated by a carriage return/line feed (CRLF). Fields are separated by commas. When a field contains a comma, the field should be enclosed by double-quotes. Double-quotes should not be used within any data field. When numeric data is negative, the minus sign should precede the number. When numeric data contains decimal precision, the decimal point should be included within the field. When numeric data contains one or more significant leading zeros, these zeros should be preserved in the flat file. Date fields should be formatted as YYYYMMDD. Time fields should be specified in a 24 hour format, formatted as HH:MM or HH:MM:SS, as applicable. Date/Time fields should be formatted as YYYYMMDD HH:MM or YYYYMMDD HH:MM:SS when date and time are expressed in one NAESB WGQ data element. Note that there should be exactly one space

DOES NOT EXIST





between the day (DD) and the hour (HH). The maximum amount of data to be placed in a field should be limited to 256 characters. When a field contains no data, the empty field should result in two delimiters next to each other. Note that there should be no blank spaces between the delimiters.




Retail Quadrants

TAB 13

Requests to be assigned for development: J.C. Penney/Wal-mart

Retail Electric Contract

• The two requests are included. The Triage Subcommittee and the EC have already acted to assign these requests. R05013 was assigned to the Contracts Subcommittee with the EC to assign priority at the 8-23 EC meeting. Similarly, R05016 was assigned to the BPS with the priority to be assigned by the EC at the 8-23 EC meeting

• Both requests are included in this tab. For the ECs to assign priority will take a simple majority vote.



R05013


Request for Initiation of a NAESB Business Practice Standard, Model Business Practice or Electronic Transaction

or Enhancement of an Existing NAESB Business Practice Standard, Model Business

Practice or Electronic Transaction Instructions: 1. Please fill out as much of the requested information as possible. It is

mandatory to provide a contact name, phone number and fax number to which questions can be directed. If you have an electronic mailing address, please make that available as well.

2. Attach any information you believe is related to the request. The more

complete your request is, the less time is required to review it. 3. Once completed, send your request to: Rae McQuade NAESB, Executive Director 1301 Fannin, Suite 2350 Houston, TX 77002 Phone: 713-356-0060 Fax: 713-356-0067 by either mail, fax, or to NAESB’s email address, [email protected]. Once received, the request will be routed to the appropriate subcommittees for review.

Please note that submitters should provide the requests to the NAESB office in sufficient time so that the NAESB Triage Subcommittee may fully consider the request prior to taking action on it. It is preferable that the request be submitted a minimum of 3 business days prior to the Triage Subcommittee meetings. Those meeting schedules

are posted on the NAESB web site at http://www.naesb.org/monthly_calendar.asp.


R05013




Practice or Electronic Transaction

Date of Request: May 6, 2005

1. Submitting Entity & Address: EnergyWindow, Inc. 1900 Folsom Street Suite 207_______ Boulder, Colorado, 80302___________ www.energywindow.com____________ 2. Contact Person, Phone #, Fax #, Electronic Mailing Address: Name : Jack Mason Title : President Phone : 877-444-0087 or 303-263-8678 Fax : 303 443-4409_______________ E-mail : [email protected] 3. Description of Proposed Standard or Enhancement:

Develop a model electric retail contract modeled after the NAESB Base Contract for Sale and Purchase of Natural Gas, NAESB Standard 6.3.1 (NAESB Base Contract for Gas). The contract would be designed for use by large scale aggregators, large single- and multi-site commercial users of electric power, and large industrials in competitive electric power markets.


Request for Initiation of a NAESB Standard for Electronic Business Transactions or Request for Enhancement of a NAESB Standard for Electronic Business Transactions

Page 3

4. Use of Proposed Standard or Enhancement (include how the standard will be used, documentation on the description of the proposed standard, any existing documentation of the proposed standard, and required communication protocols):

Through use of the NAESB Base Contract for Gas, the wholesale and retail gas industry has many years of experience using a standard contract to purchase natural gas on the wholesale and retail market. Benefits of using the NAESB Base Contract for Gas include: • Lower transaction costs and effort associated with reviewing,

negotiating contracts and executing electric service agreements; • Reduced customer service and contract administration cost and effort

following contract execution, during the term of the contract; • Less lost savings for buyers, or revenue for suppliers associated with, a)

delays in contract closure; and b) contracts that never close, due to inability to negotiate terms successfully and market changes during the negotiation period;

• Fewer opportunities for customer misunderstanding, dissatisfaction and loss;

• Less risk for buyers, and suppliers; • Greater ability to judge the value of offerings on important product

attributes without decisions being clouded by legal aspects and language;

• A framework within which more valuable aspects of electric service products can be emphasized, and suppliers can respond to customer business needs, innovate, and differentiate their offerings – all more effectively, and

• Increased competitive market participation. Those benefits and experiences could be translated into retail electric markets through the development and use of an analogous model contract for retail electric purchases. Large scale aggregators, large commercial users of power and natural gas, and large industrials purchase electric power in the retail market, and a standard contract would help facilitate market liquidity and transaction efficiency.

5. Description of Any Tangible or Intangible Benefits to the Use of the Proposed Standard or Enhancement:

See discussion above.

6. Estimate of Incremental Specific Costs to Implement Proposed Standard or

Enhancement:

Not applicable.


Request for Initiation of a NAESB Standard for Electronic Business Transactions or Request for Enhancement of a NAESB Standard for Electronic Business Transactions

Page 4

7. Description of Any Specific Legal or Other Considerations:

Since this request proposes the development of a standard contract, there are obvious legal considerations, many of which have been addressed in the development of the NAESB Base Contract for Natural Gas.

8. If This Proposed Standard or Enhancement Is Not Tested Yet, List Trading Partners Willing to Test Standard or Enhancement (Corporations and contacts):

Discussions with representatives of buyer and supplier organization suggest strong interest in a model retail electric contract and willingness to test the model. Names and contact information can be provided when appropriate.

9. If This Proposed Standard or Enhancement Is In Use, Who are the Trading Partners :

Not Applicable

10. Attachments (such as : further detailed proposals, transaction data descriptions,

information flows, implementation guides, business process descriptions, examples of ASC ANSI X12 mapped transactions):

A suggested draft of a NAESB model contract for retail electric applications is attached. It is based on the concept, structure, and, where appropriate, language of the NAESB Base Contract for Gas. In addition, the draft was developed with consideration of more than a dozen buyer and supplier retail electric service contracts in use in the industry today. Where possible and appropriate, language from the NAESB Base contract was selected preferentially. The suggested draft is provided with language borrowed from the NAESB Base Contract for Gas in blue text and additional or revised language to reflect specific requirements for retail electric service in black type in order to facilitate review and understanding of the extent of possible parallels between the two contracts. Selected mark-ups are shown where informative. An outline of the draft suggested model contract with more extensive mark-ups and annotations to explain approach, rationale and basis for selecting approaches or language for retail electric transactions can be provided if it would be helpful.


R05016 Request for Initiation of a NAESB Standard for Electronic Business Transactions or

Request for Enhancement of a NAESB Standard for Electronic Business Transactions




Practice or Electronic Transaction Instructions: 1. Please fill out as much of the requested information as possible. It is

mandatory to provide a contact name, phone number and fax number to which questions can be directed. If you have an electronic mailing address, please make that available as well.

2. Attach any information you believe is related to the request. The more

complete your request is, the less time is required to review it. 3. Once completed, send your request to: Rae McQuade NAESB, Executive Director 1301 Fannin, Suite 2350 Houston, TX 77002 Phone: 713-356-0060 Fax: 713-356-0067 by either mail, fax, or to NAESB’s email address, [email protected]. Once received, the request will be routed to the appropriate subcommittees for review.

Please note that submitters should provide the requests to the NAESB office in sufficient time so that the NAESB Triage Subcommittee may fully consider the request prior to taking action on it. It is preferable that the request be submitted a minimum of 3 business days prior to the Triage Subcommittee meetings. Those meeting schedules

are posted on the NAESB web site at http://www.naesb.org/monthly_calendar.asp.







Practice or Electronic Transaction

Date of Request: June 17, 2005

1. Submitting Entity & Address: Wal-Mart Stores, Inc. 2001 S.E. 10th Street Bentonville, AR 72716-0550 2. Contact Person, Phone #, Fax #, Electronic Mailing Address: Contact Person Name : Chris Hendrix Title : General Manager, Texas Retail Energy, LLC Manager of Energy Procurement, Wal-Mart Stores, Inc. Phone : 479-204-0845 Fax : 479-204-0936 E-mail : [email protected] 3. Description of Proposed Standard or Enhancement:

Standards or model business practices for electronic retail billing transactions and bill payment transactions between customers, suppliers, and utilities.

Energy-consuming, National Accounts (NA) with multiple facilities that span several utility service territories are required to engage with numerous utilities to satisfy the reconciliation of billing and payments associated with their commodity consumption and distribution and transmission services. Therefore, customers with a nationwide footprint (e.g., Wal-Mart, Radio Shack) must support multiple methods of receiving, interpreting and paying bills monthly for each account.

In service territories where EDI is not available the NA customer receives a large volume of paper-based transactions on a recurring monthly basis. Further complicating the problem is the complete lack of formatting consistency from one utility to another.

In service territories where the utility offers EDI billing, the NA customer experiences a wide variety of EDI standards and requirements. Although EDI has been in existence for more than 20 years and is a normal means of transacting business in most industries, it has not seen similar levels of success in billing transactions between energy utilities and their retail customers.




For utilities that serve these customers, it can also result in significant quantities of data, invoices, and payment transactions that are generally consistent in format from month-to-month. With the nature of these transactions, they are suitable for execution using electronic communications.

4. Use of Proposed Standard or Enhancement (include how the standard will be used,

documentation on the description of the proposed standard, any existing documentation of the proposed standard, and required communication protocols):

Although efforts are underway to develop implementation standards for electronic transactions between suppliers and utilities, there are no efforts underway to establish standards for electronic transactions between customers, suppliers, and utilities. NA customers and utilities alike have expressed interest in establishing standards for electronic billing communications.

While adoption of NAESB standards is voluntary, any voluntary adoption of developed standards would help to reduce the cost of sending, receiving, interpreting, and paying monthly utility bills. Also, it is hoped that over time more and more billing participants would adopt these voluntary standards; thus reducing costly exception processing. Whether a NA customers uses a 3rd party vendor to process and pay utility and energy bills or handles that process in house, uniform EDI standards would reduce costs.

5. Description of Any Tangible or Intangible Benefits to the Use of the Proposed

Standard or Enhancement: Studies indicate processing a paper invoice versus an electronic invoice is 10 times more expensive. For example, an electronic invoice can be received, validated, and processed for less than $1.00, while a paper invoice can reach $10.00 in handling, scanning/keying, validation cost for a paper invoice. A National Account with 5,000 locations can save over $500,000 a year in processing cost (5,000 location * 12 months * ($10 - $1)) given the paper invoice verse electronic invoice. All paper invoices are in different formats. Likewise, each utility that offers electronic invoices can use a different electronic format. Therefore, when a utility decides to offer an electronic invoice, it is in the best interest to all to have a common industry-wide EDI electronic format. Lowering transaction cost and improving accuracy will benefit all in the retail electric and gas supply chain.

6. Estimate of Incremental Specific Costs to Implement Proposed Standard or

Enhancement: Specific implementation costs for NA customers and utilities are unknown at this time.

7. Description of Any Specific Legal or Other Considerations:

Regulations may exist that govern bill content and presentation. These regulations will need to be considered when establishing standards.

Also, billing complexity can increase with deregulation, as competitive charges are unbundled from the non-competitive charges. That said, however, unregulated energy providers are also




likely to have newer, more flexible billing systems, or even outsource to application service providers (ASP) who are also more likely to have electronic billing capacity.

8. If This Proposed Standard or Enhancement Is Not Tested Yet, List Trading Partners

Willing to Test Standard or Enhancement (Corporations and contacts):

None provided. 9. If This Proposed Standard or Enhancement Is In Use, Who are the Trading Partners :

Consumers, utilities, retail energy providers, and third billing agents.

10. Attachments (such as: further detailed proposals, transaction data descriptions,

information flows, implementation guides, business process descriptions, examples of ASC ANSI X12 mapped transactions):

The Utility Industry Group developed an electronic utility EDI invoice in the late 1990s that has been adopted by a limited number of utilities. The UIG guideline was developed more from technical basis and could be improved upon by adding a business process perspective. This 810 EDI guideline could be the basis for NAESB in developing an industry-wide consensus. The 810 EDI Guideline developed by UIG is attached to request.
