Re: FW: UIGD New 814 Codes

All,

I cannot think of reasons why we should not all support Mr. Price's
recommendations on EDI.

If there are objections, can we hear about them ASAP?

Eric Woychik
CCN

At 02:43 PM 6/22/98 -0700, Price, James E. wrote:
>In the hope that this can smooth our discussions of EDI at the PSWG/
>MDMA meeting tomorrow, I'll address a couple of issues that have come up
>recently.  I fully agree that EDI implementation should be a
>collaborative process that addresses everyone's needs, and I believe
>that in looking past the heated discussion, the vote on 6/9 to set the
>1/1/99 target date for availability of meter reads in EDI format is the
>closest to date of that result.  If rational discussion can reach a
>broader consensus, we'll all be better off.  But I'm convinced that a
>1/1/99 target date for availability of meter reads in EDI format is
>workable.
>
>First is whether it will be difficult or time-consuming to resolve
>technical implementation details of EDI.  I believe it will not be
>difficult once people get past the point of accepting the need to do the
>migration.  One example is the attached note on Friday from the
>chairperson of UIG's electric deregulation task force, who identified
>what she termed "a few complicated questions" after noting that
>Pennsylvania utilities had been ordered to implement EDI over the
>Internet by 1/1/99.  (Note also that the working group in Arizona
>unanimously decided on June 16 to use EDI for their electric
>restructuring that takes effect 1/1/99.  The Arizona Corporations
>Commission staff was to recommend EDI to its Commission on 6/19, and
>after a formal committee vote on 6/29, it would be approved on 8/1.)  As
>far as I can tell, the "complicated" questions identified in the
>attached note were resolved by email within a few hours.
>
>Similarly, the EDI staff of the 3 UDCs and other interested parties
>(ESPs and ORA) met on 6/11 to address inconsistencies in existing
>implementations of transaction set 810 (billing) and to address how to
>update the implementations from EDI version 3030 to 3070, and in one day
>reached agreement on the entire content of a uniform implementation
>guideline for UDC to ESP billing.  We're meeting again on 6/30 and 7/1
>to agree on uniform implementation of EDI transaction set 814 for DASRs,
>account maintenance, and meter-specific information flows, and this
>2-day meeting will be addressing business model issues in addition to
>EDI implementation issues.  In the case of implementation of EDI
>transaction set 867 for meter reads, my view is that it should initially
>address the technical translation of CMEP to EDI, and then deal with any
>changes to our existing business model issues (i.e., operational
>policies and rules, given that we start with current practices) over a
>period of time, as evolving needs become apparent.  I see no reason to
>expect that reaching agreement during the technical translation process
>will be time-consuming, and want to schedule a meeting for this purpose
>(likely date: week of 7/20).
>
>With all this in mind, I propose the following as a strawman for
>milestones to a 1/1/99 availability of data in EDI format, with the
>development plan being documented in time for the 7/29 PSWG report:
>

>(1)  5/26/98 - 6/8/98:  Demonstration testing by ORA, as discussed at
>6/9 meeting
>
>(2)  6/10/98 - 7/15/98:  Preparation by ORA for public demonstration
>testing, including (1) conversion of CMEP files placed onto ORA's server
>into EDI format by scheduled software runs, and (2) downloading
>EDI-formatted data into a CMEP-formatted file on the recipient's system.
>Those wishing to test this system could verify that they had received a
>valid CMEP file containing the same data that they had posted to ORA's
>server, after this round-trip process.
>
>(3)  6/16/98:  Proposal by ORA of specific mapping of CMEP data content
>into EDI format.
>
>(4)  Prior to 7/29/98:  Agreement by EDI experts representing market
>participants on the appropriate mapping of CMEP data content into EDI
>Transaction Set 867.  (This depends on successful scheduling of a
>meeting.)
>
>(5)  7/15/98 - 12/1/98:  Configuration of programs on UDCs' servers to
>perform the file conversions that were previously demonstrated by ORA.
>
>(6)  12/1/98 - 12/31/98:  Testing on UDC servers by other market
>participants.
>
>(7)  1/1/99:  Data routinely available in EDI format at option of ESP.
>
>Second is the significance of a "narrow" initial implementation of EDI
>for meter reads.  On a general level, this simply means translation of
>the CMEP data content into EDI format, with the writing of the EDI
>format being within the UIG guidelines (for which refinements may be
>proposed), and with later migration to the full UIG guideline consisting
>of being able to accept the input of additional EDI coding beyond what
>we would initially be outputting.  In other words, someone whose
>software is programmed to the full UIG guideline would be able to
>process our initial subset with no problem.  There are places in my
>proposed implementation where it differs from drafts of the UIG
>guidelines prior to 6/98 but where I had suggested these simplifications
>in order to reduce the required file size, and I haven't seen the
>adopted 6/98 version to see whether they've been incorporated -- but
>whether we decide to accept the 6/98 UIG version or pursue proposals for
>change, the intent is not to be out of compliance with the UIG
>guideline.  The suggestion of a 12/31/99 date could be appropriate for
>migration to the full UIG guideline, although we may collectively choose
>to implement some additional features before then.  The preparation of
>state-specific implementation guidelines (or at least a few
>industry-model-specific guidelines) is a direction that UIG itself is
>moving in and is not a concern -- the specific guidelines simply
>document what is in actual use in a particular state because of its
>business needs, and does not indicate any non-compliance with the
>overall UIG guideline.  UIG's leadership works for Pennsylvania
>utilities, and Pennsylvania's state-specific guidelines are available on
>the Edison Electric Institute's Web site (www.eei.org).  Concepts like
>transaction numbers are inherent to EDI, would be part of even an
>interim guideline, and do facilitate auditing and resolution of any
>problems.

>
>Third, I'll repeat what I offered on Friday:  MDMAs could be required to
>produce CMEP output through 12/31/99 for market participants who need
>it, and EDI could be produced for ESPs who want it by an automated
>conversion process that runs on a schedule.  This automated conversion
>process would be analogous to what we're all accustomed to with ORA's
>email to Web posting process -- when scheduled, the software looks for
>new files and converts them to a different format that is usable through
>a different technological medium, without need for routine manual
>attention.  The CMEP output could even be the official version of the
>data, with the EDI translation being for ESPs' convenience.  The UDCs'
>reasonable concern (other than what's the official data) would seem to
>be making sure of what software is running on their systems, and
>reviewing under 1000 lines of source code and recompiling the program
>would resolve that issue.  The ESPs would be the ones who care most
>about what's in the EDI file if the CMEP version is the official one,
>and the program that I've already written could be reworked by ESPs as
>they collectively choose to do.  (I'll be glad to help with any
>revisions.)
>
>I'm looking forward to further discussion of these issues at the PSWG
>meetings this week.
>
>---
>Jim Price, ORA, jep@cpuc.ca.gov
>
>> -----Original Message-----
>> From:	kawall@papl.com [SMTP:kawall@papl.com]
>> Sent:	Friday, June 19, 1998 7:49 AM
>> To:	[UIG Electric Deregulation Task Force]
>> Subject:	UIGD New 814 Codes
>> 
>> It's official, Pennsylvania PUC issued a Final Order yesterday 
>> mandating the use of EDI in Pennsylvania, using UIG Guidelines!!  In 
>> addition, they also mandated that the work group choose an internet 
>> standard by July 24th to be implemented no later than 1/1/99.
>> 
>> So, if PA is going to use UIG guidelines, I have a few complicated
>> questions...
>> ..........
>> Question: First, if you look in the REF segment, we have a variety of 
>> pieces of data that relate to a meter.  What do you do when you have
>> to 
>> supply that information for multiple meters?  For example, I need to 
>> provide Number of Dials (IX), Old Meter # (46), Rate Code (RB) and AMR
>> 
>> Device ID (YT) for three separate meters.  How do I relate the 
>> information back?
>> 
>> Solution:  Put the Meter Number in REF03 so that the receiver would 
>> know which pieces of info go with which meter.  We could also expand 
>> the REF03 to the max of Composite Elements (3), which may or may not
>> be 
>> enough.  What do you think?
>> ..........
>> Question:  I need a new "service" for Requesting Meter Information.
>> 
>> Solution:  Add "MI" for "Meter Information" in the LIN.  This is very 
>> similar to HU, Request for Historical Usage, except that the HU is 
>> provided back on the 867 where the MI would be returned on the 814.
>> ..........
>> Question: I need "Annual KWH" with a related "Number of Months of 
>> Historical Usage Included in Annual KWH", and "Peak Demand for Last 12
>> 
>> Months" to be able to appear in the 814.  These are bits of
>> information 

>> that have been mandated to be returned on a response when an ESP 
>> initiates a request for enrollment.
>> 
>> Solution:  AMT segment?  REF segment?  This one I need help with.
>> ..........
>> 
>> As usual, I would very much appreciate anyone's comments.  I'm not
>> sure 
>> of the procedure here, but I figured the Task Group should review and 
>> come to consensus, then put the issue out to uiglist for 
>> review/comment.  Eventually when our electronic voting is in place I 
>> would assume that would be the next step.  Thanks everyone!
>> 
>> Kim
>> kawall@papl.com
>> 610.774.5612
> 

.