EXHIBIT 99.238
[CALIFORNIA POWER EXCHANGE LOGO]
CALIFORNIA POWER EXCHANGE
SETTLEMENTS SYSTEM HIGH LEVEL REQUIREMENTS
Prepared For:
California Power Exchange Settlement Department
Prepared By:
Perot Systems L.A. Energy Office
SECTION 1: INTRODUCTION........................................................1
Section 1.1 Intent........................................................1
Section 1.2: Guiding Principles...........................................1
Section 1.3 Role of Functional and Non-Functional Requirements
in the Application Development Process....................................2
Section 1.4 Overview of the CalPX Settlement System (Titan)...............3
SECTION 2: FUNCTIONAL REQUIREMENTS.............................................4
Section 2.1: Process a Settlement.........................................4
SECTION 2.1.1: PROCESS A REAL TIME SETTLEMENT........................5
SECTION 2.1.2: PROCESS A DAY AHEAD/HOUR AHEAD SETTLEMENT.............6
SECTION 2.1.3: PROCESS A PREDICTIVE SETTLEMENT.......................7
Section 2.2: Administer System............................................8
SECTION 2.2.1: EFFECTIVE DATING......................................8
SECTION 2.2.2: FILE PROTOCOLS........................................8
SECTION 2.2.3: FILE NAMING CONVENTIONS...............................9
SECTION 2.2.4: CALCULATION RULES.....................................9
SECTION 2.2.5: PARTICIPANT INFORMATION...............................9
SECTION 2.2.6: VIEW THE SCHEDULE AND JOB STATUS......................9
SECTION 2.2.7: USER BASED SECURITY...................................9
SECTION 3: COMMON FUNCTIONS...................................................10
Section 3.1: Gather Input Data...........................................10
SECTION 3.1.1: CALENDAR DRIVEN ISO FILES............................10
SECTION 3.1.2: OTHER ISO DATA.......................................11
SECTION 3.1.3: CALPX DATA...........................................13
SECTION 3.1.4: MANUAL LINE ITEM ADD, CHANGE AND DELETE..............13
Section 3.2: Validation..................................................14
SECTION 3.2.1: DATA FORMAT VALIDATION...............................14
SECTION 3.2.2: DATA CONTENT VALIDATION..............................14
Section 3.3: Calculate Payments and Charges..............................15
SECTION 3.3.1: MATCH TRANSACTIONS...................................15
SECTION 3.3.2: SHARE TRANSACTIONS...................................15
SECTION 3.3.3: DIRECT TRANSACTIONS..................................15
SECTION 3.3.4: PX ADMINISTRATION FEES...............................15
Section 3.4: Propagate Results...........................................16
SECTION 3.4.1: PUSH TO CALPX WEB SITE...............................16
SECTION 3.4.2: PUSH TO BILLING......................................16
SECTION 4: NON-FUNCTIONAL REQUIREMENTS........................................17
Section 4.1: Security....................................................17
Section 4.2: Auditing....................................................17
Section 4.3: Exception Handling..........................................17
Section 4.4: Reporting...................................................17
Section 4.5: Performance.................................................18
Section 4.6: Archival & Retrieval........................................18
Section 4.7: Data Conversion.............................................18
SECTION 5: EXTERNAL SYSTEM INTERFACES.........................................19
Section 5.1: Settlements Data Warehouse..................................19
Section 5.2: Proactive Disputes (In Development).........................19
Section 5.3: Dispute Tracking (Future System)............................19
Section 5.4: PeopleSoft A/R............................................ 19
Section 5.5: CalPX Settlements Web Site................................ 20
Section 5.6 OM Scheduling System....................................... 20
APPENDICES.................................................................. 21
APPENDIX A: INFORMATION SOURCES............................................. 22
SECTION 1: INTRODUCTION
SECTION 1.1 INTENT
This purpose of this document is to capture the high level functional
requirements of the future settlements system (Titan) for the California Power
Exchange. Non-functional requirements that were collected as part of the
discovery process are also included in this document. The collective high-level
requirements will need to be examined along with required delivery dates and
available resources to determine scope and delivery phasing for this project.
This will be accomplished in the upcoming Project Initiation Workship (PIW).
SECTION 1.2: GUIDING PRINCIPLES
The dynamic nature of the California energy market, the need for CalPX to
provide a first class settlements system for its participants, and the growing
opportunities in the deregulated energy industry necessitate the creation of a
settlements system that is flexible, scaleable, reliable, maintainable and
intuitive. To satisfy these requirements Perot Systems will strive to develop
and deliver a settlements system that:
o is data driven to increase business flexibility and rules visibility
o abstracts services to isolate & facilitate future change
o provides meaningful audit trails
o is schedule/event driven (automated)
o is easily administered
o employs standards-based technology to ensure future expandability
Perot Systems Confidential page 1
SECTION 1.3 ROLE OF FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS IN THE
APPLICATION DEVELOPMENT PROCESS
High-level functional and non-functional requirements are captured early in a
project's life cycle to aid in project phasing, scope determination and to serve
as a road map for detailed requirements gathering. Functional requirements are
those requirements that describe the business processes of the system being
specified. Non-functional requirements describe qualities of the system that are
essential but that are not business processes (e.g. performance specifications).
Functional decomposition of a system during the Requirements phase of a project
leads into the creation of Use Cases and other Analysis deliverables such as
Summary Sequence Diagrams and Class Diagrams. These deliverables in turn aid in
the creation of Collaboration Diagrams and other design-level deliverables that
will be used to develop the software system. Analysis, Design, Development and
Test phases of the project are performed iteratively. The deliverables of each
iteration build upon one another to cumulatively construct a complete set of
detailed system documentation.
[GRAPH]
Perot Systems Confidential page 2
SECTION 1.4 OVERVIEW OF THE CALPX SETTLEMENT SYSTEM (TITAN)
The CalPX Settlements system includes retrieval, validation, and processing of
input data from the California Independent System Operator (ISO) and from the
CalPX Day-Ahead and Hour-Ahead scheduling systems. This data, combined with
other CalPX databases, will be used to generate Real Time, Forward Market, and
Predictive settlement statements and will also be used as the basis of invoicing
within the PeopleSoft billing system.
[GRAPH]
Perot Systems Confidential page 3
SECTION 2: FUNCTIONAL REQUIREMENTS
There are two high level requirements that pertain to the Settlements system:
Processing a settlement statement and Administration of the system. Both of
these functional requirements can easily be decomposed.
SECTION 2.1: PROCESS A SETTLEMENT
Processing a settlement is the core business process that the Settlement system
must automate. Processing a settlement is composed of the following high-level
functional components:
a) gathering the data needed
b) calculating the charges and payments based on the input data
c) propagating these results to the appropriate recipients
[GRAPH]
In the Settlements system, Real Time, Day Ahead / Hour Ahead and Predictive
settlements will need to be processed. Their common functional components
(gather, calculate and propagate) are essentially the same though behavior will
vary based on the information being processed.
Section 3, Common Functions, of this document provides details for each of the
common functional components used to describe the processing of a Real Time, Day
Ahead / Hour Ahead and Predictive settlement. The section number for the
referenced requirement is listed in parenthesis beside its description in the
following section.
Perot Systems Confidential page 4
SECTION 2.1.1: PROCESS A REAL TIME SETTLEMENT
1. PROCESS A REAL TIME PRELIMINARY SETTLEMENT
ISO Preliminary Settlements are issued approximately 45 days after the trading
date. The ultimate goal of the preliminary statement is to allow CalPX and its
participants the chance to review and validate the charges issued by the ISO
before receiving the final settlement statements.
*NOTE* DETAILS OF THE STEPS OUTLINED BELOW ARE FURTHER EXPANDED IN THE SECTIONS
INDICATED IN PARENTHESIS.
GATHER INPUT DATA (3.1)
o Calendar Driven ISO Data (3.1.1)
o Other ISO Data (3.1.2)
o CalPX Data (3.1.3)
o Manual Line Item Add, Change and Delete (3.1.4)
o Validate Data Format (3.2.1)
CALCULATE CHARGES (3.3)
o Validate Data Content (3.2.2)
o Match Transactions (3.3.1)
o Share Transactions (3.3.2)
o Direct Transactions (3.3.3)
o PX Administration Fees (3.3.4)
PROPAGATE RESULTS (3.4)
o Push to Web Site (3.4.1)
2. PROCESS A REAL TIME FINAL SETTLEMENT
Final Settlement Statements are issued approximately 60 days after the trading
date. Once the final statements are released, no disputes can be raised.
Technically, only things that remained unchanged since the preliminary can no
longer be disputed; new items are still disputable. There isn't a formal process
for resolving such disputes, however; hence, the importance of getting it right
the first time.)
GATHER INPUT DATA (3.1)
o Calendar Driven ISO Data (3.1.1)
o Other ISO Data (3.1.2)
Perot Systems Confidential page 5
o CalPX Data (3.1.3)
o Manual Line Item Add, Change and Delete (3.1.4)
o Validate Data Format (3.2.1)
CALCULATE CHARGES (3.3)
o Validate Data Content (3.2.2)
o Match Transactions (3.3.1)
o Share Transactions (3.3.2)
o Direct Transactions (3.3.3)
o PX Administration Fees (3.3.4)
PROPAGATE RESULTS (3.4)
o Push to Web Site (3.4.1)
o Push to Billing (3.4.2)
SECTION 2.1.2: PROCESS A DAY AHEAD/HOUR AHEAD SETTLEMENT
The processing of settlement data for the hour-ahead and day-ahead (forward)
markets is identical. These markets also produces preliminary and final
statements in order to allow for disputes.
1. PROCESS A DA/HA PRELIMINARY SETTLEMENT
GATHER INPUT DATA (3.1)
o Other ISO Data (3.1.2)
o CalPX Data (3.1.3)
o Manual Line Item Add, Change and Delete (3.1.4) (I'm not aware of any
manual line items for the DA or HA markets.)
o Validate Data Format (3.2.1)
CALCULATE CHARGES (3.3)
o Validate Data Content (3.2.2)
o Share Transaction (TO Debit) (3.3.2)
o Direct Transactions (3.3.3)
o PX Administration Fees (3.3.4)
PROPAGATE RESULTS (3.4)
o Push to Web Site (3.4.1)
o Push to Billing (3.4.2)
Perot Systems Confidential page 6
2. PROCESS A DA/HA FINAL STATEMENT
GATHER INPUT DATA (3.1)
o Other ISO Data (3.1.2)
o CalPX Data (3.1.3)
o Manual Line Item Add, Change and Delete (3.1.4)
o Validate Data Format (3.2.1)
CALCULATE CHARGES (3.3)
o Validate Data Content (3.2.2)
o Share Transaction (TO Debit) (3.3.2)
o Direct Transactions (3.3.3)
o PX Administration Fees (3.3.4)
PROPAGATE RESULTS (3.4)
o Push to Web Site (3.4.1)
o Push to Billing (3.4.2)
SECTION 2.1.3: PROCESS A PREDICTIVE SETTLEMENT
A strategic goal for CalPX is to have much quicker turnaround on the generation
of participant real time market settlement statements. Preliminary Statements
are not received from the ISO until approximately 45 days after the trading
date. CalPX can provide its participants with an extremely valuable service of
predictive (estimated) settlement statements through utilization of data
available approximately 10 days after the trading date. This would cut the lag
time in preliminary settlement data down by more than 30 days for the
participants of CalPX. Generation meter data and PMI data (available on ISO's
web site) are both available within a few days of the transaction, as is the
schedule data from within CalPX. By making use of these inputs, the settlements
system can quickly produce a very good estimate of the amounts to be invoiced.
(The exact form and use of these predictive statements has no, however, been
determined yet.)
GATHER INPUT DATA (3.1)
o Other ISO Data (3.1.2)
o CalPX Data (3.1.3)
o Manual Line Item Add, Change and Delete (3.1.4)
o Validate Data Format (3.2.1)
CALCULATE CHARGES (3.3)
Perot Systems Confidential page 7
o Validate Data Content (3.2.2)
o Match Transactions (3.3.1)
o Share Transactions (3.3.2)
o Direct Transactions (3.3.3)
o PX Administration Fees (3.3.4)
PROPAGATE RESULTS (3.4)
o Push to Web Site (3.4.1)
o Push to Billing (3.4.2)
SECTION 2.2: ADMINISTER SYSTEM
The second high-level functional requirement for the Settlements system is that
of Administration. Due to the short amount of time that deregulation has been
in place, the data and processes dealing with settlements are highly volatile
and are likely to change often. Being able to quickly adapt to these changes is
a key requirement of the settlements system. The following functional
components have been identified as key components in being able to adapt to
these changing requirements. The exact nature of how these functional pieces
will be easily administered is not the focus of this section.
SECTION 2.2.1: EFFECTIVE DATING
Effective dating will need to be designed into system components to allow for
advanced specification and appropriate introduction. These components will be
phased into or out of service as appropriate. This will include, for example,
such components as products, resources, resource ownership, and calculations.
SECTION 2.2.2: FILE PROTOCOLS
1. INPUT FILE SPECIFICATIONS
There should be an easily configurable input module that will enable the record
layout for all of the current input files to be easily modified. These changes
should also be effective-dated. This will allow the settlements system to
easily adapt to changes in the input files that are received from the ISO.
2. SETTLEMENT STATEMENT SPECIFICATION
The result of processing settlement data is to produce an informative,
descriptive and easy to understand settlement statement for each participant.
The specification for this file should be easily administered such that
modifications necessary to achieve this goal can be done quickly and easily.
Ideally, the layout of this file should be user configurable.
Perot Systems Confidential page 8
SECTION 2.2.3: FILE NAMING CONVENTIONS
The naming conventions followed for files downloaded from the ISO web site
should be easily modified to isolate the settlements system from ISO naming
convention changes.
SECTION 2.2.4: CALCULATION RULES
The rules for calculations should be produced in such a way that they are
easily modified to isolate the settlement system from market-based changes.
SECTION 2.2.5: PARTICIPANT INFORMATION
Currently, participant information is maintained in the Master/Master tables.
It may be beneficial to have the Titan system administer and control the
imports for this information.
SECTION 2.2.6: VIEW THE SCHEDULE AND JOB STATUS
As settlements are being processed, the status of the job should be easy to
determine. In addition to easily monitoring the progress of a particular job,
schedules for upcoming jobs should be easily administered and monitored. (I'd
like a stronger statement to the effect that it should be possible to schedule
individual jobs, based on a combination of time of day, job precedence, and job
return codes.)
SECTION 2.2.7: USER BASED SECURITY
Simple user based security should be easily administered such that each user is
given access rights to perform certain functions in the settlement system. (For
simplicity, these rights can be assigned based on standard role definitions.)
Perot Systems Confidential page 9
SECTION 3: COMMON FUNCTIONS
SECTION 3.1: GATHER INPUT DATA
Input data into the settlements system currently originates from either the ISO
or other internal PX systems. This data must be gathered, where possible, by
the settlements system as input to initiate the settlement process.
The process of gathering data will be done using an Automated Calendar/Event
based mechanism. The ISO web site will be polled at intervals determined by the
published ISO schedule. Once the required data is extracted from the
site, the processing of the settlement statements will occur automatically.
SECTION 3.1.1: CALENDAR DRIVEN ISO FILES
There are currently four files that are generated by the ISO for input into the
settlements system. The four files complement one another and are produced for
each trading date. Once generated, these files are available through the ISO
web site according to the published ISO schedule.
1. SETTLEMENTS FILE
There are two settlement statements (preliminary and final) issued for a given
trading date. Currently, the preliminary and final statements for a given
trading date are issued 14 days apart. Both statements have the same statement
number, but are identified by the statement type. Each preliminary statement
file contains the best available listing of settlement detail and manual line
items for the trading date being settled. Also included in the file may be new
settlement line items that represent adjustments for prior settlement
statements. (I don't understand the constraint/condition being described. The
fact is that the ISO will make prior day adjustments on a regular basis. In
theory, no PDA is supposed to appear on a final without first appearing on a
preliminary, but in practice that condition can't be guaranteed.)
The Specification for this file format can be seen in the file
FileSpecifications.pdf, which is available from the ISO web site.
2. GRID MANAGEMENT CHARGES (GMC) FILE
Perot Systems Confidential page 10
The GMC Detail File contains a detail breakdown by resource location and
trading interval of the ISO's grid management charges associated with the
market participant's load and export schedules for a given trade date.
The Specification for this file format can be seen in the file
FileSpecifications.pdf, which is available from the ISO web site.
3. GROSS INTERTIE SCHEDULE (GIS) FILE
The Gross Intertie Schedule File contains the market participant's individual
import and export schedules from the forward and real-time market along with
the real-time intertie operational adjustments.
The Specification for this file format can be seen in the file
FileSpecifications.pdf, which is available from the ISO web site.
4. UNACCOUNTED FOR ENERGY (UFE) FILE
The UFE or "Deviation" File is received with every ISO Settlement Statement.
This file is an itemized account of all deviation charges referenced in the
Settlement Statement. Deviation charges are those charges in the Settlement
Statement that have a charge type in the range of 402-406. (In general,
deviations are the differences between the planned level of supply or demand
and the metered quantity.)
The Deviation/UFE file contains a detailed breakdown by resource location of
the deviations in the market participant's generation, load, import and export
schedules. It also contains the parameters that are used to derive the
participant's share of Unaccounted for Energy.
The Specification for this file format can be seen in the file
FileSpecifications.pdf, which is available from the ISO web site.
SECTION 3.1.2: OTHER ISO DATA
1. ISO PUBLIC MARKET INFORMATION (PMI) FILE
The PMI file is downloaded through the Wenet by the data warehousing group.
This file contains market information that includes BEEP and ex-post prices.
The Titan system will not be responsible for gathering this data from the ISO,
but merely querying the data warehouse tables for the desired information.
2. ISO MEETING DATA
Perot Systems Confidential page 11
The process of gathering metering data is coordinated between CalPX and the ISO.
CalPX will gather all of the metering data for its participants that isn't
directly available to the ISO and submit it to the ISO. Once the ISO has
gathered all of the data from CalPX, from other scheduling coordinators, and
from its own resources, it will send this accumulation of data back to CalPX.
The interface for submitting and receiving metering data is done through the
MDAS SYSTEM. The settlements system will be responsible for gathering data from
MDAS and using it for calculations. (Just a definitional item here: if the PEP+
system is replaced, then it's true that the data warehouse will need an
alternative access to MDAS.)
[GRAPHIC]
3. REGULATION ENERGY PAYMENT ADJUSTMENT CHARGES (REPA) FILE (REPA files
were used last summer -- from May through November -- because of high energy
process. There is no guarantee that REPA will happen in the future. What's
important, though, is the notion that the ISO will frequently compensate for
their own system deficiencies by sending us settlement information in the form
of spreadsheets. This type of contingency must be included in our plans.)
REPA files are used in the exception case when energy prices reach levels that
are so high that regulatory adjustments to those prices must be administered.
Two charge types are currently used for this exception case: 1003 and 1010.
Regulatory Energy Payment Adjustment Charges are summarized in the settlement
statement. This file provides an hour by hour, itemized listing of the charges.
Perot Systems Confidential page 12
This file is in an Excel format and is emailed to CalPX office when these
charge types exist for a particular settlement date.
4. "JAKE'S" SPREADSHEET
This spreadsheet is emailed to the CalPX offices from ISO. This file is a
Microsoft Excel file with multiple tabs that details the DC losses for the
appropriate resources. This file is being phased out, but is currently the only
source for DC losses.
5. TRANSMISSION OWNER (TO) DEBIT FILE
The Transmission Owner Debit file is used in conjunction with schedule data for
the Hour ahead market only. These fees from the ISO come in to play whenever
the capacity for sold energy has to be reduced. This cost is shared across all
of the participants in that market.
This file is sent as an Excel spreadsheet and is emailed to CalPX from the ISO.
(Larry -- Does Settlements get this info in this form?)
SECTION 3.1.3: CALPX DATA
The settlements system will rely on data submitted from the scheduling system
and data from the Master / Master tables.
1. PX SCHEDULED DATA
Data from the trading floor is currently managed by an OM system which is
polled by the current Settlements system for Price and Quantity data. This data
will need to be made available to the Titan system via an API or database table
definitions.
2. MASTER / MASTER DATA
Participant information is maintained in the Master / Master tables. There are
currently approximately forty tables in the database that maintain such
relationships as resources, participants and zones.
CalPX has the entity -- relationship model captured in the Erwin database
design tool.
SECTION 3.1.4: MANUAL LINE ITEM ADD, CHANGE AND DELETE
The settlement system must provide the capability for manual manipulation of
the input data. This will include adding, deleting and modifying records in any
of the files previously listed.
Perot Systems Confidential page 13
SECTION 3.2: VALIDATION
SECTION 3.2.1: DATA FORMAT VALIDATION
Format validation must occur on the files as they are being processed by the
Settlements systems. This validation will ensure that the protocols established
for each of the file types are adhered to as well as the correct summation of
checksum data within the files. Data that is not formatted correctly will not be
processed and the job status will be updated as appropriate to the error
condition. (Hopefully, improper formats would be immediately self-evident to the
analysts.)
SECTION 3.2.2: DATA CONTENT VALIDATION
After the input data is verified to be syntactically correct, the settlements
system must ensure that the content of the data is correct for the settlement
trading date. (I'm sorry, but I don't know where you were going with that last
part.)
After validation, a detailed list of all data that failed with the associated
rules will be generated and propagated to the appropriate monitor process.(??)
Perot Systems Confidential Page 14
SECTION 3.3: CALCULATE PAYMENTS AND CHARGES
Payment and charge calculations are detailed in the Power Exchange Settlement
and Billing Protocol - Appendix 1: Algorithms for Computation of Payments and
are segregated by transaction type in Appendix 2: Table 4: Payments and Charges.
SECTION 3.3.1: MATCH TRANSACTIONS
Match transactions are a payment from the ISO or charge from the ISO that can
be identified as belonging to a specific resource and, hence, to a specific
participant. (Match transactions do NOT need to be balanced within the CalPX
participant pool.
SECTION 3.3.2: SHARE TRANSACTIONS
For share transactions, CalPX, acting as an Agent for one or more CalPX
Participants, either makes a payment to the ISO or makes a charge to the ISO.
The resulting money is either collected from, or paid to, CalPX Participants in
accordance with a "sharing" algorithm defined in the Protocol. The payment or
charge on the ISO is shown as if was directly between the ISO and CalPX. The
payment or charge on CalPX Participants is shown as if it was on CalPX.
All share transactions are for the Real Time Energy market with the exception
of TO Debits which are a unique share type that applies to both generators and
loads in the Hour Ahead market. (Let's just say for now that all share
transactions are settled in the real-time market.)
SECTION 3.3.3: DIRECT TRANSACTIONS
Direct transactions represent the settlements arising from participants trading
in the CalPX energy market. Participants will be paid for energy scheduled to
be delivered and charged for energy scheduled to be used.
SECTION 3.3.4: PX ADMINISTRATION FEES
Administration fees are CalPX's primary source of income. There are three types
of Administration fees that are charges to the participants:
1. VOLUMETRIC
Perot Systems Confidential page 15
These fees are based on the volume of demand only. No fees are based on supply
volumes.
2. TERMINAL
These fees are applied to the participants based on the number of trading
'terminals' (Trade App installations) they have licensed.
3. SUBSCRIPTION
These fees are elective and allow a participant to buy a fixed amount of
demand, which is exempt from the Volumetric Fees. Essentially, subscription
fees represent quantity discounts for steady levels of demand.
SECTION 3.4: PROPAGATE RESULTS
Once a settlement process reaches completion, the results will need to be
propagated to the appropriate recipient. Currently, there are two recipients of
settlement information: the billing system and California Power Exchange Web
Site. Exception cases will be propagated to the system monitor (See Section 6.3)
SECTION 3.4.1: PUSH TO CALPX WEB SITE
Settlement statements (and invoices) will be distributed to participants
through the Settlements web site. ("Charges" is an inappropriate term here,
since settlement statements represent combinations of payments and charges.)
SECTION 3.4.2: PUSH TO BILLING
The billing system will need the charge information at the end of each
settlement process. The format and content of this data is to be determined.
Perot Systems Confidential page 16
SECTION 4: NON-FUNCTIONAL REQUIREMENTS
SECTION 4.1: SECURITY
The Settlements system security will be role-based and control access to
settlement system functionality and data.
SECTION 4.2: AUDITING
Auditing for the Settlements system will ensure that data transformation from
beginning to end is traceable. All activities that alter settlements data will
record information sufficient to ensure complete visibility.
Control information will also be captured for audit purposes. The system will
track input and output information at all stages of the settlements process
(e.g. # of records read in -- of file type X -- transformed to # records --
processed results in # records per participant). This control information will
track record counts and dollar amounts as applicable.
Archival information will also be captured to track the changes that are taking
place to the input data sets.
SECTION 4.3: EXCEPTION HANDLING
Abnormal situations encountered while processing settlements data will generate
an informational exception which will be linked to the settlements run and
provide information necessary to aid in determination of the cause.
Encountering an exception that requires user intervention will visibly change
(How?) that status of the settlements process that generated the exception.
SECTION 4.4: REPORTING
1. CONTROL
Reports will be generated at process "stages" that will provide validation that
all details / dollars are accounted for. The Settlement system must be able to
account for totals end-to-end.
2. PARTICIPANT
Reports will be generated for each PX participant that provides detailed
information on the settlement payments and charges and how they were calculated.
Perot Systems Confidential Page 17
SECTION 4.5: PERFORMANCE
Support the following volumes (for each geographic area):
o 5,000 resource ids
o 1M ISO transaction records per day
o one preliminary and one final version of all data for each trading day
o 50 congestion zones
o 100 out of state inter-ties
o 100 interchange ids at each inter-tie
o Supports simultaneous access for up to 10 users
Processing speed adequate to process to above volumes for three trading days
within 18 hours, assuming 10 markets each containing 25 market transactions,
with separate preliminary and final versions of data for each day (the above
volumes apply to each version). (Larry to validate.)
SECTION 4.6: ARCHIVAL & RETRIEVAL
Each revision of a data set that is run through the settlements process should
be archived to ensure a complete audit trail of data from the preliminary to
the final statement.
Settlement Data availability:
o Support access to 120 days of data on-line
o 121 days to 1 year old data archived with 4 hour retrieval
o 7 year old data archived with 24 hour retrieval
(Actually, I think we need to keep one year on-line. The ISO is currently in
the process of reviewing payment and charge transactions dating back to April
98.)
Also: In addition to data retrieval, the system must be capable of reruns, as
necessary, using the old data.
SECTION 4.7: DATA CONVERSION
Historical data from the current Settlements system must be transformed to a
format that can be manipulated by the new system.
Perot Systems Confidential page 18
SECTION 5: EXTERNAL SYSTEM INTERFACES
One of the major goals in the development of enterprise level systems is to
have seamless communication between the different systems of the application
architecture. Each system in the architecture should have a well-defined
interface that exposes its public functionality.
While a well-defined API is the preferred communication mechanism between
systems, another acceptable mechanism for communication is shared data sources.
However, manual intervention into the shared resources for the purposes of
communication should be avoided.
Perot Systems will strive to provide a well-defined programming interface into
all of the components in the settlements system. Communication between existing
systems that do not have defined APIs will require development of APIs or
utilization of their shared resources for communication.
There are currently six major systems with which the Settlements system will
need to exchange data. Due to the fact that two of the systems are not yet in
place and one of the systems is completely proprietary, it is likely that we
will have to use a combination of the preferred communication mechanisms to
both send and receive data from the Settlements system.
SECTION 5.1: SETTLEMENTS DATA WAREHOUSE
Communication with the data warehouse will occur either through direct access
to the database tables or via an established API.
SECTION 5.2: PROACTIVE DISPUTES (IN DEVELOPMENT)
A well-defined API into the proactive disputes system will need to be put into
place for sending settlement data to the proactive dispute system. (You would
actually be sending it to the data warehouse, so this is almost the same
problem described in the paragraph immediately above.)
SECTION 5.3: DISPUTE TRACKING (FUTURE SYSTEM)
A well-defined API into the dispute tracking system will need to be put into
place for the Settlement system to propagate its data. (You would also be
getting information from dispute tracking.)
SECTION 5.4: PEOPLESOFT A/R
The API into the PeopleSoft system will need to be used for submitting and
receiving settlement data to and from the billing system.
Perot Systems Confidential page 19
SECTION 5.5: CALPX SETTLEMENTS WEB SITE
An API for web based settlements solutions will need to be set up in the
Settlements system. Currently a push approach is used to populate the
Settlements web site. A move to user defined settlement statements may
necessitate the creation of an API to be used by the Web Server to extract
specific information.
SECTION 5.6 OM SCHEDULING SYSTEM
The OM Scheduling system will need to provide data to the Settlements system.
Currently, the OM Scheduling system database tables are open to the settlements
system. Either direct access to the database tables or an open API will be
required to extract the appropriate data.
Perot Systems Confidential page 20
APPENDICES
Perot Systems Confidential page 21
APPENDIX A: INFORMATION SOURCES
The purpose of this section is to identify those documents that were used to
generate the functional requirements for the settlements system. This section
also identifies those files that are referenced as containing functional
requirement specifications pertaining to the settlements system.
Settlements Pre-Processor (PEP+) Requirements and Functional Specifications
Power Exchange Settlement and Billing Protocol (PSABP)
ISO Charge Types and PX Products as of Stage 4.0 (spreadsheet)
ISO Settlements Guide
SUP Maintenance Upgrade Functional Spec
FileSpecifications.pdf (From ISO web site)
Perot Systems Confidential page 22