B2B Procedures Version 2.0
Initial Consultation Participant Response Pack
Participant:
Completion Date:
B2B Procedures v2.0 - Initial Consultation - Change Pack - v0.03.doc 1 of 40
Table of Contents
9. Proposed Changes 3
9.1 Proposed changes to the B2B Procedure Customer and Site Details Notification Process 4
9.2 Proposed changes to the B2B Procedure Service Order Process 23
9.3 Proposed changes to the B2B Procedure Meter Data Process 28
9.4 Proposed changes to the B2B Procedure One Way Notification Process 29
9.5 Proposed changes to the B2B Procedure Technical Guidelines for B2B Procedures 30
9.6 Proposed changes to the B2B Procedure Technical Delivery Specification 32
Initial Consultation V2.0- Response Pack 2 of 32
Proposal for B2B Procedures V2.0
9. Proposed Changes
This section lists the changes proposed to the B2B Procedures: Version 2.0.
Proposed changes have been categorised as Procedure changes as follows;
· Table 9.1 covers the proposed changes to the B2B Procedure Customer and Site Details Notification Process.
· Table 9.2 covers the proposed changes to the B2B Procedure Service Order Process.
· Table 9.3 covers the proposed changes to the B2B Meter Data Process.
· Table 9.4 covers the proposed changes to the B2B Procedure One Way Notification Process.
· Table 9.5 covers the proposed changes to the B2B Procedure Technical Guideline for B2B Procedures.
· Table 9.6 covers the proposed changes to the B2B Procedure Technical Delivery Specification.
NOTE: All proposed additions to the B2B Procedures are highlighted in red colour text and are underlined. All proposed deletions from the B2B Procedures are highlighted in red strike through text. Example: Reference.
9.1 Proposed changes to the B2B Procedure Customer and Site Details Notification Process
Item / Solution ID / Description /9.1.1 / 2-N1 /
Section 1.7 - Application of this Procedure
Changes to Clause1.7 c:c. This Procedure applies to Customer and Site Details in respect of the NMIs in the following Participating Jurisdictions:
Transaction
/ ACT
/ NSW
/ QLD
/ SA
/ VIC
/ TAS
/
Customer Details Request / Yes / Yes / Yes / Yes / Yes / Yes
Customer Details Notification / Yes / Yes / Yes / Yes / Yes / Yes
Customer Details Reconciliation / Yes / Yes / Yes / Yes / Yes / Yes
Site Access Notification / Yes / Yes / Yes / Yes / Yes / Yes
Site Address Notification / Yes / Yes / Yes / Yes / Yes / Yes
/
9.1.2 / 2-N1 /
Section 1.9.1 - Business Documents
Changes to Clause 1.9.1 a:a. Throughout this Procedure, the term "Business Document" is used to refer to the key Transactions sent between the Retailer and DNSP. In this Procedure, the relevant Business Documents are:
1. CustomerDetailsRequest
2. CustomerDetailsNotification
3. CustomerDetailsReconciliation
4. SiteAccessNotification
5. SiteAddressNotification /
9.1.3 / 2-N1 /
Section 2.1 - Process Diagrams
Changes to Clause 2.1 b:b. The Timing Requirements for the BusinessReceipt and the BusinessAcceptance/Rejection for the SiteAccessNotification and SiteAddressNotification are is identical to those for the CustomerDetailsNotification.
/
9.1.4 / 1-N2 /
Section 2.2.2 - Common business rules for Notifications
Changes to Clause 2.2.2:h. The details provided in a CustomerDetailsNotification, and SiteAccessNotification and SiteAddressNotification must be the current details at the date and time that the Notification, was generated. This date may be historical in certain situations. The recipient should use the date the transaction was generated as the effective date for the change of details and not the last modified date and time. For Life Support Changes refer to 2.2.4 a., b and cb).
i. A Retailer must investigate and take corrective action where necessary upon receiving a rejection of a notification transaction. /
9.1.5 / 2-N1
5-N2 /
Section 2.2.3 - Customer Details Request
Changes to Clause 2.2.3c. The Retailer must provide a CustomerDetailsNotification in response to a valid CustomerDetailsRequest. The Retailer must not provide a SiteAccessNotification or SiteAddressNotification in response to a valid CustomerDetailsRequest.
d. The DNSP must not use this transaction to obtain mass updates of information. If a mass update of information is required, the Reconciliation Process must be used. /
9.1.6 / 1-N5,
5-G1 /
Section 2.2.4 - Customer Details Notification
Changes to Clause 2.2.4:a. Life support applies to a customer at a connection point, and sensitive load applies to a connection point to indicate that the Retailer reasonably believes there are economic, health or safety issues associated with loss of supply to the connection point.
b. The Retailer must immediately advise the DNSP by telephone when they become aware of a Life Support situation (refer SensitiveLoad field, Section 4.2). The Retailer must subsequently send a CustomerDetailsNotification in accordance with the normal Timing Requirements set out in Section 3.2.3). In this case, the Changes are effective from the time of the telephone call from the Retailer to the DNSP.
c. For sites in South Australia with Life Support requirements, the Retailer must fax a copy of the documentation verifying the Life Support requirements for the Site to the DNSP. The BusinessAcceptance/Rejection transaction does not indicate formal acceptance of the Life Support information. Formal acceptance occurs once verification of the Life Support information is received as per regulatory requirements. In this case, the Changes are effective from the time the DNSP verifies the documentation provided by the Retailer.
d. Where the requirements for Life Support are no longer appropriate (for example an occupier no longer meets the jurisdictional requirements to be classified as a Life Support customer) a Retailer must send a CustomerDetailsNotification containing NMI, LastModifiedDateTime, a MovementType value of “Update” and SensitiveLoad value of “None” to the relevant DNSP and the DNSP must update their records accordingly.
e. The SensitiveLoad code “Sensitive Load” will not be used by the DNSP for the purpose of de-energisation. The DNSP may use this information for load or outage management purposes.
f. Where a Site is vacant (for example, if a customer moves out), a Retailer must send a CustomerDetailsNotification containing NMI, LastModifiedDateTime, a MovementType value of “Site Vacant” and SensitiveLoad value of “None” to the relevant DNSP.
g. If a Customer changes Retailer, the Old Retailer must not send a CustomerDetailsNotification. The New Retailer must send a CustomerDetailsNotification in accordance with 2.2.2 b above.
h. The Retailer must confirm who the specific contact for the management of outages and supply issues is for each connection point. The Retailer must provide these details via the CustomerDetailsNotification for each connection point. /
9.1.7 / 5-N2,
MM /
Section 2.2.5 - Customer Details Reconciliation
Changes to Clause 2.2.4:a. Participants must conduct a reconciliation of Customer Details on a regular or as required basis. For timing requirements see Clause 2.2.5 f.
b. The Reconciliation Process provides the DNSP with a complete snapshot of all NMI’s with SensitiveLoad value other than ‘None’, for which the Retailer is financially responsible, as at the time of the Reconciliation (as required by the CustomerDetailsNotification).
c. The Reconciliation Process must use the CustomerDetailsNotification transaction with MovementType equal to ”Reconciliation”. This form of the CustomerDetailsNotification transaction is called the CustomerDetailsReconciliation transaction.
d. The use of BusinessAcceptance/Rejections for the CustomerDetailsReconciliation will be identical to that used for the CustomerDetailsNotification, with the addition for the use of CustomerDetailsReconciliation-specific EventCodes.
e. The following apply to the delivery of CustomerDetailsReconciliation transactions:
1. The required delivery method for the CustomerDetailsReconciliation transaction and its Business Signals is the B2B e-Hub, and if the B2B e-Hub cannot be used the backup delivery method must be a DVD (any DVD Type).
2. The Retailer and DNSP must agree the timing of the Reconcilliation. This agreement shall consider at least the following criteria:
i. File limits;
ii. Conflicting scheduled reconciliations with other participants;
iii. IT Support availability; and
iv. Other impacting activities.
3. If the delivery method is via the B2B e-Hub and the number of files exceeds 100, the Retailer must agree the timing of the Reconciliation with AEMO before commencing the Reconciliation
3. Where AEMO advises the Retailer that the CustomerDetailsReconciliation can not be undertaken as agreed in clause 2.2.5 e 2 the Retailer must contact the DNSP and agree a new date.
4. If tThe CustomerDetailsReconciliation transaction is sent via the B2B e-Hub, the transaction must be sent as a Low Priority aseXML document.
f. The Timing Requirements for the use of the CustomerDetailsReconciliation transaction and its Business Signals will be initiated and processed during the months of May and November of each year or as agreed between the Participants using the Transaction should further CustomerDetailsReconciliation be required.
g. A Reconciliation transaction does not replace the requirement for the Notification of Customer Details Changes as described in sections 2.2.2 and 2.2.4.
h. Where a DNSP reasonably believes the data they have received in a CustomerDetailsReconciliation transaction is incorrect, the DNSP may reject the data and query the Retailer for a given NMI by using the appropriate EventCode in the corresponding BusinessAcceptance/Rejection.
i. Where a DNSP reasonably believes a NMI not sent in the CustomerDetailsReconciliation transaction has SensitiveLoad, the DNSP must raise the appropriate CustomerDetailsRequest transaction to request the Retailer confirm SensitiveLoad.
j. Where a DNSP has rejected the information provided in a CustomerDetailsReconciliation transaction, the Retailer must use reasonable endeavours to confirm that the information is correct. A Retailer must send a subsequent CustomerDetailsReconciliation with an appropriate MovementType code, for the NMI in question to the DNSP. For timing requirements see clause 3.2.7 a.
k. A DNSP must not reject two consecutive CustomerDetailsReconciliation transactions for the same NMI. If the DNSP still believes the SenstitiveLoad value is incorrect, the DNSP should contact the Retailer to resolve the issue. /
9.1.8 / 2-N1 /
Section 2.2.6 – Site Address Notification
Deletion of Clause 2.2.6:2.2.6 Site Address Notification
a. The DNSP must comply with the following usage rules for the Business Events listed in the table below when sending BusinessAcceptance/Rejections for SiteAddressNotifications.Business Event
/ Usage
/
Accept / The DNSP fully accepts the information provided by the Retailer and will update MSATS accordingly.
Address identical to address held by DNSP / The information provided by the Retailer matches the DNSP’s records. The DNSP will not be updating its records based on the information provided by the Retailer.
Address not accepted. MSATS correct / The DNSP reasonably believes the Site address recorded by the DNSP and MSATS is correct. The DNSP will not be updating its records or MSATS based on the information provided by the Retailer.
Address not accepted. MSATS to be updated / The DNSP does not accept the Site address provided by the Retailer. The DNSP investigation of the site address has resulted in changes to its records and will result in a corresponding change to MSATS.
/
9.1.9 / 2-N1 /
Section 3.2.3 – Timing Requirement for Providing Notifications
Changes to Clause 3.2.3 b:b. In all other situations, the Notification transaction (Customer, Address or Access details) must be provided within one business day of the relevant data being updated/changed (and the completion of the related customer transfer, if applicable). Refer 2.2.2. a and 2.2.4.e f. /
9.1.10 / 1-N7 /
Section 3.2.4 Timing Requirement for Sending CustomerDetailsRequests
Changes to Clause 3.2.4:a. The DNSP must not send a CustomerDetailsRequest for a NMI before the Close of Business of the fifth business day following the completion of the Transfer of the Connection Point.
b. The DNSP must not send a CustomerDetailsRequest for a NMI before the Close of Business of the fifth business day following the completion of the New Connection of the Connection Point. /
9.1.11 / 2-N1 /
Section 3.2.6 - Timing Requirement for BusinessAcceptance/Rejection for Notifications
Changes to Clause 3.2.6:a. With the exception of SiteAddressNotification, tThe timing requirement for BusinessAcceptance/Rejections is set out in section 4.10 of the B2B Procedure Technical Delivery Specification.
b. The DNSP must provide a BusinessAcceptance/Rejection to the Retailer within 15 Business Days of receiving a SiteAddressNotification. /
9.1.12 / 5-N2 /
Section 3.2.7 - Timing Requirement for Sending CustomerDetailsReconciliation
Addition of Clause 3.2.7:3.2.7 Timing Requirement for Sending CustomerDetailsReconciliation
a. A Retailer must send a new CustomerDetailsReconciliation for the NMI in question within five business days of receiving confirmation of sensitive load or life support in relation to a CustomerDetailsReconciliation transaction with MovementType equal to “Reconciliation”. /9.1.13 / 5-N2,
5-G1,
1-N7,
MM /
Section 4.1- CustomerDetailsRequest Transaction Data
Changes to Clause 4.1:Field
/ Format
/ Usage: Customer Details Request
/ Definition/Comments
/
NMI / CHAR(10) / M / NMI (as used by MSATS).
NMI Checksum / CHAR(1) / O / NMI Checksum (as used by MSATS).
Reason / VARCHAR(40) / M / Allowed values
Returned Mail
Missing Customer Details
Confirm Life Support
No response to rejected CDN
Transfer complete, no CDN received
New Connection, no CDN received
Data Quality Issue (explanation in SpecialNotes)
Rec - confirm no SensitiveLoad
Other (explanation in SpecialNotes)
Notes regarding the allowed values
“Returned Mail” means the DNSP has received returned mail with the current PostalAddress held by the DNSP.
“Missing Customer Details” means the DNSP reasonably believes the customer details have changed and the Retailer has not provided a Notification of the Changes (e.g. move-in or transfer has occurred).
“Confirm Life Support” means the DNSP requires confirmation of whether the Connection Point has a Life Support requirement or not.
“No response to rejected CDN” means that a DNSP has rejected a previous CDN where it was reasonably expected the Retailer would send through a new CDN with updated/corrected information, which has not yet been received by the DNSP after two business days of sending the rejection.
“Transfer complete, no CDN received” means a transfer has completed for the NMI and the DNSP believes a CDN has not yet been received within the allowed timeframe.
“New Connection, no CDN Received” means a new connection has completed for the NMI and the DNSP believes a CDN has not yet been received within the allowed timeframe.
“Data Quality Issue” means that although the data may be technically correct, it may not be fit for purpose (e.g. phone number is 9999999). The DNSP must provide which specific data they are querying in the SpecialNotes field.
“Rec - confirm no SensitiveLoad” means the DNSP believes a NMI has a SensitiveLoad value other than ‘None’ and was not included in the Reconciliation Process.
“Other” means other reasons to the specified ones. If this Code is used, the DNSP must provide the details of the reason in the in SpecialNotes field.
SpecialNotes / VARCHAR(240) / O/M / Any additional information the DNSP wishes to convey to the Retailer.
Mandatory if Reason is “Other”. or “Data Quality Issue”.
/
9.1.13 / 1-N7,
5-N2,
1-N5,
3-N1,
5-G1
1-N6 /
Section 4.2 - CustomerDetailsNotification Transaction Data