Enron Mail

From:will.smith@enron.com
To:cara.semperger@enron.com
Subject:RE: Preschedule Workspace Testing-June 21 target date
Cc:corry.bentley@enron.com, asem.atta@enron.com,vishwanatha.venkataswami@enron.com
Bcc:corry.bentley@enron.com, asem.atta@enron.com,vishwanatha.venkataswami@enron.com
Date:Wed, 18 Jul 2001 05:53:16 -0700 (PDT)

Cara,

PreSchedule:
1. Concerning the path with transmission data... The original format was based off of Corry's suggestion. Perhaps the two of you need to discuss your needs. However, I should tell you that your approach will require a database access for each transmission, otherwise there is no way for us to determine the POR, POD and firmness for the transmission deal.

2. Can you give Asem and me some deal numbers to look into regarding the Northwest Delivered deals with multiple delivery points?

3. We will resolve the physical / non-physical in the next release, as well as add a "Check for Errors" button.

4. Determining the cause of the speed issues with creating the confirm records can be time consuming. We will work on it right away, but in the meantime try working with smaller sets of data. We will get you a faster solution as soon as possible.

Path Confirm:
1. Sorting... Are Global ID and Tag sorting, just not in an order that you expect? Our tools are sorting strictly by alphanumeric comparisons. If you need the values sorted by numbers, putting the numbers ahead of the description will work better for you.

2. Can you give me a specific example of a path that is missing dashes?

3. I will have Vish change the New Path functionality to require both Supply and Market. If the delivery points are different, should we require a transmission path record?

4. I know we discussed the possibility of tying the new path and path cuts to our other EnPower systems. I apologize if I did not make it clear that this would be a complicated process involving changes to those other applications. There is currently no plan for including those features in this release. Our goal for the first release was to replace your existing Lotus Notes system.


Again, thanks for your testing efforts. We have come a long way due to your diligence.

Regards,
Will

-----Original Message-----
From: Semperger, Cara
Sent: Tuesday, July 17, 2001 6:23 PM
To: Bentley, Corry; Poston, David; Smith, Will; Venkataswami, Vishwanatha
Cc: Williams III, Bill; Cutsforth, Diane; Gang, Lisa; Robinson, Donald; Runswick, Stacy; Wilson, Susie
Subject: Preschedule Workspace Testing-June 21 target date

Good Afternoon:

I have created PSW documents for all 4 of my regions for June 21, here are my findings today:

In PreSchedule Workspace:

What worked:
I was still able to successfully copy and paste large amounts of excel data into the PSW.
I was able to query build route successfully for each delivery point I needed.
I was able to change the color of text and fonts at will.
When running the Confirm function:
I was able to print the error log, which was helpful when I had to fix a few counterparty errors.
The routing speed was still very good.

What needs improvement:
The run time for the Confirm function is still far too slow to be useful in production. The rockies sheet alone took 2 hours to upload, the Mid C sheet took over two hours. I have not been able to populate the full data set because of this speed issue. I will continue uploading today, and try tomorrow to look at the full data set in confirm. I could not import the Palo Verde sheet in to confirm. I got this error message :ERROR:Access violation at address 004ED7E3 in module 'PreSchedWS.exe'. Read of address 00000000.
We need the ability to check for errors before running the sheet, I used another half hour fixing the errors and re-running the sheet.
A spot check of routing shows that the routes are still not showing the appropriate flag for physical vs non-physical. Everything shows non-physical.
Routing still did not happen on the Northwest Delivered deals that were moved in scheduling to multiple delivery points.

Question: Will the sheet support the capability of our transmission legs showing up where the E is now? the weakness with having the path show from transmission 1, 2, etc, is it does not give the POR/POD or the firmness of the transmission.
( The way a path should look is like this: SRP@PV-E-APS(T)PV/WW O#23305 F-WALC(T)WW/MEAD O#464521 MNF-EPMI-NEVP, the way this same path would show if put in to the sheet as it is now will be : SRP@PV-E-APS(23305)-WALC(464521)-NEVP. This is incomplete information.)

OR, would it be possible to modify the sheet to accept the following information in the Trans and Oasis number cells? Instead of APS, put APS(T)PV/WW and in the OASIS cell put 23305 F.


In Path Confirmation:

What worked:
I was able to choose and reset colors that help me read the information better.
The speed to pull up an individual path is MUCH BETTER.
I was able to select a group of paths in the line view and attempt to confirm them. The save takes too long, but it worked.


What still needs work:
I still cannot sort by Global ID or Tag number. Would a different tag logic work, instead of "PWX Tag 123" show "123 (PWX TAG)?" Some marketers use letters for tags.
The cell with the path in the expanded view must auto-size to contain all of the path.
The program needs to insert a dash in the path when each cell boundary is passed.Upstream-Supply-E-Trans-Trans-Trans-Market-Downstream.Right now some run together.
The path cut needs work, it is cumbersome, unclear on some entry requirements, and does not seem to recognize any number I put in it. This app seems like guess-work.

New path needs work as well.
The POR and POD needs to be a type and complete field( like in build route selection) not a first letter drop down list.
The Counterparty list is just too confusing and cumbersome to be practical. It should mimic the deal entry list.
The new record should be three tiered. Supply first, then market,(both mandatory entry), then transmission as an optional third. To allow a Supply without a Market record is going to create many problems.
How are these new records going to be routed?
Also, our original intent was that the new path and path cut would drive deal entry, not deal entry being done and then numbers populated into Path Cut.




I will continue testing tomorrow, the hotspots I see now are the upload speed to Path confirmation, and a close look at how we need the Path Cut and New Path to work.


We are getting there, I am very encouraged!

Cara