Insert Company LOGO HERE
:

Proposal for B2B Procedures V1.8
7. Proposed Changes
This section lists the changes proposed to the B2B Procedures for Version 1.8.
Proposed changes have been categorised as Procedure changes as follows;
Table 7.1 covers the proposed changes to the B2B Procedure Customer and Site Details Notification Process.
Table 7.2 covers the proposed changes to the B2B Procedure Service Order Process.
Table 7.3 covers the proposed changes to the B2B Procedure Meter Data Process.
Table 7.4 covers the proposed inclusion of the B2B Procedure One Way Notification Process
Table 7.5 covers the proposed changes to the B2B Procedure Technical Guidelines for B2B Procedures.
Table 7.6 covers the proposed changes to the B2B Procedure Technical Delivery Specification.
The BPRG and IEC are requesting Participants to carefully review and provide specific comments and views for items QC
744, QC 755, QC 759, QC 766, QC 779 and QC767 documented in the Change Pack and this Participant Response document.
NOTE: All proposed updates are highlighted in red, with the deleted items highlighted as red Strike though.
726898904 1 of 27

Proposal for B2B Procedures V1.8
Item
QC ID Description Participant Responses to Draft
Determination
7.1.1 QC 766
726898904
Customer Details Reconciliation requires a clear uniform process for participants to agree the timing of the customer detail reconciliation timing, taking into account the varying external influencing factor.
Clause 2.2.5 Customer Details Reconciliation 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, 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 s 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. 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;
2 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
7.1.2 N/A
7.1.3 N/A iii. IT Support availability; or 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.
Where AEMO advises the Retailer that the
CustomerDetailsReconciliation cannot be undertaken as agreed in clause 2.2.5 e 2, the Retailer must contact the DNSP and agree a new date.
4. If the 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.
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.
Update the version number from 1.7 to 1.8
in the document history.
The proposed effective date is 16 November 2011
Participant Responses to Draft
Determination
726898904 3 of 27

Proposal for B2B Procedures V1.8
Item QC ID 1 Description
7.2.1 QC 744 Changes documented to clearly explain of the use of the ServiceOrderSubType codes.
Clause 2.12.3
Participant Responses to Draft
Determination
1 Quality Centre identification number
726898904 4 of 27

Proposal for B2B Procedures V1.8
Item QC ID 1
7.2.2 QC 755
7.2.3 QC 779
726898904
Description
The Timing Requirement for Completion of the Requested Work for the Service
Order SubType of ‘Adds and Alts’ has been amended to provide clarity for all jurisdictions.
Clause 3.3.5
Figure 18: Timing Period for completion of work






2.6.2 Scheduled Date and Customer Preferred Date and Time a. The following apply to the ScheduledDate and
CustomerPreferredDateAndTime fields on a ServiceOrderRequest:
Participant Responses to Draft
Determination
5 of 27

Item QC ID 1
726898904
Description
1. Where only the ScheduledDate field is completed: i. The Retailer must not put a retrospective date in the ScheduledDate field.
Where a CustomerPreferredDateAndTime is provided it must also be prospective except as detailed in 2.6.2 c.1.ii. and 2.6.2 c.1.iii. Where the delivery of the ServiceOrderRequest to the Service Provider is delayed resulting in the ScheduledDate being retrospective, the ScheduledDate will be deemed to be the date the ServiceOrderRequest is received by the
Service Provider. If a CustomerPreferredDateAndTime is provided this will also be retrospective and in this circumstance the Service Provider must reject the ServiceOrderRequest except as detailed in 2.6.2 c.1.ii and 2.6.2 c.1.iii. ii. If a retrospective date is received in the ScheduledDate field, the Service
Provider must provide the Retailer with a BusinessAcceptance/Rejection with a rejecti on message of ‘Invalid data. Details provided in the
Explanation.’
2. Where both the ScheduledDate and CustomerPreferredDateAndTime fields are completed: i. The Retailer must not put a retrospective date in the ScheduledDate field. ii. If a retrospective date is received in the ScheduledDate field the Service
Provider must provide the Retailer with a BusinessAcceptance/Rejection with a rejection message of ‘Invalid data. Details provided in the
Explanation.’ iii. The date specified by the Retailer in the ScheduledDate and
CustomerPreferredDateAndTime fields must be the same except as allowed in 2.6.2 c.1.ii. and 2.6.2 c.1.iii in which case only the
CustomerPreferredDateAndTime can be retrospective. iv. If a retrospective CustomerPreferredDateAndTime is provided otherwise than in accordance with 2.6.2 c.1.ii or 2.6.2 c.1.iii, the Service Provider must reject the ServiceOrderRequest with a rejection message of ‘Invalid data. Details provided in the Explanation.’
Proposal for B2B Procedures V1.8
Participant Responses to Draft
Determination
6 of 27

Item QC ID 1
726898904
Description b. The Service Provider must use reasonable endeavours to complete the work requested and accepted on or after the ScheduledDate included in the
ServiceOrderRequest, and within the Required Timeframe from this
ScheduledDate or in the case of an appointment, agreed by the Retailer and
Service Provider, on the ScheduledDate.
c. Where a the CustomerPreferredDateAndTime is provided included in accordance with 2.6.2 a.2, the CustomerPreferredDateAndTime should represent: in the ServiceOrderRequest the ScheduledDate must be the same date as the
CustomerPreferredDateAndTime, except as detailed in 2.6.2 c.1.ii and 2.6.2 c.1.iii.
1. The CustomerPreferredDateAndTime should represent: i. The Customer's preference, as agreed with the Retailer, which becomes the ScheduledDate for the Service Order, or ii. A date and time, agreed between the Retailer and Service Provider to support exceptional Service Order requests (e.g. Re-energisation on a weekend with the ServiceOrderRequest sent the following Monday). Such requests must include details of the agreement in the SpecialInstructions field and have the same RetServiceOrder quoted by the Retailer to the
Service Provider by phone. In this instance, the
CustomerPreferredDateAndTime is the date agreed by both parties for the work to be completed; or iii. ii.
Where a Customer advises the Retailer they have already moved into the Site and the Site is energised (left energised or energised by the
Customer), if the Retailer requires a move-in reading the Retailer may raise a Re-energisation ServiceOrderRequest with a
ServiceOrderSubType of “Retrospective Move-in”, a
CustomerPreferredDateAndTime that matches the move-in date, and a prospective ScheduledDate . The Service Provider will provide a meter reading in accordance with the Metrology Procedure, undertaking field work if necessary.
Proposal for B2B Procedures V1.8
Participant Responses to Draft
Determination
7 of 27

Proposal for B2B Procedures V1.8
Item QC ID 1
7.2.4 N/A
7.2.5 N/A
Description
2. If the CustomerPreferredDateAndTime and ScheduledDate are not the same date, except as permitted in 2.6.2 c 1.ii and 2.6.2c.1.iii, of these
Procedures , the Service Provider must provide the Retailer with a
BusinessAcceptance/Rejection with a rejection message of ‘Invalid data.
Details provided in the Explanation’.
3. If the CustomerPreferredDateAndTime is not reflected by the ServiceTime , the Service Provider must provide the Retailer with a
BusinessAcceptance/Rejection with a rejection message of ‘Invalid data.
Details provided in the Explanation’. d. The ScheduledDate must not be more than 100 calendar days in the future. e. The Retailer must not put a retrospective date in the
CustomerPreferredDateAndTime field other than as specified in for a Service
Order Sub Type of ‘Retrospective Move-in’ (See 2.6.2c.1.ii and iii).
Update the version number from 1.7 to 1.8
in the document history.
The proposed effective date is 16 November 2011
Participant Responses to Draft
Determination
726898904 8 of 27

Proposal for B2B Procedures V1.8
Item
7.3.1
QC ID Description
QC 767
Insertion of new section 3.2 Network Tariff Notification Process to be introduced.
3.2 Network Tariff Notification (NTN) Process
Figure 4: Overview of the Network Tariff Notification (NTN) Process
Network Tariff Notification Process
Participant Responses to Draft
Determination
Send
OneWayNotification
NTN Transaction
BusinessReceipt received
BusinessAccept/ reject received
Network Tariff
Change
7.3.2
Receives
OneWayNotification
NTN Transaction
BusinessReceipt raised
BusinessAccept/
Reject raised
Note
The “Network Tariff Change” step is shown for completeness and this process does not obligate the
DNSP to perform this step.
It is expected that the Network Tariff in the NTN transaction will match the MSATS Change Request notification for Network Tariff change.
QC 767 a. This transaction is forms the communication method for DNSPs to notify Retailers of planned network tariff changes in advance of the network tariff change being taking effected. b. Upon receipt of a OneWayNotification transaction from a DNSP, the Retailer must return a BusinessReceipt and BusinessAcceptance/Rejection .
Insertion of new clause 3.2.1 Network Tariff Notification Business Rules to be introduced.
726898904 9 of 27

Proposal for B2B Procedures V1.8
Item
726898904
QC ID Description
3.2.1 Network Tariff Notification (NTN) Business Rules a. For this process the “Network Tariff Notification” shall mean the notification of a
DNSP initiated Network Tariff change for a customer or groups of customers from a
DNSP to the Current Retailer in advance of when the DNSP intends to change the
Network Tariff, for a customer or groups of customers. that is not initiated by the current Retailer. b. For DNSP initiated Network Tariff changes, where advanced notification to the current Retailer is required by jurisdictional instruments, the DNSP must raise a
OneWayNotification (NTN) for each impacted current Retailer in its Network. c. The Network Tariff Notification is to be originated by DNSPs with the current Retailer being the receiving party. c. The DNSP must provide all network tariffs applicable for the NMI as at the proposed change date in the OneWayNotification (NTN) transaction. d. When initiating advanced notification of network tariff changes, the DNSP must take reasonable endeavours to include multiple NTN records in OneWayNotification transactions. e. Taking into account clause 3.2.1.a, b and f, the DSNP may initiate the NTN based on in advance of any Network Tariff change being effected: i. DNSP Review ii. Change of NMI Classification iii. Regulator Review iv. Customer Request to DNSP; v. Any other reason. f. Where a DNSP intends to begin initiateing Network Tariff Notification in 3.2.1.f where a jurisdictional obligation does not exist, the DNSP must engage and establish an agreement with impacted market participants to determine impacts before any
OneWayNotification transaction s (NTN) are are raised.
g. The DNSP is not required to notify the Retailer if a planned Network Tariff change did not occur.
Participant Responses to Draft
Determination
10 of 27

Item QC ID Description h. The DNSP is not obliged to complete the Network Tariff change on the proposed dates provided to the Retailer. i. If the DNSP fails to complete the Network Tariff change on the NOTICEENDDATE and consequently re-plans re-schedules the Network Tariff change, a new
OneWayNotification (NTN) transaction shall be sent to the Retailer.
j. The DNSP must produce the OneWayNotification (NTN) transaction a minimum of thirty business days before the Network Tariff change becomes effective. k. The Network Tariff Notification will be sent to each affected Retailer, with an OWNP transaction type of NTN (NetworkTariffNotification) with data, in CSV format. k. The DNSP is only required to notify the current Retailer as defined by MSATS at the time the Network Tariff Notification (NTN) is created. l. If a prospective Retailer exists either at the time of creating or post the creation of the OneWayNotification (NTN) transaction, there is no requirement for the DNSP to also notify the prospective Retailer. m. Notifications of successful Network Tariff changes are communicated via the existing
MSATS Change Request process. n. Retailers may receive more than one OneWayNotification (NTN) per day from the same DNSP, for reasons outlined in 2.4.d. o. Any Network Tariff Change is effective from the MSATS CATS change request CR effective date. p. The network tariff must be an approved and published Network Tariff before it can be used in the Network Tariff Notification
Proposal for B2B Procedures V1.8
Participant Responses to Draft
Determination
726898904 11 of 27

Proposal for B2B Procedures V1.8
Item
7.3.3
QC ID Description
QC 767
Insertion of new clause 3.2.2 Delivery Priorities (Network Tariff Notification) to be introduced.
Participant Responses to Draft
Determination
7.3.4
3.2.2 Delivery Priorities a. The B2B Procedure B2B Technical Delivery Specification, section 4 documents the delivery priorities.
QC 767
1. Participants must ensure all OneWayNotification transactions are delivered as a Low Priority.
A new section 4.2 Network Tariff Notification (NTN) Timing needs to be introduced.
4.2 Network Tariff Notification (NTN) Timing
Figure 84.2.a: - Represents the timing points for Network Tariff Notification (NTN).
Network Tariff Notification Process
Send
OneWayNotification
NTN Transaction
BusinessReceipt received
BusinessAccept/ reject received
Network Tariff
Change
726898904
Timing Requirements
A
Receives
OneWayNotification
NTN Transaction
BusinessReceipt raised
BusinessAccept/
Reject raised
B C D
E
F
12 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
Note:
The ”Network Tariff Change” step is shown for completeness.
Where the Network Tariff changes are not affected by the NOTICEENDDATE, a new NTN will be required from the DNSP.
Figure 94.2.b: - Timing points A to D described and used below are shown in the diagram above.
Timing Point Definition
A
B
This is the point when the DNSP sends the
OneWayNotification Network Tariff Notification (NTN) transaction for a NMI or a set of NMIs to the Retailer.
This is the point when the Retailer sends the
BusinessReceipt to the DNSP.
7.3.5
C This is the point when the Retailer sends the
BusinessAcceptance/Rejection to the DNSP.
D The date the Network Tariff change is effective in
MSATS and is shown for completeness only.
QC 767
E
This is the latest date the DNSP can effect a Network
Tariff Change without initiating a new NTN.
Insertion of new clause 4.2.1 Timing Variation (Network Tariff Notification) to be introduced.
Participant Responses to Draft
Determination
4.2.1 Timing Variations
726898904 13 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
7.3.6
The following timing intervals apply to the Network Tariff Notification (NTN) process
Figure 104.2.c: - Timing Point Definitions
Timing Period Definition
A to B
B to C
Retailers must comply with Section 4 of the B2B
Procedure B2B Technical Delivery Specification for
BusinessReceipt Messages.
Retailers must comply with Section 4 of the B2B
Procedure B2B Technical Delivery Specification for
BusinessAcceptance/Rejection Messages.
QC 767
A to D
A to E
This is the notice period between when the DNSP provides the notification of a proposed Network Tariff
Change to Retailers and the new Network Tariff effective date.
Where application of this procedure is mandatory, the minimum days for this timing period must meet jurisdictional obligations.
This is the period between when the DNSP provides the notification of a proposed Network Tariff Change to
Retailer and the expiry of the advanced notification of network tariff change.
Where application of this procedure is mandatory, the minimum days for this timing period must meet jurisdictional obligations.
A new section 5.1.2 Network Tariff Notification (NTN) CSV Data Timing to be introduced.
Participant Responses to Draft
Determination
726898904
5.1.2 Network Tariff Notification CSV Data
14 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
726898904 a. The Network Tariff Notification message is defined as;
1. Message Type – Network_Tariff_Notification
2. Message Name – NTN b. The DNSP should use the examples provided where these are applicable to the
REASONFORCHANGE and only use free text where none of these standards texts are applicable. The DNSP must use the text “No change” when under clause 5.1.2(c) a data record is included in the transaction but the existing tariff is to remain. c. Participants must ensure the Network Tariff Notification message
CSVNotificationDetail conforms to the usage, format and definitional rules for the information (I) and data (D) records detailed in the following table. The header and footer (C) record details are contained in the B2B Procedure Technical Guidelines for
B2B Procedures.
Figure 135.1.2.a: - Network Tariff Notification CSV field values
Column Field
Column1 RECORDINDICATOR
Format
Char(1)
Column2
Column3
Column4
Column5
Column6
Column7
Column8
MESSAGENAME
VERSION
NMI
NMICHECKSUM
NTPROPOSEDDATE
NOTICEENDDATE
PROPOSEDNTC
VarChar(3)
Char(1)
Char(10)
Char(1)
DATE(8)
DATE(8)
VarChar2(10)
Use Definition
M
M
M
M
M
M
R
M
Indicates the type of record, “I” for information which is the column headings for the CSV data, and “D” which is the data for the matching heading.
The Message Name for
Network_Tariff_Change, it is always
“NTN”. See section 5.1.1.a.2 above.
Identifies the version of the CSV content. For NTN this is “1”.
NMI where the Network Tariff Change is proposed to occur.
NMI Checksum for the NMI.
This is the proposed date of the
Network tariff Change by the DNSP.
Format CCYYMMDD
This is the latest date the DNSP can effect a Network Tariff Change without initiating a new NTN.
Where application of this procedure is mandatory this date must be provided
This is the new network tariff code being proposed for that NMI .
Participant Responses to Draft
Determination
15 of 27

Proposal for B2B Procedures V1.8
Item
726898904
QC ID Description
Column 9 REASONFORCHANG
E
VarChar2(20) M This is the reason for Network Tariff change. A few examples are provided below:
- No Change**
- DNSP Review**
- Change of NMI Classification**
- Smart Meter Roll Out
- Regulator Review**
- Customer Request to DNSP**
- ‘Free Text’**
**These ‘
Reasons for Change’ could be used where participants agree the use of this transaction outside the jurisdictional obligations.
Example of I & D indicator records for Network Tariff Change
I,MESSAGENAME,VERSION,NMI,NMICHECKSUM,NTPROPOSEDDATE,NOTICEENDDATE,PROP
OSEDNTC,REASONFORCHANGE
D,NTN,1,1234567890,1,20111101, 20111121,B101,Change to TOU tariff d. For each NMI included in a NTN and taking into account clause 3.2.1.d, the DNSP must create individual indicator data(D) records for all Network Tariffs that will be applicable to the NMI post the Network Tariff Change in the CSV payload, whether the
Network Tariff is changing or not.
An example of the CSV Data has been provided below:
D,NTN,1,1234567890,1,20111101, 20111121,B101,Smart Meter Roll Out
D,NTN,1,1234567890,1,20111101, 20111121,B102, Smart Meter Roll Out
D,NTN,1,1234567890,1,20111101, 20111121,NE113,No Change e. The receiving Participant is required to send a BusinessReceipt and
BusinessAcceptance/Rejection for each transaction in accordance with the B2B
Procedure Technical Delivery Specification.
Participant Responses to Draft
Determination
16 of 27

Proposal for B2B Procedures V1.8
Item
7.3.7
QC ID Description
QC 767
Updates to existing text in section 2.1 Process Overview.
a. The One Way Notification process enables Participants to send information or messages to other Participants in a single transaction for multiple NMIs. b. The process is designed to allow flexibility to add additional new Message Types within the Business Document without an aseXML schema change, by incorporating the data in CSV format within the transaction. c. There is one Business Document associated with this overall Procedure:
1. OneWayNotification - The provision of selected information between
Participants. d. There is one are two Message Types CSVNotificationDetail associated with this overall Procedure:
1. Meter Exchange Notification (MXN) - The provision of selected information to Retailers for planned mass meter replacements initiated by
DNSPs.
2. Network Tariff Notification (NTN) - The provision of selected information to
Retailers for proposed Network Tariff changes initiated by DNSPs.
Participant Responses to Draft
Determination
726898904 17 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
7.3.8 QC 767
Updates to existing text section 5.1 CSV Notification Details.
a. Participants must ensure the CSVNotificationDetail payload conforms with the
B2B Procedure Technical Guidelines for B2B Procedures, section 4, by including:
 Header records “C” – For the header and footer
 Information records “I” – Column headings for each data item
 Data records “D” – data for each column heading above. b. There is currently one There is a different CSVNotificationDetail for each of the following Message Type s associated with the One Way Notification process.
1. Meter Exchange Notification (MXN)
2. Network Tariff Notification (NTN) c. Payload content of the CSVNotificationDetail is located in clause 5.1.1 for MXN and clause 5.1.2 for NTN
7.3.9 QC 767
7.3.10 N/A
7.3.11 N/A
7.3.12 N/A
The existing text in clause 3.1.1.b page 8 is incomplete and requires amendment. b. During a Mass Meter Exchange Program the DNSP must raise a
OneWayNotification (MXN), for each impacted current Retailer in its Network, each time a new customer notification is sent.
The figure numbers throughout the process for One Way Notification have been updated.
Update the version number from 1.7 to 1.8
in the document history.
The proposed effective date is 16 November 2011
726898904
Participant Responses to Draft
Determination
18 of 27

Item
7.4.1
QC ID Description
N/A
7.4.2
N/A
Update the version number from 1.7 to 1.8 in the document history.
The proposed effective date is 16 November 2011
Proposal for B2B Procedures V1.8
Participant Responses to Draft
Determination
726898904 19 of 27

Proposal for B2B Procedures V1.8
Item
QC ID Description Participant Responses to Draft
Determination
7.5.1 QC 767
6. GLOSSARY, Page 33 – The following definition needs to be added between glossary terms ‘NEMMCO’ and ‘New FRMP’
Note: with this insertion, all subsequent glossary terms will be progressed to next page.
NEMMCO National Electricity Market Management
Company Limited as defined in the National
Electricity Rules. NEMMCO was renamed
AEMO on 1 July 2009.
Network Tariff
Notification
A Message Type within the B2B Procedure One
Way Notification Process. It is defined as a notification for DNSP initiated network tariff changes for a customer or groups of customers from a DNSP to the Current Retailer in advance of when the DNSP intends to change the
Network Tariff., for a customer or groups of customers that is not initiated by the current
Retailer.
New FRMP The FRMP that is identified on a change request prior to the change request being completed.
726898904 20 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
7.5.2 QC 759
6. 6. GLOSSARY, Page 33 – The following definition needs to be added between glossary terms ‘NEMMCO’ and ‘New FRMP’ (above the Network
Tariff Notification once inserted)
Note: with this insertion, all subsequent glossary terms will be progressed to next page.
Term
B2BNEM Retail Operations
Contacts List
Definition
A list of contact details published populated by Participants , administered by AEMO and to be used for the purpose of contact communication between Participants to support B2B
Communications pursuant to the B2B
Procedures retail operation processes .
Participant Responses to Draft
Determination
7.5.3 N/A
7.5.4 N/A
Update the version number from 1.7 to 1.8
in the document history.
The proposed effective date is 16 November 2011
726898904 21 of 27

Proposal for B2B Procedures V1.8
Item
QC ID Description
7.6.1 2
726898904
Reference to the B2B Contacts List in Section 3.5 - A Summary of Transaction
Model Exception Points is required to be updated to NEM Retail Operations
Contacts List.
Exception
Who needs to take action
Initiator
Action to be taken
1. Initiator determines that intended Recipient of a
B2B Message has reached flow control limit.
Once relevant Timing
Requirements are exceeded, raise issue with appropriate technical contact for
Recipient, as indicated by B2BNEM Retail
Operations Contacts List.
Address the indicated reason for failure and resend.
2. B2B Message sent by
Initiator fails MSATS B2B
Handler validation.
Initiator
3. An MSATS B2B Handler
“.ac1” Acknowledgement not received in response to a B2B Message sent by
Initiator. See Section 4.10 for Timing Requirements.
Initiator
Initiator
4. B2B Message sent by
Initiator fails Business
Receipt validation by the
Recipient, ie Initiator receives a negative ase:
MessageAcknowledgemen t
Contact AEMO to raise issue of potential performance issue.
Address the indicated reason for failure and resend.
Participant Responses to Draft
Determination
22 of 27

Item QC ID Description
5. Ase:MessageAcknowle dgement not received in response to a B2B
Transaction.
Participants should refer to the Section 4.10 for Timing
Requirements
Initiator
6. Ase:TransactionAckno wledgement not received within appropriate timeframe from posting a B2B
Message to the MSATS
B2B Handler (and all intermediary events have occurred successfully).
(Participants should refer to the B2B
Procedures for specific
Timing Requirements; however the Business
Acceptance/Rejection is typically required within one business day.)
Initiator
726898904
Proposal for B2B Procedures V1.8
Participant Responses to Draft
Determination
Raise potential performance issue with appropriate technical contact for
Recipient, as indicated by
B2BNEM Retail
Operations
Contacts List.
Raise nondelivery issue with appropriate technical contact for
Recipient, as indicated by
B2BNEM Retail
Operations
Contacts List.
23 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
7.6.2 QC 759 Reference to the B2B Contacts List in Clause 5.8 d is required to be updated to
NEM Retail Operations Contacts List and acronym (ROCL) to be inserted.
Participants must ensure that any email Message sent pursuant to and in accordance with clause 5.8 is sent to the appropriate email address specified in the B2BNEM Retail Operations Contacts List (ROCL).
Participant Responses to Draft
Determination
726898904 24 of 27

Proposal for B2B Procedures V1.8
Item QC ID Description
7.6.3 QC 759
7.6.4 N/A
726898904
Reference to the B2B Contacts List in Section 6 is required to be updated to NEM
Retail Operations Contacts List and acronym (ROCL) to be inserted.
6.1 B2B Contact List NEM Retail Operations Contacts List (ROCL)
Industry requires a central reference point of contacts within each participant organisation for various B2B functions.
The B2B Contact List ROCL holds escalation contacts in each participant organisation for B2B related retail operational processes for the NEM.
Currently the list is administered by AEMO on a secure web based application, which is used by all Participants.
The contact list has a template that is managed by the Industry reference group on behalf of the Industry and it may be amended periodically based on
Industry’s requirements.
6.2 Creating a new B2B Contact List NEM Retail Operations Contacts List
(ROCL)
When participants register in the NEM they must add their details to the template provided by AEMO and submit the completed template as per the instructions in the B2B Contact List ROCL template.
6.3 Updating an Existing B2B Contact List NEM Retail Operations Contacts
List (ROCL)
Participants must update their contact details as and when their details change and provide these to AEMO.
6.4 Publishing of B2B Contact List NEM Retail Operations Contacts List
(ROCL)
AEMO shall publish new and updated Contact List within five business days of receiving the new or changed B2B Contact List ROCL .
Draft Determination:
The following clause is inserted to Clause 6.5 of the B2B Procedure – Technical Delivery
Specification
Note: The Service Order Paperwork Reference Table is published in
NEMConnect under National B2B – B2B Documentation.
Participant Responses to Draft
Determination
25 of 27

Item QC ID Description
7.6.5 N/A
7.6.6 N/A
Update the version number from 1.7 to 1.8
in the document history.
The proposed effective date is 16 November 2011
Proposal for B2B Procedures V1.8
Participant Responses to Draft
Determination
726898904 26 of 27