The mapping problem mentioned below is a power desk problem only.  The 
mapping problem is purely between the interface of the gas and power trading 
systems and does not affect the book if it is strictly a gas trader's gas 
book.  There was one instance when a gas trader's transactions were 
incorrectly bridged to a power trader's gas book through EOL.  The root of 
this problem was with the EOL bridge not the interface mapping.

The procedure to set up a gas book for power traders includes communication 
to IT regarding the appropriate interface mapping of the book.  If for some 
reason the mapping does not occur, the position will be mapped to a 'dummy' 
default desk.  We will be alerted when positions are loaded to the 'dummy' 
account on a nightly basis in order to investigate the problem and ensure 
that positions do no get lost in the system.  

If anyone needs to further discuss the problem we have been having and why it 
is only the power world that is affected, please give me a call.  

Thanks,
Stacey
(3-1870)



   
	
	
	From:  Tim Belden                           02/14/2001 05:25 PM
	

To: John J Lavorato/Corp/Enron, Stacey W White/HOU/ECT@ECT, Sally 
Beck/HOU/ECT@ECT, Beth Perlman/HOU/ECT, Steve Nat/Corp/Enron
cc:  
Subject: Potential Gas System Exposure

For some period of time, various West Power desks have been the default desk 
which received gas positions for new books that were not properly setup in 
TAGG.  I have worked with our risk team and the techology group to get West 
Power out of this problem.  I'm happy with the result from the West Power 
point of view.  

I am writing to alert you that one half of the problem still exists.  If 
someone does a gas deal and hasn't set up a new book properly and doesn't 
carefully track his/her position, the trade goes into a dummy book that 
nobody manages.  Days, weeks, or months later you discover the trade and take 
the hit or the gain.  I think that this risk is real because we were the ones 
finding the misplaced gas trades before -- not the gas desk with the 
misplaced trade.  Now nobody will find them unless the gas trader realizes 
that some of his/her position is missing.

These are the facts as I understand them.  I'm sure that Stacey White, Steve 
Nat, and Monica Lande could fill you in with more detailed information.  Let 
me know if I can be of further assistance.
---------------------- Forwarded by Tim Belden/HOU/ECT on 02/14/2001 02:18 PM 
---------------------------


Monica Lande
02/14/2001 02:34 PM
To: Tim Belden/HOU/ECT@ECT
cc: Fran Chang/PDX/ECT@ECT, Valarie Sabo/PDX/ECT@ECT, Samantha 
Law/PDX/ECT@ECT 
Subject: RE: Remaining problem with West tot  

Tim,

Steve has described the problem accurately.  Setting up a dummy book solves 
the problem for us, but not for Enron as a whole.  If no one monitors the 
dummy book on the daily basis (which probably won't happen if there is no 
ownership), then you still have the possibility of positions falling into 
that book and never showing up in the book that they were intended.  Why 
can't a process be put in place for the initial set-up of a book in TAGG?

Monica


To: Fran Chang/PDX/ECT@ECT, Monica Lande/PDX/ECT@ECT, Valarie 
Sabo/PDX/ECT@ECT, Samantha Law/PDX/ECT@ECT
cc:  
Subject: RE: Remaining problem with West tot

do you guys agree?
---------------------- Forwarded by Tim Belden/HOU/ECT on 02/14/2001 01:23 PM 
---------------------------
From: Steve Nat/ENRON@enronXgate on 02/14/2001 03:49 PM CST
To: Tim Belden/HOU/ECT@ECT, Stacey W White/HOU/ECT@ECT
cc: Beth Perlman/ENRON@enronXgate 
Subject: RE: Remaining problem with West tot


Tim,  The root problem was related to the default mapping logic in the 
'interface' job that moves the ERMS gas calc results to the portcalc results 
tables.  If mapping logic is not set up for a new book, the job was 
defaulting the gas deals to the ST-PLT desk.  The default mapping has been 
changed to a dummy  ZZ_erms book, which will prevent the deals from showing 
up in the wrong book if the mapping logic is not updated.

In reference to Beth's concerns... turns out this was a limitation in our 
production code, not an IT change to production data, so we should be OK on 
that front.  

The long-term solution would be to remove the hard-coded logic, set-up table 
structures, and maintain the mapping rules through a user screen.  Given our 
other priorities, and the default logic change, we will not pursue this 
option.

Let me know if you have any other questions or concerns.

Steve

 -----Original Message-----
From:  Belden, Tim  
Sent: Wednesday, February 14, 2001 11:49 AM
To: White, Stacey
Cc: Perlman, Beth; Nat, Steve
Subject: RE: Remaining problem with West tot

thanks for the concise description of the problem.  i should have cc'd you on 
the original message.  your description is much better than mine.  now that 
beth has a better understanding of the issue, how long will it take to get 
solved!?


To: Beth Perlman/ENRON@enronXgate @ ENRON
cc: Tim Belden/HOU/ECT@ECT, Steve Nat/ENRON@enronXgate@ENRON 
Subject: RE: Remaining problem with West tot   << OLE Object: StdOleLink >> 

The problem is not that we should enter a reversing trade in the system as 
this would misrepresent the positions across the board.  The problem is that 
the position belongs to another book within Enpower.  The users have no 
access to the screens which define where our gas books are mapped in Enpower; 
therefore, IT has to manually define the correct mapping for us.  When the 
manual fix has not been made, we have true positions for one book mapped to 
another book.

Stacey


From: Beth Perlman/ENRON@enronXgate on 02/14/2001 11:14 AM
To: Tim Belden/HOU/ECT@ECT, Steve Nat/ENRON@enronXgate, Stacey W 
White/HOU/ECT@ECT
cc:  
Subject: RE: Remaining problem with West tot

Tim,

Sorry about this.  A better question to ask is why are systems people 
manipulating data?  Why can't the users put on a reversing trade?  I'm having 
fits about IT resources touching production data and I can't tell you how 
many times we screw ourselves up because IT does this. 

I'll let you know the end result.  Sorry again, but these practices have to 
stop!

Beth

 -----Original Message-----
From:  Belden, Tim  
Sent: Wednesday, February 14, 2001 7:59 AM
To: Beth Perlman/HOU/ECT@ENRON
Subject: Remaining problem with West tot

words cannot describe how distressing this problem is.  in terms of 
mis-reporting our risk, we are dropping mmbtu's from some other book into our 
book as mwhs.  mmbtus go for around $10.  mwhs go for around $400.  why is 
this problem so hard to fix?
---------------------- Forwarded by Tim Belden/HOU/ECT on 02/14/2001 04:58 AM 
---------------------------

 << OLE Object: Picture (Device Independent Bitmap) >> 
Fran Chang
02/13/2001 06:27 PM
To: Tim Belden/HOU/ECT@ECT
cc: Monica Lande/PDX/ECT@ECT, Valarie Sabo/PDX/ECT@ECT, Samantha 
Law/PDX/ECT@ECT 
Subject: Remaining problem with West tot

Tim:

Please note that as of 2/13 there will still be 1,321 MWhs of Nymex Swap 
position in ST-PLT book (COB) which is yet to be cleared out by IT.   I have 
sent out an email to Norman Lee in IT and will follow up with him to make 
sure this problem is removed asap.  (The "unknown" position of the -311,354 
MWhs showing up on 2/12 has already been taken cared of.)  

Regards,
Fran
x7973