1. Stacking Implementation Plan
Presented by: Glen Wingerd
Thursday, February 12, 2004

2. Shut Down Etiquette
The shutdown times listed will be strictly adhered to.
All MPs should submit transactions well in advance of the shutdown time so that large transaction volumes are not experienced just prior to shutdown
(i.e. if you run batch jobs, schedule them throughout the day)!!!
All MPs shall call-in to each conference call, on-time, during the implementation.
All times listed are Central Prevailing Time

3. Initiating Transactions Shut-down timeline
6 hrs
14 hrs
6 hrs
Step 1
Step 2b
Step 3
Step 4 CR
ERCOT
TDSP
ERCOT CR
Step 2a
Step 5
1 am
7 am
7 am
9 pm
9 pm
3 am
Noon
Thursday, July 29th
Friday, July 30th
CR’s will suspend sending 814_01, 814_10, 814_16 and 814_24 transactions to ERCOT Thursday July 29th at 1 a.m.
ERCOT will process all initiating transactions by July 29th at 7 a.m.
TDSPs will process all transactions and respond to ERCOT by July 29th at 9 p.m.
ERCOT will process the TDSP’s responses by Friday, July 30th at 3 a.m.
CRs will process ERCOT’s responses by July 30th at noon.

4. Initiation Shut-down timeline detailed
997s should be provided to the sending parties within the processing windows defined
above. ERCOT will leave their 997 process on throughout the migration.

5. Sub-Initiating Transactions Shut-down timeline
6 hrs
8 hrs
6 hrs
Step 1
Step 2b
Step 3
Step 4 CR
ERCOT
TDSP
ERCOT CR
Step 2a
9 pm
3 am
3 am
11 am
11 am
5 pm
Thursday, July 29th
Friday, July 30th
CR’s will suspend sending 814_08, 814_12, 814_18, 814_26 transactions to ERCOT Thursday July 29th at 9 p.m.
ERCOT will process all sub-initiating transactions by Friday, July 30th at 3 a.m.
TDSPs will process all transactions and respond to ERCOT by July 30th at 11 a.m.
ERCOT will process the TDSP’s responses by July 30th at 5 p.m.
CRs will process ERCOT’s responses by July 30th at 11:00 p.m..

6. Sub-Initiation Shut-down timeline detailed
997s should be provided to the sending parties within the processing windows defined
above. The CR has until 7/30/ :00 to respond with a 997 after step 4.

7. 814_20 Transactions Shut-down timeline
6 hrs
8 hrs
6 hrs
Step 1
Step 2b
Step 3
TDSP
ERCOT
CRs
ERCOT
Step 2a
9 pm
3 am
3 am
11 am
11 am
5 pm
Thursday, July 29th
Friday, July 30th
TDSP’s will suspend sending 814_20 transactions to ERCOT Thursday July 29th at 9 p.m.
ERCOT will process all 814_20 transactions by Friday, July 30th at 3 a.m.
CRs will process all transactions and respond to ERCOT with 814_21s by July 30th at 11 a.m.
ERCOT will process the CR responses (814_21s) by July 30th at 5 p.m.

8. 814_20 Shut-down timeline detailed
997s should be provided to the sending parties within the processing windows defined
above. TDSPs and CRs should respond with 997s by 7/30/04 at 11:00am.

9. 867 Transactions Shut-down timeline
8 hrs
7 hrs
TDSP
ERCOT CR
2 pm
10 pm
10 pm
5 am
Saturday,
July 31st
Friday, July 30th
TDSPs will suspend sending all 867 transactions (867_02, 867_03, and 867_04) to ERCOT on Friday July 30th at 2 p.m.
ERCOT will process the 867 transactions by July 30th at 10 p.m.
ERCOT will respond to TDSPs with 824s related to 867 Transactions by Friday July 30th at 11 p.m.
CRs will process 867 transactions by Saturday, July 31st at 5 a.m.
CRs will respond to ERCOT with 824s related to 867 Transactions by Saturday July 31st at 5 a.m.
824s from REPs received after 11:00 pm on Friday, July 30th will be held at ERCOT until after implementation weekend
867s P-2-P
TDSP will suspend sending 867s to CRs on Friday July 30th at 2 p.m.
P-2-P 867s do not have reject response transactions.

10. 810 Transactions Shut-down timeline
TDSP CR
TDSP
5 pm
6 pm
Friday, July 30th
TDSPs will suspending sending 810 transactions to CRs on Friday July 30th at 5 p.m.
CRs will respond to TDSPs with 824s related to 810 Transactions by Friday July 30th at 6 p.m.

11. 820 Transactions Shut-down timeline
CRs will suspend sending 820_02 transactions to TDSPs on Friday, July 30th at 5 p.m.
CRs that submit 820_02 transactions to their financial institutions and then on to the TDSP should notify their financial institutions of this shut-down.
If 820_03s are being processed, they will adhere to the same shut-down timeline.

12. 650 Transactions Shut-down timeline
CRs will suspend sending 650_01 transactions to TDSPs on Friday, July 30th at 5 p.m.
TDSPs will suspend sending 650_02 transactions to CRs on Friday, July 30th at 6 p.m.
TDSPs will suspend sending 650_04 transactions to CRs on Friday, July 30th at 5 p.m.
CRs will suspend sending 650_05 transactions to TDSPs on Friday, July 30th at 6 p.m.

13. 814 P-2-P Transactions Shut-down timeline
4 hrs CR
TDSP CR
2 pm
6 pm
Friday, July 30th
CRs will suspend sending 814_PC transactions to TDSPs on Friday, July 30th at 2 p.m.
TDSPs will suspend sending 814_PD transactions to CRs on Friday, July 30th at 6 p.m.

14. Implementation Shutdown Overview
Wednesday
Midnight
Thursday
Noon
Thursday
Midnight
Friday
Noon
Friday
Midnight
Initiating
814_01, 814_10, 814_16, 814_24
1 am
6 hrs
14 hrs
6 hrs
9 hrs
814_08, 814_12, 814_18, 814_26
9 pm
6 hrs
8 hrs
6 hrs
6 hrs
814_20
9 pm
6 hrs
8 hrs
6 hrs
867
2 pm
8 hrs
7 hrs
650_01
5 pm
1 hr
810, 650_04
5 pm
1 hr
814_PC
2 pm
4 hrs
Legend
CRs
ERCOT
TDSPs
= Conference Calls

15. Conference Call Times Wednesday July 28th 5 p.m.
ERCOT provides quantities of initiating transactions submitted, health of ERCOT systems
CRs and TDSPs to provide status (state of systems and processing)
Thursday July 29th 9 a.m.
ERCOT provides quantities of initiating transactions submitted and completed, health of ERCOT systems.
Confirm ERCOT is not processing initiating transactions received after Thursday 1 a.m.

16. Conference Call Times Friday July 30th 9 a.m.
ERCOT provides quantities of sub -initiating transactions submitted and completed, health of ERCOT systems.
Confirm ERCOT is not processing sub-initiating transactions received after Thursday 9 p.m.
CRs and TDSPs to provide status (state of systems and processing)

17. Conference Call Times Friday July 30th 5 p.m.
CRs & TDSPs to confirm 650s, 810s and 814 P-T-Ps have stopped flowing (excluding responses); Confirm all initiating transactions processed.
ERCOT to provide status of 867 and sub-initiating transaction processing.
Saturday July 31st 9 a.m.
ERCOT to provide status of 2.0 code migration & production verification
TDSPs to provide status of upgrade

18. Conference Call Times Saturday July 31st 7 p.m.
ERCOT declares Go/No-Go, % complete of production verification
CRs and TDSPs provide migration status

19. Conference Call Times Sunday August 1st 9 a.m.
ERCOT declares Go/No-Go, % complete of production verification (fall-back if it can not be made Saturday at 7 pm)
CRs and TDSPs provide migration status
Sunday August 1st 3 p.m.
ERCOT provides time at which ERCOT will begin accepting Version 2.0 transactions

20. Conference Call Times Monday August 2nd 9 a.m.
ERCOT to discuss any post-implementation issues that have been discovered
CRs and TDSPs provide system status
Tuesday August 3rd 9 a.m.
CRs and TDSPs to provide system status

21. Start up Etiquette
Validation of 2.0 prior to resuming normal transaction volumes
MPs that wish to do this will have to regulate the flow of transactions into and out of their system.
ERCOT will not run special tests with MPs during the migration prior to opening the market with 2.0 functionality.
Any responses that are not sent prior to shut-down will be sent after start-up and will be validated against Version All stacking rules will apply.

22. Conversion Plan Service Orders ‘In Flight’
All Transactions that are sent (including re-drops) and received by all market participants after the implementation of Stacking will be processed under the new Stacking rules and will use the Version 2.0 implementation guides
Date Changes and Cancels received after the implementation of stacking on orders that were scheduled prior to implementation will be processed using the new Stacking rules
Stacking rules that are designed to be executed at the beginning of the evaluation period or on the scheduled meter read date will be executed on orders that were scheduled prior to stacking
For Date Changes, it will be required that for any date changes that the REP has not received a response prior to implementation of stacking, they will have to send a new date change request
For Cancels, it will be required that for any cancels that the REP has not received a response prior to implementation of stacking, they will have to send a new cancel request

23. Conversion Plan Service Orders ‘In Flight’
814_14s and 814_22s that have been sent out prior to the implementation of stacking will not be sent again during their evaluation periods.
For Move-Ins and Move-Outs that are scheduled on the same day for the same ESI ID within 2 business days after the implementation of stacking, ERCOT will cancel the Move-Out and allow the Move-In to complete.
Order information in the form of a spreadsheet and 814_08s for cancelled Move-Outs will be provided to affected TDSPs and REPs
Move-Outs will be cancelled after the implementation of stacking and 814_08s will be sent to all affected parties
Volume is expected to be around 1,000
Once Stacking has been implemented, backdated MVIs/MVOs that are requesting a date prior to implementation of stacking will be processed using stacking rules.

24. Conversion Plan Service Orders ‘In Flight’
All orders that are in a Cancel Pending state at 11:00 am on Friday will be manually cancelled by ERCOT.
814_08s will be sent out for these orders after implementation
The TDSPs will not be able to reject them.
This will require a concerted effort to clean up all potential CWEs prior to implementation weekend
Volume is expected to be around 300
The MCT has reviewed the Option 1 Outages and has determined that implementation will have no affect on it.
For Move-Ins with a status of Permit Pending during migration weekend, ERCOT will re-calculate the PNR expiration to be Requested Meter Read Date +20 Bus. Days. If that calculation yields a date that is less than the first business day after implementation weekend, ERCOT will default to a date that is equal to the first business day after implementation weekend.

25. When bad things happen to a good plan…
At the point that we arrive at conversion weekend, every market participant has:
Provided monthly statuses
Participated in migration conference calls
Passed testing certification.
The inability of a Market Participant to successfully implement would not be a situation where a party failed to build their solution, but rather a situation where there is a technical problem with migrating to their production environment.
Based on this, it is the position of MCT that any issues on conversion weekend will be of the type that cause delays measured in hours not days.
Although it is a fundamental requirement for all MPs that they have a back-out plan, MCT does not envision an issue that would be a showstopper, but does believe there may be a possibility for delay.

26. When bad things happen to a good plan…
If any party cannot implement the stacking solution at any point between July 23rd and August 1st, the potential for delay will be discussed on an emergency conference call.
As determined on the call, the affected parties will develop a plan for resolving the issue(s).
Once Version 2.0 transactions begin to flow, there will be no turning back.
There will not be a reverse migration once Stacking goes live.