Cara,
I agree that we should reduce the number of "names" from a global standpoint now while we can.  
The routing portion of the workspace seems to work well, I agree, but the major issues lie with the confirmation side of it.
On another note, it seems I am duplicating work here.  ie: I am using buildroute, transferring to excel (to get the font/colors, etc) then back to the workspace.
We'll see...I'll hit it again next week.
Thanks for all your "documented" input...it sure helps.

CB


 -----Original Message-----
From: 	Semperger, Cara  
Sent:	Friday, July 13, 2001 4:21 PM
To:	Atta, Asem; Smith, Will
Cc:	Bentley, Corry; Poston, David; Williams III, Bill
Subject:	Continuing testing of Preschedule Workspace, Path Confirmation and Path Cut software

I am working in the target date of June 20th.  Today I added schedules from Palo Verde and the entire MidC sheet to the testing group. Once COB is added, we will have pretty much an average daily volume.

Here is my attached worksheet for Mid C    << File: Mid_C_June20.psc >> 


In Preschedule Workspace:

I added Palo Verde to the group of deals imported, and ran a total of 37 lines into the Path confirmation. The rest of the sheet was all bookouts, and so I marked them for routing only.  I do like the feature of being able to exlude the majority of deals from the path confirmation. This will make the app much faster and less cumbersome for Real Time and Settlements.

I would like the option of printing the error sheet when it comes up, as the lists can be long, and I have to make notes on what is wrong. Also being able to check for errors before running the sheet would save us lots of time.  We currently have a function that checks that all names are recognized before the sheet is imported to paths. This would give us the opportunity of correction before running the sheet, instead of cleaning up afterwards.

Routing functionality question:  If we change a delivery point in scheduling (BPA NW delivered gets moved and changed every day), do these changes not route because the deal entry strip has the original delivery point?  These types of deals route now, I would like to duplicate that existing functionality. I did get an error message on those lines, "Capability not supported: deal has multiple delivery points" Please see the attached sheet, there is a batch of them line 76 thru 86, but it is all deals that are our BPA Northwest Delivered.

The routing speed is EXCELLENT. One second per line or less all the way in Portland on Local Enpower! The megawatts also appear to split properly between mis-matched deal amounts! this is very encouraging. My Palo data was corrupted, so my primary focus for checking routing will be the other delivery points.

My plan is to attack the Alias stuff from a different angle. We are going to work with the team that sets the Enpower "short name" to something that is workable.  I would like to make a new path of approval where the schedulers help set that Enpower short name. 



In Path Confirmation

The early sorting looks good, things look very versatile and useable. 

Yesterday I identified several problems:

1. The entire path needs to be shown in Both counterparty paths. Currently only the upstream or downstream shows depending on if you are looking at the supply cp or the market cp.

2. The Alias list is not functioning properly.  The Enpower Long name needs to be shown in the Collapsed counterparty view, along with the phone number and a check box to indicate if we check out with the cp.

3. Confirming the deals needs to be done as a batch, not pulling up each deal line by line.


Today, I am finding the following:

1.  When a path is pulled up from the line view to the expanded view,  the system blows away the schedule term and the Delivery point.  These fields have to be re-populated before saving can occur.

2.I am not allowed to sort by Global ID,  even though global IDs are populated there. My idea is that if there is a global present it goes in one section, no globals go in another section, and then expaning on the global section gets the individual numbers. (just like the phys vs. non phys).

3. Pulling up an individual path from line view to expanded view takes over 2 minutes.  This is to long to be practical in production for real time. I would like to see this time go to 5 seconds or less.

4.  All paths are showing up as being cut (cut checkbox checked), even though none have been cut yet.

5. The grey on grey color scheme is not going to work, but that is a little thing. Lighter colors for the back ground are going to be preferable. Variations of the beige color are easier to read.

6. The path cut button and dialog boxes I think are going to need alot of work.  It looks like I will have to do all the Enpower work first, and then populate the cut. This is a bit different than we discussed.  My plan is to take this as far as I can, and then hand it over to Bill Williams III and his group for final 'tweaking'.

7. I also cannot sort by tag number.  We need that.



Thank you all for your work on this, it is really looking good. 
I have to schedule on Monday, but will jump right back in when I am finished with daily tasks.

Cara