1 Siebel Service Order Extract MIMO Impact May 03, 2004

2 SIEBEL SERVICE ORDER EXTRACT Table of Contents Siebel Service Order Extractp. 2 Siebel Service Order New Extract Field Namesp. 3 Appendix: Workflow Code Definitionsp.5.

3 SIEBEL SERVICE ORDER EXTRACT Purpose: The information contained within this extract is highly detailed, providing customer registration information such as: Move In Dates Move Out Dates Switch Requests Format: Current extract is delivered to the market via the Portal – Reports page in CSV file format. A DDL doesnt current exist – future direction will not be there in support of MIMO. Changes: MIMO will be adding six additional fields: Cancel_Code, Cancel_Desc, Status_SubType, Workflow_exeception_num

4 SIEBEL SERVICE ORDER EXTRACT NEW FIELD NAMES New ColumnElement Type/Defi nition Position In Extract Description of Business FunctionExpected Values Cancel CodeVarchar2 (80) 58 Code defined by Texas Set (814_08, REF~1P) indicating why the service order or business process instance was cancelled A13 ; A81; ANL; TWO; CCA; CCE; MAN; MOX; COV; B40; CHA; MPC; A95; EB3; PNR Cancel Description Varchar2 (80) 59 Description of the cancel code as defined by Texas Set (814_08, REF~1P REF03) providing a text description indicating why the service order or business process instance was cancelled. Will always populated when Cancel Code is A13 and may be populated when Cancel Code is B40 or MAN. Status Subtype Varchar2 (80) 4 Further defines the Siebel Service Order Status Sub Status In Review Permit Pending Cancelled PendingCR Requested Permit Not Received w/Exception Scheduled CancelledCR Requested Permit Not Received w/Exception ERCOT Operating Rule Customer Objection Unexecutable Rejected by TDSP Complete w/o Transactions

5 SIEBEL SERVICE ORDER EXTRACT NEW FIELD NAMES (cont.) New ColumnElement Type/Definition Position In Extract Description of Business FunctionExpected Values Workflow_E xception _Num Varchar2 (5) 60 An ERCOT trap in support of TDSP Operating Rule #1. When there are 2 processes pending at the same time with different scheduled meter read dates. The dates cannot be flip-flopped or read on the same day. These transactions will be processed and not rejected transactionally (824 will not be sent to TDSP, Usage will be sent to Loadstar, Service Order will require manual intervention to complete), an exception must be logged with applicable information for the EDIM group to research ; 30100; 30200; 30600; 30700; 30800; 30900; 31000; 31200; ; (See appendix for definition) PITS_STAR T DateTime61 Point-in-Time Selectivity (PITS); Used to aid market participants in maintaining the data. Note: For future use by ERCOT. Column will be blank. Provides increased functionality for when ERCOT migrates to the new EDW Retail Components Date/Time Stamp PITS_STOPDateTime 62 Point-in-Time Selectivity (PITS); Used to aid market participants in maintaining the data. Note: For future use by ERCOT. Column will be blank. Provides increased functionality for when ERCOT migrates to the new EDW Retail Components Date/Time Stamp

6 Appendix

7 WORKFLOW_EXCEPTION_NUM DESCRIPTIONS ERROR_NUMERROR_DESCComments 30000Service Instance End Date before Start DateEnd Date before Start Dates should not write to service instances in any situation after MIMO. 867 exception should be thrown instead More than one active Service Instance found for ESI Id This logic should be expanded to all business processes/not just MVI/MVO Move Out did not find a matching Service Instance to update 867s on MOVE OUT, Current REP must match the CR of the row that is being updated. Evaluate If there is an existing scheduled Move In that will make the MVO valid, then throw exception. Else Drop to POLR did not find a matching Service Instance to update 867s on Drop to AREPs – Current REP must match the CR of the row that is being updated. Evaluate If there is an existing scheduled transaction that will make the Drop valid, then throw exception. Else Meter Date is equal to Meter Date on a previous Service Instance This error is thrown for either a match on service instance start date or end date in the case of the MVO Meter Data received on Cancelled OrderThis is a change from existing logic. If an 867 is received on a cancelled order, rather than not updating the service order, the meter read date should be populated and a workflow exception thrown. The service order status will remain Cancelled Meter Data present at time of CancelAt the time that an order is Cancelled if there is meter data present, this error should be thrown. This should not be thrown if the order is manually cancelled SMRD MRD Conflict between ordersTDSP Operating Rule: Crossing the Beams MRD A > MRD B and SMRD A < SMRD B – ERROR MRD A SMRD B – ERROR SMRD A = SMRD B – ERROR Meter Data prior to ESI ID Start Date 31300MRD conflicts with previously received MRD on same service order. If a subsequent 867 is received on a service order with a Meter read date greater than 2 days from the completing meter read date an error should be logged.

8 WORKFLOW_EXCEPTION_NUM DESCRIPTIONS (cont.) ERROR_NUMERROR_DESCComments 31500ESIID Does Not ExistThis is a serious problem that should never happen, as it would mean that the esiid was deleted after the order already existed. It can be done through the front end, so we perform the validation Completion is Pending Another Service OrderThe expectation is that these exceptions will not require manual effort from the Analyst. A Siebel business service will re-evaluate the MVO/DTA orders on a regular basis and will either complete the order without manual intervention or throw the appropriate exception. The exception record should have a link to the order that caused the initial exception. It is understood that over time this identified service order may not be the same order that caused the final update on the orders.