FW: UIGD New 814 Codes

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
.