ࡱ> ܥhc e~( P-^fT 1` b b b , b 6  X KT P_T $` 5}Z` X**Requirement/ IssueDiscussionPolicyAction 1. SCE HIGHThere are four phases to customer relationship Connect Update (priority; validated) Disconnect Change (Acct Maint) No Policy RequirementAction Item: Need to clarify language and terms for ALL Market Participants.2. SCE LOWAll transactions require the following: (1) Security, (2) Authenticity, Acknowledgment Cellnet: Security and authenticity may be accomplished electronically as well as paper documents. State explicitly that electronic authorization is permitted for all actions unless prohibited by law or regulation No Policy Requirement No Policy Requirement3. SCE HIGHDo the UDCs have any responsibility for fixing data on inbound 814No defaulting on any fieldsInfo provided by ESP is only info to be used for validation in accept or reject; no defaults; no changing. (Agreement on 1/21/99) Agreed **Requirement/ IssueDiscussionPolicyAction 3a Group HIGH What should the DASR Response contain?Trying to get info off Bill Statement can be challenging; so Meter Number can be a problem. In response, UDC mirrors back what was sent in. In response, UDC sends both the mirror of what was sent in as well as different data UDC has on file. Cellnet: DASR response must include previous 12 months billing history including usage and billed amounts, including unbundled components (i.e. distribution, transmission, energy, CTC, taxes, etc.) SCE: Explicitly state what data is to be sent (if name, address, and meter number is adequate, leave it at thatetc. is vague). Information such as previous 12 billing history (including usage and billed amounts) would not be provided. PG&E: Aagrees with SCEs comments. 2/26/99: DASR Request will trigger the sending of Usage History data, but not directly on DASR Response. The Meter Usage Data subtean is developing the details on what information will be included on EDI 867 for Usage History. In response, UDC sends data as they have on file (i.e., Name, Address, Meter #, - as documented in DASR Response data dictionary); only when DASR has been accepted. (Agreement on 1/21/99) Agreed Action Item: DASR subteam to redocument DASR Response data fields. (scheduled for early April)  **Requirement/ IssueDiscussionPolicyAction 4. SCE HIGHIs it a best practice to send all text (Name, Address etc.) sent in upper case?Key Fields are all numeric. Additional elements are required on a per UDC basisIn the transmission, only Upper Case for text is used. (Agreement on 1/21/99) Agreed5. SCE HIGHHow is data changed in UDC or ESP customer data baseIf the UDC is not fixing data, is the maintenance transaction the exclusive means to change data. What fields to communicate as changed is based on Acct Maintenance document.See 3a When data changes (based on Acct Maintenance list of fields) Acct Maint transaction sent to other party (UDC/ESP). (Agreement on 1/21/99)Agreed Action Item: Review list of fields in Document6. SCE HIGHWhat are the acceptable choices for unbundled services; Are MSP and MDMA fields required for DASR acceptanceDA Rule or UDC tariff or both Optional fields on the 814 Implementation Guide. ESPs would like flexibility in not having to specify at time of DASR, but UDCs use this info in other operation processes. Scheduling Coordinator will be included on DASRs. Requiring MSP to be specific on Connect DASR has caused problems with ESPs in scheduling Meter installations. For those who want to specify a specific MSP, then it will be identified in the MSP field on DASR. If ESP specifies MSP, then will it need to be kept updated? ESP will transmit the Billing Option, MDMA, SC and designate the MSP (and Meter Owner) as ESP or UDC or Specific Entity. (Most preferred by non-UDCs; UDCs need to assess impact to other operations.) ESP will transmit the Billing Option, MDMA, SC, and designate the Maint MSP, &; and follow-up with Acct Maint for installation MSP. NWE: Designate the MSP and Meter Owner as at least UDC or ESP. SCE: Does not require the scheduling coordinator information in the DASR (at the account level). ESPs are required to provide this information in the Participation Information Form (PIF) as part of SCEs ESP enrollment process (at the customer level). PG&E: Does not require the Scheduling Coordinator information in the DASR at the account level either. We believe that this information would be more appropriate at the ESP level outside the DASR process. The DASR Connect should identify the ESP, Biller, Bill-Calc, MDMA, MSP & Meter Owner. (Note: Further discussion is needed on requesting vs. not requesting a meter and how these relationships are involved.) SDG&E: Need SC on DASR if ESPs will continue to use multiple SCs. 2/26/99: SC will only be a Conditional field, but still need to determine what (if any) validation should be applied, and the potential future use of this data. ESP will transmit the Billing Option (specific), MDMA (specific), SC (specific), and designate the MSP as at least UDC or ESP. (Agreement on 2/1/99) ESP will designate the Meter Owner as UDC, ESP, or Customer. (Agreement on 2/26/99) SC is optional. (Agreement by SDG&E) Agreed (including MSS discussions) Action Item: UDCs to assess impact to other operations if ESPs only designate MSP as ESP or UDC on DASR. (completed) Action Item: Align Data Dictionary to new Policy. Action Item: Need to clarify what optional MSP designation means; will it still need to be maintained? Action Item: DASR subteam to have follow-up mtg to review DASR / Acct Maint mapping, update as necessary, and republish this documentation. (Scheduled for early April)  **Requirement/ IssueDiscussionPolicyAction 7. SCE MEDDo rejected DASRs include warning messages if applicable?All rejected DASRs use the agreed upon reject code list. Reject code list is a minimum. Text description is optional, warning messages no longer sent.The ESP will receive a reject code for all rejects (that can be determined) contained in the DASR. There will be a standard list of these Reject Codes, maintained by DASR Change Control Process. (Agreement on 2/1/99)Agreed Action Item: UDCs will document their validation rules.8. SCE HIGHIf Account number is the primary key field, is the second key field the same across all three UDCs. Are non-key fields also being validated? What is contained in response? There is difference between validating DASR (key fields) and validating data.See Data Dictionary and Key Fields list from the work group report posted to the PUC website. ESPs need to know what the UDCs use as the secondary key. If using ZIP code, do not require Zip+4. But, ZIP code could be too loose a validation with Account Number. Some ESPs have difficulty obtaining Meter Number for enrollment. Also, certain accounts do not have meters. Want to have some assurance that Acct identified is the right one. PG&E: Primary key is Acct Number; Secondary key is Zip Code SDG&E: Primary key is Acct Number; Secondary key is Meter Number. (Sometimes difficult to get Meter Number) SCE: Primary key is Acct Number, Secondary key is Name & Address (portions). NWE: Any changes to the UDCs secondary keys should be agreed upon by Market Participants through Change Control Process. Cellnet: All three UDCs should move to zip code as secondary key. Meter numbers are more difficult for ESPs to obtain, and name and address are notoriously difficult to match perfectly especially since the service could be in a variety or persons names (husband, wife, etc.) SCE: Previous agreements have been UDCs select secondary field for validation and provide that information to the ESPs. Zip code should not be required as secondary field. 2/26/99: No changes to UDCs key fields for this EDI implementation. Any future changes would go through a formal Change Control process (to be defined). DASRs will include all required fields; including a Primary (UDC Acct #) and Current UDC Secondary key(s) for validation. UDC Secondary key(s) are Conditional, meaning it is required based on the rules for the specific UDC. (Agreement on 2/1/99) Zip +4 is always considered optional. (Agreement on 2/26/99) Agreed Action Item: UDCs clearly document what are the Primary and Secondary keys they validate on. (completed) -SDG&E uses Meter Number as secondary key; SCE uses Name & Address as secondary; PG&E uses ZIP Code as secondary. Action Item: Have Meter Number as Conditional field; have Zip Code as Conditional field & Zip + 4 as optional. Republish Data Dictionary. **Requirement/ IssueDiscussionPolicyAction 9. SCE MEDIf the ESP does not meet the credit requirement for consolidated billing three days prior to DA switch, how does the UDC notify the ESP? Is this handled through Update or Acct Maint? Some ESP billing systems require the trigger from UDC. Update transaction will communicate relationship changes. SCE: Is this issue relevant solely to the CONNECT DASR, or does it include UPDATE DASR as well? Within SCE, there is on going communication with the ESP regarding submitted DASRs and amount of security required prior to account(s) being switched. If an account is switched the ESP is sent a letter informing them the account has been switched to Dual billing. NWE: If the ESP fails to meet the UDC credit requirements the UDC will alert the ESP (designated Contact) by Telephone three days prior to the DA switch date. An account update will be sent to the ESP within ?? days notifying the ESP of the affected accounts. SCE: Failure to establish or re-establish credit will lead to any DASR(s) that do not have adequate security at least one full business day prior to the ESP Consolidated Billing switch date to be switched to the Dual Billing Option. The post switch DASR could be used to provide this notification (confirm all relationships). PG&E: Aagrees to use the post switch confirmation. However, we believe it would be a service to the ESPs to use an Update Transaction in addition to the post switch notification. Therefore, PG&E would like to utilize an Update Transaction to notify the ESP. This would be done three days prior to the DA switch date. (Note: Per Rule 22, Section P.2.C., credit requirements shall not be required until three days before the ESPs customers begin receiving direct access service.) Action Item: ESPs and UDCs can continue discussions on Credit Policies and means of notification. 10. SCE HIGHIf multiple meters (kWh & kVAR; or Multiple kWh; Totalizer/Recorder) relate to the customer account, are all related meter numbers send on the DASR NOTIFICTION ACCEPT? One DASR, one Account, One Meter was original concept.Is the Meter Installation Removal Notification more suitable to convey related meter numbers? Cellnet: Policy should follow procedures developed by meter installation group led by PG&E (Sue Sponsel). NWE: In order for us to send the appropriate information to our MDMA and to retrieve the file from the server the information on all the meters and recorders are necessary, esp. what number the UDC uses to post to the server. SDPI may take care of this, but we can only hope at this time. I suggest the sooner we get this information the better. DASR Accept seems appropriate. SCE: Meter numbers are currently communicated via the form, Supplying Meter Number Information to SCE.; separate from DASR. PG&E: Ccurrently communicates all meter numbers associated with the account. (Could be one or more meters.) ORA: This is partly covered by Issues #21 & #48. 2/26/99: ESPs (and others) need to know what Meter Numbers will be used on MDMA Usage postings. No consensus on what is the best means: the DASR Acceptance Response, DASR Switch Notification, or Meter Investigation (MI). Action Item: DASR subteam to look at adding flag to allow Request MI on DASR Request. (by end of March) 11. SCE LOW How is meter configuration information requested using 814?Is the 650 a consideration for this information Cellnet & ORA: 814 should be used for request, 650 for response. PG&E: , Tthe flag to send meter configuration data is set by identifying that the meter installer is other than the UDC. ORA: May need to update Calif EDI 814 Mapping Guide to use LIN05 codes to support this. Action Item: MSS subteam will determine how to handle the request and response under current situation (not yet using EDI for Meter configuration data). 12. SCERed List information (potentially dangerous customer site) will not be provided by the UDC for liability reasons. UDCs cannot provide red list information to ESPs. (Agreement on 1/21/99)Agreed **Requirement/ IssueDiscussionPolicyAction 13. SCE HIGHExactly what is the content of the Rate Schedule data? (Is it as identified on the customers account record, or as it appears on the bill statement?)For ESP Consolidated Billing, the rate schedule provided to the ESP for processing and billing purposes should be the rate in which the Customers bill is calculated for the UDC portion of the bill. This rate is assumed to be in the mapping for DLF and able to be referred to in the UDC posted tariffs. Cellnet: The UDC must also provide the baseline designation (or baseline quantities) in the DASR response. ESPs wanting to offer energy efficiency services need to be able to recalculate the baseline rate bill in order to establish shared savings amounts; hence the need for baseline designations. SCE: There is no requirement to provide baseline designation informationwhat would be a business need for this information? PG&E: Agrees with SCEs comment. 2/26/99: Baseline and climate zone information for UDCs is often embedded in artificial boundary designations, not easily communicated in transaction field(s). May need to explore means, other than the DASR, for handling this type of data, if needed. The rate schedule provided by UDC will be the same as provided on the Customers Bill Statement. (Agreement on 1/21/99) Agreed Action Item: ESPs, UDCs, and Others can have follow-up discussions on the need and possible means for Baseline zone information. **Requirement/ IssueDiscussionPolicyAction 14. SCE LOWWhat is the format for the SDP elementCellnet: SDP Format should be as follows: 10 followed by DOE identifier (five digits) followed by unique number assigned by UDC. SCE: Policy is driven by results of SDP Working Group. PG&E: Aagrees with SCEs comment. Per SDP subteam meeting of 1/20/99: SDP Format = 10 + DOE Code for UDC assigning the SDP + Unique Id (determined by the UDC). Action Item: Wait for the SDP Workgroup; Need to get final details out to Rule 22. (completed)15. SCE HIGHHas the market resolved the minimum time required to switch a customer to DAGreen Mountain Proposal Cellnet: This is unclear. Does this mean the next scheduled Meter Read no less than 15 days after the DASR is accepted? Please clarify.When no meter change required, DA switch will be scheduled to occur no later than 15 calendar days from receipt of DASR to the next scheduled Meter Read. (Agreement on 1/21/99) When no meter change required, DA switch will be scheduled to occur at the next scheduled Meter Read Date, given that this next Read Date is not too close to the DASR submittal. Too close is considered to be no more than 15 calendar days from receipt of DASR. For DASRs submitted that are too close, the DA switch will occur on the following (one after next) scheduled Meter Read Date. (Restatement of Policy to better clarify intent - 2/26/99) Agreed **Requirement/ IssueDiscussionPolicyAction 16. SCE HIGHWhat is the DASR processing priority rule for multiple DASRs received for the same processing period from more than one ESP?Refer to DA Decision, review language. What about subsequent DASR when prior DASR is still awaiting pending Meter Change? How long does this hold up subsequent DASR? If first DASR accepted in error, need to CANCEL the first, before allowing subsequent DASR to be processed and accepted. SDG&E allows new DASR to override prior one when a new monthly cycle starts (after 15th of the month). Customer has option to call in and Cancel a DASR through ESP. Should the Customer be allowed to force a Cancellation if ESP is not cooperating? Customer does receive letter when switch is accepted. First In has Priority. Subsequent DASR switch can process after the first has been accepted. Switch would take place after prior ESP-Customer agreement in effect at least 1 month (Rule 22 Tariff). PGE: Until another policy is made, PG&E will not overwrite a pending DASR. PG&E will reject a subsequent Connect DASR regardless if the customer is pending a meter change or not. NWE: A prudent business practice between ESPs is to communicate with the customer and each other to resolve the issue. A Connect DASR receiving an acceptance by UDC indicates the account has been scheduled to be switched. Reject subsequent Connect DASR, if first DASR is still Pending, for at least cases without Meter Changes. (Agreement on 2/1/99) A Connect DASR receiving an acceptance by UDC indicates the account has been scheduled to be switched. Reject subsequent Connect DASR, if first DASR is still Pending (even Meter Changes). Agreed Action Item: Continued discussion in other forums to handle the priority processing for Meter Change cases. (By March DA meetings) **Requirement/ IssueDiscussionPolicyAction 17. SCE HIGHInitial ACK in CMEP response (at account level) mirroring ESPs DASR is no longer necessary, replaced by EDI 997 (at file level). DASR CONNECT is responded with: Accept, Reject, Pending.In EDI, 997 will indicate acknowledgment of receipt of file; which would not be at account level. What is the date/time stamp for determining the start of the processing clock? The start will be based on when the VAN received the input EDI file. This may make it more difficult for ESPs to track individual accounts. NWE: We are reviewing this process in terms of system functionality to ensure that we are able to track a (single) DASR sequence performance as opposed to a file with multiple DASRs, since we will not have a time stamp for each DASR. EDI 997 (at file level) will replace the initial ACK response in CMEP (at account level) to satisfy 2-day required acknowledgment. (Agreement on 2/1/99) Agreed Action Item: ESPs need to review impact on their Account tracking.18. SDGE HIGHWhat is the decision requirement for new customer (new premise) and new customer to service territory? Needed for New Customer Flag.In 1999, New Customer required to be able to switch to DA within 5 days. When does 5 days start (when account number assigned)? New Construction is more difficult case to handle. For New Premise, need to have Meter Set. Contractors may want to use ESP meter installed. Cellnet: Five days should start from date DASR is submitted by ESP to UDC. ESP should be allowed to act as customers agent in contacting UDC to initiate distribution service (if permitted by Rule 22). SCE: End-use customer required to initiate time of turn-on with UDC. Time would be five business days from DASR acceptance. PG&E: Aagrees with SCEs comment. (Note: PG&E assigns a 9 digit account number to its residential customers as soon as the customer initiates the turn-on for service. This number can be used on the Connect DASR. PG&E assigns a 10 digit account number to its New Business customer at the initiation of service turn-on.) NWE: We will want to identify when the timeline starts for when we get the account number. Do any of the UDCs have a process or contact for us or our customers to call? How long will it take to get an account number assigned? Action Item: Need subgroup (UDCs and interested ESPs) to review proposals and determine what can work; including notifications, account number, meter number, etc. Action Item: UDCs will clarify how their new Account Numbers will be communicated to ESPs.  **Requirement/ IssueDiscussionPolicyAction 19. SCE HIGHFor a Pending DASR with meter change, is a final response sent later with the actual switch date (After Switch Response).A DASR is Accept, Rejected, or Pended based on acceptance criteria, a pending meter change is a separate issue. ESP needs to know how to closeout Pending cases. Any DASR response in Pend or Accepted with Meter Change status, requires a final DASR response. SCE: Refer to the Data Dictionary for list of required fields. Post switch message contents would depend upon who the recipient is in the case of a Disconnect DASR (ESP1, ESP2). Need to identify what other information is provided in post switch notification (i.e., key fields?). PG&E: The post switch message is communicated from the UDC to the ESP to inform them that the switch took placeregardless of whether a meter is installed or who installed the meter. ORA: The described policy seems to apply to meter installations by UDC. If the ESP does the installation, the processy is as described by the MSS Group. UDCs send Post-Switch Notification for all accepted Connect & Disconnect DASRs; including Meter Number, Date. (Agreement on 1/21/99) Agreed Action Item: Need to look at how to accomplish this in systems & when it can be made available. Action Item: DASR subteam to determine what Meter Number(s) need to be sent in Post-Switch Notification. (by end of March)  **Requirement/ IssueDiscussionPolicyAction 20. SDGE HIGHHow long is it reasonable to hold an accepted DASR that requires a meter set, if the meter change does not occur.If installation has long lead time, would not want to have process interrupted (especially for cities, government agencies, and customers with high security and coordination requirements). Need process to extend time limit, in certain cases. Some want warning notification from UDCs when getting close to expiration. SDG&E needs to move forward on this policy. UDCs would prefer to not have to provide advanced notification; just send Disconnect notification. To extend, would ESPs need to resubmit DASR? After 3 months, an accepted DASR with Meter Change that has not been installed, a Disconnect is sent. DASR expires 180 days from time of Accepted. DASR expires 180 days from time of Accepted, with ability of ESP to extend, otherwise Disconnect. PG&E: It was agreed at the 2/1/99 meeting that the group does not support an extension or notification of the Disconnect. PG&E supports the 180-day rule. ESPs would be required to submit a new DASR in order to pend the account NWE: Another option is to allow the ESP to assign the date the DASR will expire. This would give the ESP control versus an arbitrary date. After 180 days, an accepted DASR with Meter Change that has not been installed (for an official switch), Pending status is canceled and a Disconnect is sent, with reason in transaction. Existing DASRs are grandfathered, tied to EDI implementation time. (Agreement on 2/1/99) .Agreed **Requirement/ IssueDiscussionPolicyAction 21. PGE (see #10)Each 814 represents one DASR per one account, can it represent zero or more than one meter if the account represents multiple meters?DASR can be for unmeter as well as metered service. The transaction set can handle multiple meters in one 814. UDC Policy determines if one DASR can be for one or more Meters. NWE: This information should be disclosed in order to make an informed decision. Once established by UDC, it can only be changed with appropriate (30 days?) notification to ESPs. Note:Check documentation for definitions: Connect/Update (Replace) Account Maintenance/ Information Request ResponseNote:Relationships refer to MDMA, MSP, Billing Agent, etc.22. PGE HIGHFor UPDATE, ACCT MAINTANCE, should the DASR (request/response) identify all relationships? Or only relationships that are changing providersPer documentation these are two transactions. Requirement to know all relationships is not DA Decision requirement Acct Maint is Customer Profile type information, while Update is more Billing/Relationship type of information. On ACCT MAINT, send additional confirmation response if change applied (avoiding future resubmittals of same Acct Maint)? For UPDATE and ACCT MAINT transactions, only need to supply required fields relative to what is actually changing. The UPDATE Response will confirm those changed items (i.e., what was submitted on Update). The ACCT MAINT will only have an Accept/Reject Response, does NOT require other party to make change. (Agreement on 2/1/99) Agreed Action Item: Need to document Update Response Data Dictionary. **Requirement/ IssueDiscussionPolicyAction 23. PGE HIGHFor UPDATE, should the response communicate the effective start date for each relationship (pending or current) identified in the requestPer documentation these are two transactions. Requirement to know all relationships is not DA Decision requirement. Information exchange is bi-directional. Updates to relationships still use existing Connect DASR logic? Some ESPs would like to use Requested Date to stage Connect DASRs. Will address this possibility in the future. For UPDATE, single date in submittal (Requested Date) and response (Effective Date) will apply to all identified relationships. Effective Date is based on acceptable date using existing relationship change rules (usually at next Scheduled Meter Read date). If different dates needed, send separate UPDATE transactions. (Agreement on 2/1/99) Agreed 24. PGE HIGHFor UPDATE, ACCT MAINTANCE, should the response communicate the status for each relationship identified in the requestPer documentation these are two transactions. Requirement to know all relationships is not DA Decision requirement. SCE: Isnt this issue similar to #22 above? 25. PGE HIGHUPDATE DASR will communicate changing ESP relationships and new providersPer documentation Update DASR is a replace. Requirement to know all relationships is not DA Decision requirement. More for future considerations. NWE: Per previous agreed upon policy (#6), the ESP is not required to provide the MSP. It is optional to specifically name that entity. SCE: Isnt this issue similar to #22 above? PG&E: Agreement to only send changing relationships as stated in #22.  **Requirement/ IssueDiscussionPolicyAction 26. PGE HIGHUPDATE RESPONSE will confirm all changing relationships and their providers and one status and one start date.Per documentation, Update DASR is a replace, showing all fields. Requirement to know all relationships is not in DA Decision. Dependent on how many changes included in given UPDATE transaction. Is logic for effective date on change similar to Connect? One transaction per Update. UPDATE RESPONSE confirms all changing relationships and their providers with one overall status and one start date. Switching logic is same as the Connect DASR switching logic (including #15). The Update Transaction will be used to communicate all changing relationships. UDC will send one Update response per ESP Update transaction. (Agreement on 2/26/99) Agreed 27. PGE HIGHCONNECT DASR sets up New ESP and associated relationships, all relationships and their providers will switch together.Requirement to know all relationships is not DA Decision requirement.CONNECT DASR sets up New ESP and associated relationships. All relationships and their providers switch together. (Agreement on 2/26/99) Agreed 28. PGE HIGHCONNECT RESPONSE DASR will confirm all relationships and their providers with one status or date. The status and date are shared by all relationships.Requirement to know all relationships is not DA Decision requirement.CONNECT RESPONSE DASR confirms all relationships and their providers with one overall status or date. The status and date are shared by all relationships. (Agreement on 2/26/99) Agreed 29. PGEFor Disconnect, DISCONNECT DASR will communicate the ESP relationship/provider to disconnect.For DISCONNECT, Disconnect DASR will communicate the ESP relationship/ provider to disconnect. Meter Ownership is important information for UDC (Update DASR can be used to provide this information). If a Meter Change is required, an effective date is blank; supplied later when Meter Change takes place. PG&E: If the ESP1 owns the meter, is ESP2 placed in pend-meter status awaiting the meter change? Disconnect DASR applies to all relationships for that Account, except for Meter Ownership if Customer owns the meter. (Agreement on 2/1/99) Agreed Action Item: Bring to OCC (3/2) to have discussion on how to handle meter switch situation. May end up with DASR subteam.  **Requirement/ IssueDiscussionPolicyAction 30. PGE HIGHDISCONNECT RESPONSE PGE will confirm the disconnect to the ESP with a disconnect response. All relationships subcontracted to the ESP are disconnected and share the same stop date.Is there a market requirement? What are limitations on the date for Disconnect? Can ESP select a specific Disconnect Date? SCE: Disconnect rules should follow Connect rules (At a minimum, 15th of the month scheduling logic. More likely, however, the Green Mountain proposal should also be adhered to for Disconnect). ESP selected specific Disconnect date would not be allowed. PG&E: Agrees to SCEs comment. Disconnect rules follow Connect rules, including #15. Agreed 31. PGE HIGHUPDATE DASR will communicate those changing relationships and their new providers.Is there a market requirement? Need to be clear on consistent interpretation and use of codes in EDI. If same date, can send multiple changes on one Update transaction (EDI 814); otherwise would require separate Update transactions. Cellnet: UPDATE should also be used for UDC rate changes (e.g. to TOU). SCE: UDC rate changes would be communicated via an account maintenance transaction. Does not require the scheduling coordinator information in the DASR. ESPs provide this information in the Participation Information Form (PIF) as part of SCEs ESP enrollment process. SDG&E: UDC rate changes are communicated via account maintenance, per 8/98 agreement. UPDATE DASR will only be used for changing relationships - Billing Options, MSP, MDMA, Meter Owner, SC. (Agreement on 1/21/99) SC and Rate Schedule changes will be handled by Acct Maint transaction, not Update DASR. (Agreement on 2/26/99) Agreed **Requirement/ IssueDiscussionPolicyAction 32. PGE HIGHUPDATE RESPONSE will communicate changing relationships and their providers and one status or start date.Is there a market requirement? SCE: Is this issue similar to #26 above? PG&E: Yes  33. PGE HIGHACCOUNT MAINTENANCE data should not be restricted to standard switching logic. Can send data that changes along with key fields.Is there a market requirement?Account Maintenance transactions will handle non-relationship changes. Required fields are determined by the requested change. (Agreement on 1/21/99)Agreed34. PGE HIGHACCOUNT MAINTENANCE RESPONSE will include Key Fields and changed data onlyIs there a market requirement?35. PGE HIGHAre Key fields sent for every transaction?Yes Should this be stated as All Required Fields sent with every transaction?All Appropriate Key Fields are sent for each transaction. (Agreement on 1/21/99)Agreed Action Item: Need clear definition of Key Fields (esp Acct Number), what is the minimum set. (closed - see #8)36. PGE LOWResend request (ESP to UDC) will communicate Key Fields onlyIs there a market requirement? Future consideration.37. PGE LOWResend Response will communicate one relationship/provider and all associated dataIs there a market requirement? Future consideration.38. PGE LOWIf data is missing or incorrect a DASR is REJECTED, UDC will send Reject Code in the REF02 and further clarification in the REF03If data is missing or incorrect a DASR is REJECTED, UDC will send Reject Code in the REF02 and further clarification in the REF03. Looking for Clarification of EDI Transaction Rule.Action Item: DASR subteam will include consistent set of Reject Codes as part of the remapping and re publishing of documentation work. (by end of March)  **Requirement/ IssueDiscussionPolicyAction 39. PGE HIGH After Switch Notification to ESP (Confirmation) is sent after switch Notification upon completion of Enrollment, confirming meter switch Is there a market requirement? SCE: Isnt this issue similar to #19 above? 40. PGE HIGHAfter Switch Notification (Confirmation) is sent after every switch to a new relationship providerIs there a market requirement? Who notifies the new ESP who was the old ESP to get Historical Usage data? ESPs may need to maintain contact information on each other. To exchange EDI data, will require some trading partner or MDMA server information sharing among ESPs. After-Switch Notification (Confirmation) is sent after every switch to a new relationship provider. On Disconnect, this will include the new ESP (Dunns #), to indicate where to send Historical Usage data. On new Connect DASR Response, let the new ESP know who was the old ESP (Dunns #), for obtaining Historical Usage data. (Agreement on 2/1/99)Agreed Action Item: ESPs need to work out how to inform each other of contact, server information, etc.41. PGE HIGH After Switch Notification (Confirmation) is sent after every switch to a new ESPIs there a market requirement? SCE: After-Switch Notification (Confirmation) is sent after every switch to a new ESP. On new Connect DASR Response, let the new ESP know who was the old ESP (DUNS #), for obtaining Historical Usage data. PG&E: Requirement #41 was replaced by # 40. 42. PGE LOWIn the 814, what REF codes should be identified in the account level LIN loop and the meter level MN1 Loop. EDI Map question.43. PGE LOWAgreed upon definitions for ESP, (OLD) ESP, Current ESP, Pending (NEW) ESP, UDC, LDC, UIG Codes and California Market codes.  **Requirement/ IssueDiscussionPolicyAction 44. PGE HIGHAdd SDP element to list of key fields.SDP is one of Key Fields after initial response. Cellnet: SDP should be the primary Key Field in all transactions once SDP is available. SCE: SDP is included in the Connect/Update transaction data dictionary, and would not be a primary key field. SDG&E: After SDP is initially provided to ESP in Connect DASR Acceptance, it becomes a required field in all subsequent transactions. After SDP is initially provided to ESP in Connect DASR Acceptance, it becomes a required field in all subsequent transactions. But, initially, it will not be used as a Key Field to Reject the transaction. (Agreement on 2/26/99) Action Item: Market Participants need to have follow-up discussions to determine the expected use of SDP identifiers in various transactions. 45. PGE LOWMake sure California guide terminology is consistent with UIG46. PGE LOWRevisit required fields for Connect, Disconnect, Update, Account MaintenanceCellnet: SDP should be the primary Key Field in all transactions once SDP is available. SCE: Required fields for Connect, Disconnect, and Update, are the same (the exception being that the Update DASR would communicate only the relationships that are changing). PG&E: Required fields are subject to change. However, key fields should remain consistent with all transactions. Action Item: DASR subteam to have follow-up meeting to review DASR/Acct Maint mapping, including required fields and republish this documentation. (by end of March)  **Requirement/ IssueDiscussionPolicyAction 47. SCE HIGHWill communicate notification of turn off request when turn off is issued and every time the turn off is rescheduled or is cancelledIs there a market requirement? Is Policy dependent on size of customer? Also, if UDC not the MDMA, is advanced notification needed? What other information needs to be included? Distinction between temporary shut-off and moving out turn-off. Notification (EDI) is the key issue. 48. ORA HIGHNeed to identify when kVAR metering required.Need to know if kVAR required for Billing. Also, how to handle multiple meters that include kWh & kVAR. On DASR Response, include ALL meters. How will ESPs know about totalizers and recorders? Are the Meter Specific Services forms (maybe EDI 650 in future) better suited for communicating detail meter data, instead of DASR Response? EDI 814 DASR Response will identify if account requires kVAR for Billing. DASR Response will include identification of all Meter ids on the Account. (Tentative pending UDC action item to determine feasibility on DASR Response)Action Item: UDCs to determine how they could deliver the kVAR identification. (2 weeks) Action Item: Need flag (code) in EDI 814 for identifying if kVAR needed for billing. 49. PGEES HIGHConsistency on combination of identifiers with DUNS numberCellnet: SDP should be the primary Key Field in all transactions once SDP is available. SCE: DUNS required for MDMA; conditional for MSP and meter owner.  **Requirement/ IssueDiscussionPolicyAction 50. SDGE HIGHTimeline for migrating to EDI 814; including which version (4010).Policy changes will take effect when EDI implementation takes place; a packaged deal. Will there be an Operational Manual that documents the new Procedures and Policies? The EDI 814 version 4010 will be the accepted version for All at time of Implementation; no interim changes to existing EDI 814 3070 version or CMEP would be made. (Agreement on 2/1/99)Accepted Action Item: Document Calif EDI 814 mapping guide for version 4010. Action Item: DASR Consistency subteam to provide new procedures & processes to Operational Manual subteam. UDCs initially posted EDI schedule to Rule 22 in Sept 1998 (spread throughout 1999). 51. SCE LOWHow to communicate Tax Exemption status?Issues on whether and what information should be communicated. Cellnet: This should be communicated in the DASR Response. SCE: Issue currently being addressed outside of DASR Working Group. Action Item: Resolve in separate forum. (In Conf Call on 2/8/99, if this status gets communicated, the DASR/Acct Maint will be used)  **Requirement/ IssueDiscussionPolicyAction 52. NWE NEW NWE: How to communicate Invoice Number / Billing Account Number?NWE: The invoice number will be provided to the ESP in the DASR Response. SDG&E: Recent meetings confirmed that the Billing Acct. No. will be an Acct. Maint. transaction, per 8/98 agreement. The invoice number (UDC billing account number) will be provided to the ESP in the DASR Response. Any changes to that number will be communicated via Account Maintenance transaction. (Agreement on 2/26/99) Agreed 53. NWE NEW NWE: How to communicate accounts, which are Load Research, that go DA?NWE: The DASR Response will indicate accounts that are Load Research. SDG&E: Support adding this field to the new std. format for DASR Status Notification Accept. Action Item: New West Energy will clarify the business needs for this information and specify what data. 54. SCE NEW SCE: Update Data DictionarySCE: Disconnect DASR is not used to switch a customer; the Connect DASR is sent by the ESP to the UDC to connect a customer per the Data Dictionary.  DASR / Account Maintenance - Business Policies/Issues ** - Prioritization: HIGH = Consistency Needed Across Market Page - page 4 DASR / Acct Maint Consistency Group MED = Agreement between Specific UDC & ESP may be sufficient As of: 3/31/99 LOW = Not Business Policy, more Technical Issue " =/88`"1INvTUklmu     ( + 6 F G J Ľ BEFd2b BEFʃ2Fb BEF܃2Fb BEFɃ2Fb BEFS2fb BEFS2fb BEFS2fb BEFY2bBEFY2^bBEFy2&UbBEFy2&UbUbU^b AEFy2&EFy2& BEFy2&bb^bUUc5 j "9$Blټۧۑۊ BEF2b BEF2bBEFe2^b BEF2b BEFf2b BEFS2fb BEF˃2Fb BEFS2fbBEFS2f^bUUcUbVb^bb BEFe2bABEFY2b BEFd2b BEFY2bBEFd2^b4()349:>HI{~cewxy[\_vpOR f!ɺ𪣜 BEF̃2Fb BEFY2bBEFY2^bBEFy2&UbBEFy2&UbU^bUcUbUWUVbV^b^b BEFm2b BEFl2b BEF2bb BEF2b BEFg2bm@v@y@@@@BBQDRDUDXDDDDDDEEE EEElF)GGGGGGIIJJKKK{MMMMٺ񳬳ٞ BEFy2&b BEF 2b BEF2b BEF2bBEF\2^bhUc BEFy2&b^bUVUVbb BEF2bABEF\2b BEF2b BEF\2bBEF2^boBowooooppp q9q:qAqÿÿöÒÿVb BEFZ2UVbBEF2UVbBEF2UVbBEF2UVbBEFՃ2FUVbUVbBEFZ2UVbUc BEF2b BEF2bBEF2^b^bb BEFZ2b BEF_2bBEF_2^b8Aqrrrrrr=s>s?ssPtRtUtltwttuuu vvvvvvvvvvvvvvw!w"w#w$w+wyxxxxxxxЫ┋ BEFy2&b^bVBEFփ2FUVbBEFZ2UVb BEF2b BEFa2bBEF2^b BEF2b BEFփ2FbBEFZ2bh BEFZ2b BEF`2bBEF`2^bUcUVbU BEF2b BEF2bBEF2^bb.xxxyyyyyyy*z+zzzz{{({?{J{Y{{{{||||!|$|'|(||r}}}|~EAE\gv/25[\036Շ BEFZ2b BEFZ2b BEFb2bBEFb2^b BEF2b BEFT2fbUcUVbUWbU^bUb BEF2b BEFZ2bb BEF׃2Fb BEFa2bBEFa2^b:Շه 23UlwDFILS_cr}=>$%]df'CPdefjm؎َێžžډ BEF2b BEF܃2Fb BEFك2Fb BEFy2&bUVb BEF؃2Fb BEFZ2b BEFZ2b BEFb2bBEFb2^b BEFy2&b^bUc BEF2bBEF2^b BEF2bb BEFZ2b BEFZ2b6ܓڔ1369uv|}-/25stv"1569:=?BEʚ˚͚ҚD!"%&󹰹UVbBEF܃2FUVbUVb BEF܃2FbBEFc2UbU^ BEFۃ2Fb BEFڃ2Fb BEFc2bBEFc2^b BEFy2&bb^bUcUUbD&)+.1svwxy/JOPQǞΞϞԞ՞֞מ؞z}~ĹuPauDBEF2fPPUc c BEFۃ2Fb BEFڃ2FbBEFc2^bUVb BEF܃2Fb BEFc2b^bbBEFc2Ub.")1259>?nv#$L\o~" h3 48h() h3w33333l LH ,s5333~UVmvw~EF333333l LH ,s533 48h() Fvw a b i j   \     33l Lj ,t5333l LH ,s5333     F ;YIJ}~d                     33l Lj ,s5333&deQRxyHI[\]_bvpKRS  33l Lj ,s5333l Lj ,s53!SSTUMNO !!/"0"(#)#g#h#o#p###N$O$$33!33l Lj ,s53$$$$$$%%%%%%% & &F&G&''((**+++M,N,O,l Lj L,p533!33l Lj L,s5333l Lj ,p5O,S,W,\,<----..//00r0s0001111111122=2m2n222)3*3333l Lj L,s5333!33%34 4!4%4)4*44444444 555$5%5)5-525566&8'8888899A:B:I:J:33333l Lj L,p53$J::::::::;;; ; ;4;;;;;<<<<<<<<<=P=j=k==>>n@o@v@33333l Lj L,p53$v@w@y@|@@@@@@@@@5A\ACCQDRDEEEEkFlF)G*G1G2GGGGGG333l Lj Q,p5333l Lj Q,p5 GGGGGGGGHIIJJKKKKKKKKiLzM{MENFNNNN P,l @Lj L,o5333l Lj L,s533 P PPPPQQQQQQRR#R+R,R0R4R9RRUSVSSSTTUU%V&VVV33l L7,s5333l Lj L,o53VVVWWWWWWWWWWWWWWWIXGZHZZZZZ?[@[&\'\\\]333l L*j,s5333l L;,o533]]]]]]]]^ ^ ^^^^^T_U_ ` ` ` ```9`T````` V3Vl L*j L,p53l L*j L,s5333l L*j,p53```````````haMbNbbb=cdd d!dadbdddgd{ddddddddl L*j ,s5333333l L*j L,p5 d-e~ffgggggggehhhi i i i iiiiciiijjjjjjjjjjkk333l L*j ,p533$k k'k/k0k4k8k=kkll1n2n9n:n;n?nCnHnnooooooooo?pp9q:qAqBql L*L,o5333l L*L,s533"BqCqGqKqqrr>s?sssssQtRtStUtXtltwt~ttttttJuuuvv3l L*,s5333l L*L,o53l L*L,q5vvv#w$w+w,w-w1w5w:wwxxyxxxyy*z+zzz{{%{&{({+{?{J{Q{Y{Z{^{l L*,s53333l L*,o53!^{b{g{{{{||(|)|*|+|,|1|5|:|||s}z}{}}}}}}}}}}}~-~1~2~|~~~~4Fl L*,p533(FGKOS(^_`aeimABCEH\gnvw{33333l L*,p5%./\]^_`dhmЃELM/034567;?Cl L*,o53l L*,p53$CˆÈĈňɈ͈шNOPQRSUXlw~EF=>l L*l,o53333l L*,o53">$%Œ ]efَڎێŏ3333l L*l,o53%ŏJefghiqvܓ78ڔ23vwxyz|l L*,s53333l L*l,o53"jst&'|}~./tuv")12  333l L*,o533%26:>?͚̚CD"&*+sKLMNOP             63l L*,o53&PJ{|}~63 3!T p5 3 !p5 K@Normal3a $@$ Heading 1Uc.@. Heading 2DUc*@* Heading 3 Uc"@" Heading 4U@ Heading 5U"A@"Default Paragraph Font @ Footer !)@ Page Numberc @ Header !B@" Body TextU~~!!!!!!!!! ! ! ! ! !!!!!!!!!!!!!e\]^0!!!'(N)O)-...17x=DKMNNNTZcagTq'xDT{~Lj       $ 9,/ f!M,3;MThAqxՇ&PQRSTUVWXYZ[\]^~F dS$O,3J:v@G PV]`dkBqv^{FC>ŏ2P~_`abcdefghijklmnopqrstuvwxyz{Unknown Chris KingStandard ConfigurationA Valued Microsoft Customer8Standard ConfigurationA Valued Microsoft Customer2d8Standard ConfigurationA Valued Microsoft Customer28Standard ConfigurationA Valued Microsoft Customer2u8Standard ConfigurationA Valued Microsoft Customer2y8Standard ConfigurationA Valued Microsoft Customer28Standard ConfigurationA Valued Microsoft Customer2 ~~/!U^>E}A F 2 7 UZ{<@aehm48 W[05~ ""##i'm'(())v)z)))***+--..n/u/C0H000111134g4k45556X7\7^7b748;8999"999k:r:<<==2B6BFFGGHH{JJKKwM|MNN%N)NNNNNOO=PEPkPoPRS&S*SoStS*T1TaVeVVV+W/WXXYYyZ~ZZZ[[]]^^____ccHcMcppHqOqssyuu^vbvvvww | |~~~>B݁w|[_]d$)@I >BNX/3uyڑٔ$'+ PXStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (3-31-99).doc@HP LaserJet IIPLPT1:HPPCLHP LaserJet IIPHP LaserJet IIP@g,,@MSUDHP LaserJet IIPd HP LaserJet IIP@g,,@MSUDHP LaserJet IIPd 1Times New Roman Symbol &Arial"h44 2wAYK Proposed ByStandard ConfigurationStandard Configuration  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root EntryGFE Conf Call Agenda for 4-16-98 (2pm).do F N_e}DQIWordDocument# EDImtg.docEDIMTG.q<@G>2rofile Protocol (5-5-98).docLOADPR~26FCompObjG Mtg Notes from 5-7-98.docDQIWG~10.DOCp~H CDT Mtg Notes fromjOCSummaryInformationh @(MainP`                                          DocumentSummaryInformation8 Root EntryGFE Conf Call Agenda for 4-16-98 (2pm).do F N_e}DQIWordDocument# EDImtg.docEDIMTG.q<@G>2rofile Protocol (5-5-98).docLOADPR~( FCompObjG Mtg Notes from 5-7-98.docDQIWG~10.DOCp~H CDT Mtg Notes fromjOCSummaryInformationh @(Mainor Windows 95F@@V!b@"}@B}V՜.+,0HPt|  Southern California Edison,B  Proposed By FMicrosoft Word Document MSWordDocWord.Document.69qOh+'0  ,8 ` l x  Proposed ByKFStandard ConfigurationG Normal.dotStandard Configuration3Microsoft Word f                     TO          TLL              T OO        TLL   TL  TL           TTLLL  TL      TTLL    YY YYG  YG          YYYYGGG  TO    TKKK           T KKKh  ydh           ~~\\\\\\h  h              h  TOh     TLh h h  TLh  TLh     TTTLLLh  h  h     h           O   KK  KK  MM    KKKK                                                                   b         bb  b       b   b  b  bbb     b            9,/ f!M,3;MThAqxՇ&QvPQRSTUVWXYZ[\]^~F dS$O,3J:v@G PV]`dkBqv^{FC>ŏ2PQ_`abcdefghijklmnopqrstuvwxyz{9Unknown Chris KingStandard ConfigurationA Valued Microsoft Customer8Standard ConfigurationA Valued Microsoft Customer2d8Standard ConfigurationA Valued Microsoft Customer28Standard ConfigurationA Valued Microsoft Customer2u8Standard ConfigurationA Valued Microsoft Customer2y8Standard ConfigurationA Valued Microsoft Customer28Standard ConfigurationA Valued Microsoft Customer2 8Standard ConfigurationA Valued Microsoft Customer2 8Standard ConfigurationA Valued Microsoft Customer2 Employee GEW @~/!U^>E}A F 2 7 UZ{<@aehm48 W[05~ ""##i'm'(())v)z)))***+--..//00001122J4Q444 66N6R6777788S9X9k9r9: :::= =?>D>BB&G*GGHHHJJ+L0LMMaNeNuNyNNN?OCO"P(PPPPPJSRSvSzSSSzTTVVWWWW7Y;YoYsYZZZZm[r[[[[[[[[[\\&\)\]]b^f^@`E`aaa#aodsdddoqsqrr;u@uvvwwxx?yDyg}j}Zc;?Ճڃ]bKR# UY}АԐ !ʒΒIMvzeldk~.2sx:>BFAXStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (2-25-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (3-31-99).docStandard ConfigurationWC:\My Documents\Direct Access\DA Workshops\DASR - Acct Maint Bus Policies (3-31-99).doc@HP LaserJet IIPLPT1:HPPCLHP LaserJet IIPHP LaserJet IIP@g,,@MSUDHP LaserJet IIPd HP LaserJet IIP@g,,@MSUDHP LaserJet IIPd 4444VbUVbUVbVWbTdg (M)-...0/A/B/0o16778c99;=gTTTT.[0[Y[a[b[e[m[s[[[[[%\2\&klcmmnoqrKuux yy{yefst0IK:ÓϚGIIJK<=>?@@@@d@"@g#@+@M,@0@1A1AA@1@1@3@4@8@9AJ:@:A<@<@>@n@AWA@W@W@AAAAA AAA$AhAjAoA@]@l@:n@o@o@p@Bq@?s@Rt@v@,w@+zAz@z@{@>AA)A*@@AێA7@@@P@QARA@ۓA@5A8@@D@@A@@@P@P@@AAQ@֞@z@{@|@}1Times New Roman Symbol &Arial"h4 4 23VBYK Proposed ByStandard ConfigurationStandard Configurationܥhc e~26-P2d^51""""""""....,//05X5K0{"P_""""0*" 9  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGQRSTUVWabcdefghijklmnopqrstuvw***""".e}".*X***Requirement/ IssueDiscussionPolicyAction 1. SCE HIGHThere are four phases to customer relationship Connect Update (priority; validated) Disconnect Change (Acct Maint) No Policy RequirementAction Item: Need to clarify language and terms for ALL Market Participants.2. SCE LOWAll transactions require the following: (1) Security, (2) Authenticity, Acknowledgment Cellnet: Security and authenticity may be accomplished electronically as well as paper documents. State explicitly that electronic authorization is permitted for all actions unless prohibited by law or regulation No Policy Requirement No Policy Requirement3. SCE HIGHDo the UDCs have any responsibility for fixing data on inbound 814No defaulting on any fieldsInfo provided by ESP is only info to be used for validation in accept or reject; no defaults; no changing. (Agreement on 1/21/99) Agreed **Requirement/ IssueDiscussionPolicyAction 3a Group HIGH What should the DASR Response contain?Trying to get info off Bill Statement can be challenging; so Meter Number can be a problem. In response, UDC mirrors back what was sent in. In response, UDC sends both the mirror of what was sent in as well as different data UDC has on file. Cellnet: DASR response must include previous 12 months billing history including usage and billed amounts, including unbundled components (i.e. distribution, transmission, energy, CTC, taxes, etc.) SCE: Explicitly state what data is to be sent (if name, address, and meter number is adequate, leave it at thatetc. is vague). Information such as previous 12 billing history (including usage and billed amounts) would not be provided. PG&E: Aagrees with SCEs comments. 2/26/99: DASR Request will trigger the sending of Usage History data, but not directly on DASR Response. The Meter Usage Data subtean is developing the details on what information will be included on EDI 867 for Usage History. In response, UDC sends data as they have on file (i.e., Name, Address, Meter #, - as documented in DASR Response data dictionary); only when DASR has been accepted. (Agreement on 1/21/99) Agreed Action Item: DASR subteam to redocument DASR Response data fields. (scheduled for early April)  **Requirement/ IssueDiscussionPolicyAction 4. SCE HIGHIs it a best practice to send all text (Name, Address etc.) sent in upper case?Key Fields are all numeric. Additional elements are required on a per UDC basisIn the transmission, only Upper Case for text is used. (Agreement on 1/21/99) Agreed5. SCE HIGHHow is data changed in UDC or ESP customer data baseIf the UDC is not fixing data, is the maintenance transaction the exclusive means to change data. What fields to communicate as changed is based on Acct Maintenance document.See 3a When data changes (based on Acct Maintenance list of fields) Acct Maint transaction sent to other party (UDC/ESP). (Agreement on 1/21/99)Agreed Action Item: Review list of fields in Document6. SCE HIGHWhat are the acceptable choices for unbundled services; Are MSP and MDMA fields required for DASR acceptanceDA Rule or UDC tariff or both Optional fields on the 814 Implementation Guide. ESPs would like flexibility in not having to specify at time of DASR, but UDCs use this info in other operation proce off is issued and every time the turn off is rescheduled or is cancelledIs there a market requirement? Is Policy dependent on size of customer? Also, if UDC not the MDMA, is advanced notification needed? What other information needs to be included? Distinction between temporary shut-off and moving out turn-off. Notification (EDI) is the key issue. 48. ORA HIGHNeed to identify when kVAR metering required.Need to know if kVAR required for Billing. Also, how to handle multiple meters that include kWh & kVAR. On DASR Response, include ALL meters. How will ESPs know about totalizers and recorders? Are the Meter Specific Services forms (maybe EDI 650 in future) better suited for communicating detail meter data, instead of DASR Response? EDI 814 DASR Response will identify if account requires kVAR for Billing. DASR Response will include identification of all Meter ids on the Account. (Tentative pending UDC action item to determine feasibility on DASR Response)Action Item: UDCs to determine how they could deliver the kVAR identification. (2 weeks) Action Item: Need flag (code) in EDI 814 for identifying if kVAR needed for billing. 49. PGEES HIGHConsistency on combination of identifiers with DUNS numberCellnet: SDP should be the primary Key Field in all transactions once SDP is available. SCE: DUNS required for MDMA; conditional for MSP and meter owner.  **Requirement/ IssueDiscussionPolicyAction 50. SDGE HIGHTimeline for migrating to EDI 814; including which version (4010).Policy changes will take effect when EDI implementation takes place; a packaged deal. Will there be an Operational Manual that documents the new Procedures and Policies? The EDI 814 version 4010 will be the accepted version for All at time of Implementation; no interim changes to existing EDI 814 3070 version or CMEP would be made. (Agreement on 2/1/99)Accepted Action Item: Document Calif EDI 814 mapping guide for version 4010. Action Item: DASR Consistency subteam to provide new procedures & processes to Operational Manual subteam. UDCs initially posted EDI schedule to Rule 22 in Sept 1998 (spread throughout 1999). 51. SCE LOWHow to communicate Tax Exemption status?Issues on whether and what information should be communicated. Cellnet: This should be communicated in the DASR Response. SCE: Issue currently being addressed outside of DASR Working Group. Action Item: Resolve in separate forum. (In Conf Call on 2/8/99, if this status gets communicated, the DASR/Acct Maint will be used)  **Requirement/ IssueDiscussionPolicyAction 52. NWE NEW NWE: How to communicate Invoice Number / Billing Account Number?NWE: The invoice number will be provided to the ESP in the DASR Response. SDG&E: Recent meetings confirmed that the Billing Acct. No. will be an Acct. Maint. transaction, per 8/98 agreement. The invoice number (UDC billing account number) will be provided to the ESP in the DASR Response. Any changes to that number will be communicated via Account Maintenance transaction. (Agreement on 2/26/99) Agreed 53. NWE NEW NWE: How to communicate accounts, which are Load Research, that go DA?NWE: The DASR Response will indicate accounts that are Load Research. SDG&E: Support adding this field to the new std. format for DASR Status Notification Accept. Action Item: New West Energy will clarify the business needs for this information and specify what data. 54. SCE NEW SCE: Update Data DictionarySCE: Disconnect DASR is not used to switch a customer; the Connect DASR is sent by the ESP to the UDC to connect a customer per the Data Dictionary.  DASR / Account Maintenance - Business Policies/Issues ** - Prioritization: HIGH = Consistency Needed Across Market Page - page 4 DASR / Acct Maint Consistency Group MED = Agreement between Specific UDC & ESP may be sufficient As of: 3/31/99 LOW = Not Business Policy, more Technical Issue " =/88` (Decided to allow manual communication of Meter information. MSS will work on TTQURUUUUU%V&VVVWWWWWWWXY?[@[D[G[z[|[~[[[[[%\&\'\*\\\]]]]]] ^U_X_ `9`;`T`V`bcccaddd{dddfghžžŷŷۯ۩UbU^b]BEF2Vb BEF^2b BEF2b BEF2bBEF2^bUcUVbU^bbBEF T2fUb BEF2b BEF2bBEF2^b?hhhiiiiijjjjjjjjjjk k/klmmm m;mxmmmmmmmmmmnnn1n2n9no>oBowooooppp q9q:qAqÿÿöÒÿVb BEFZ2UVbBEF2UVbBEF2UVbBEF2UVbBEFՃ2FUVbUVbBEFZ2UVbUc BEF2b BEF2bBEF2^b^bb BEFZ2b BEF_2bBEF_2^b8Aqrrrrrr=s>s?ssPtRtUtltwttuuu vvvvvvvvvvvvvvw!w"w#w$w+wyxxxxxxxЫ┋ BEFy2&b^bVBEFփ2FUVbBEFZ2UVb BEF2b BEFa2bBEF2^b BEF2b BEFփ2FbBEFZ2bh BEFZ2b BEF`2bBEF`2^bUcUVbU BEF2b BEF2bBEF2^bb.xxxyyyyyyy*z+zzzz{{({?{J{Y{{{{||||!|$|'|(||r}}}|~EAE\gv/25[\036Շ BEFZ2b BEFZ2b BEFb2bBEFb2^b BEF2b BEFT2fbUcUVbUWbU^bUb BEF2b BEFZ2bb BEF׃2Fb BEFa2bBEFa2^b:Շه 23UlwDFILS_cr}=>$%]df'CPdefjm؎َێžžډ BEF2b BEF܃2Fb BEFك2Fb BEFy2&bUVb BEF؃2Fb BEFZ2b BEFZ2b BEFb2bBEFb2^b BEFy2&b^bUc BEF2bBEF2^b BEF2bb BEFZ2b BEFZ2b6ܓڔ1369uv|}-/25stv"1569:=?BEʚ˚͚ҚD!"%&󹰹UVbBEF܃2FUVbUVb BEF܃2FbBEFc2UbU^ BEFۃ2Fb BEFڃ2Fb BEFc2bBEFc2^b BEFy2&bb^bUcUUbD&)+.1svwxy/JOPQǞΞϞԞ՞֞מ؞z}~ $hjo)*7PQĹUUbuPauDBEF2fPPUc c BEFۃ2Fb BEFڃ2FbBEFc2^bUVb BEF܃2Fb BEFc2b^bbBEFc2UbD")1259>?nv#$L\o~" h3 48h() h3w33333l LH ,s5333ŏJefghiqvܓ78ڔ23vwxyz|l L*,s53333l L*l,o53"jst&'|}~./tuv")12  333l L*,o533%26:>?͚̚CD"&*+sKLMNOP             63l L*,o53&PJ{|}~QRQ6bb33 3!T p5 3 !p5K@Normal3a $@$ Heading 1Uc.@. Heading 2DUc*@* Heading 3 Uc"@" Heading 4U@ Heading 5U"A@"Default Paragraph Font @ Footer !)@ Page Numberc @ Header !B@" Body TextUfuture approach.)Scheduled for early April Will implement manual process with report on 4/30 of pending DASRs over 150 days. ESPs can indicate DASRs that need to remain pending. Otherwise, on 5/30 pending DASRs over 180 days will be cancelled. (Agreement at OCC Mtg on 3/30 and Rule 22 Mtg on 3/31)(Conf Call scheduled for early April to discuss use and purpose of SDP; or maybe its not needed)Scheduled for early April For now, information about need for kVAR meter for billing purposes will be communicated manually outside of DASR. (Agree on 3/2/99 at OCC meeting)MSS will look at including this data on meter forms (Load Research accounts are confidential info to UDCs) 1" =/88`dS$O,3J:v@G PV]`dkBqv^{FC>ŏ2P~_`abcdefghijklmnopqrstuvwxyz{Unknown Chris KingStandard ConfigurationA Valued Microsoft Customer8Standard ConfigurationA Valued Microsoft Customer2d8Standard ConfigurationA Valued Microsoft Customer28Standard ConfigurationA Valued QRPQRvuPaUbU@R!!!!!!!!! ! ! ! ! !!!!!!!!!!!!!e\]^0!!!'(N)O)-.C/D/B28= ELCNGOHOIOT5\b[iryN@Lj       $ ")259>?nv#$L\o~UVvwEFvwabijd_bvpKRSSTUMNO/0( ) g h o p N!O!!!!"""""" # #F#G#$$%%'(((M)O)S)W)\)<****++,,-r-s---...B/D/H/L/P/Q/////y0z0000o1q1u1y1z11192C2F2Z2e2l2u2y2}223I4J4v5w555667777778"868A8H8Q8U8Y8]8899>9b9c9999:F:J:N:S::::D;;;=========>>>>@@AAWBXBBBCCyDzDDD E E!E,E3EfCfGfLff8g9gfggghgjgngrgwggUhVhhhiiViWiXi\i_isi~iiiiii j%k&klllllllmcmmmmmmnnnnoooooop9q:qqq*r+r2r3rrrrrrrrrrrs%t&t)u*uJuKuuuuuuuuuvv w!w/x0xxx y y{y|yyyyyyyyyy/zNzOzzz{zzzzzzzz{9{{{{{{1|P|Q|S|W|[|`|||||,}3}4}}}}}}}$~%~'~+~/~3~~~~~~~~Mŀ̀Հـ݀lmƁˁ.ABncd  !#'+/ʇՇ܇JKuy}ËNjˋϋtu$%KORfqx./02:?m;“Ó%*e )09=BG8DE >}~*ϚH@