Notifications

Notifications occur when there is a change to the status of a Change Request A transaction submitted by participants in MSATS whenever they want to create or update data held in MSATS. or when an Objection A type of transaction raised in relation to a Change Request. is lodged or withdrawn. A Notification A transaction that does not have a corresponding reply transaction, see Notification Business Transaction Pattern. includes information about what is proposed to change or what has changed, in the case of a COM (complete) Notification.

Notifications are sent to relevant parties throughout the different stages of the Transaction See Relevant Rules or Procedures process as determined by the notification rules. Current The participant can receive files compliant to the current aseXML version. and new Roles are notified of a change in Change Request The way information is returned from an API. In a request, the client provides a resource URL with the proper authorization to an API server. The API returns a response with the information requested. status according to the Notification Rules The National Gas or Electricity rules. (see NMI discovery search key rules).

Notifications are placed in your Participant Outbox regardless of how you created them (web portal or Batch A right type assigned to a participant user by their participant administrator to access a Batch (file) application). MSATS Market Settlement and Transfer Solutions. The procedures published by AEMO under clause 7.2.8 of the National Electricity Rules, which include those governing the recording of financial responsibility for energy flows at a connection point, the transfer of that responsibility between market participants, and the recording of energy flows at a connection point. puts each Notification in a separate XML eXtensible Mark-up Language. message in a separate .ZIP file. Participants can request outbound messages bundled by calling the Support Hub.

You can view Notifications in the web portal or download the .XML message from your Participant Outbox.

The process involves:

  1. Determining who is notified.

  2. Determining what is in the Notification.

  3. Creating the Notification ready for distribution.

  4. Keeping an audit trail of Notifications.

New parties

Notifications serve an important purpose for nominated new parties for an existing NMI who do not currently act in the Role The role a company has with a connection point in CATS. A single company can have more than one role associated with a NMI.. When the Notification for a status COM is sent to new parties, it includes the NMI master data required by the new party.

It includes all active records, (active historic and/or current), depending on the period covered by the Change Request. The reason for supplying this information is to make it easy for parties acquiring a new relationship to update their own systems with the NMI information.

New parties on a Change Request in certain roles (FRMP Financially Responsible Market Participant, usually a retailer, Generator, Market Customer or a Market Small Generator Aggregator, identified in respect of a connection point. Responsible for dealings with AEMO in relation to a specific load., LNSP, LR Local Retailer. A business unit or related body corporate of the relevant local network service provider, or responsible under the laws of the relevant participating jurisdiction for the supply of electricity to franchise customers in that local area., MDP Meter Data Provider. An organisation which installs, commissions, gathers, and verifies data remotely from meters in the National Electricity Market (NEM)., MBP, and RP Responsible Person. The participant with formal responsibility for the provision, installation and maintenance of a metering installation.) receive these special notifications for the COM status. If the old and new parties are the same for a Role, the special Notification for the COM status is not sent.

Some Change Requests require the specification of the Role party, even the Role is not changing.

NMI master data in notifications

Generally, a Notification only includes information about:

  • The Proposed change.

  • For a COM Notification, what has changed.

For new parties nominated on a Change Request, Batch Notifications serve an additional purpose for an existing NMI. When the Notification for status COM (such as, Completed One of the status points of a Change Request.) is sent to the new parties, it includes all NMI master data for the NMI the new participant is entitled to. It can also include active Current and active Historical Data Metering data provided for a previous reading period., depending on the period covered by the Change Request.

Supplying this information make it easy for new parties to update their own systems with all current NMI information they acquired a relationship with.

The NMI master data applies to Notifications for Roles: FRMP, LNSP Local Network Service Provider. The organisation that owns the poles and wires used to distribute electricity to premises within a geographical area and in the relevant participating jurisdiction.(including ENSP), LR, MDP, MBP and RP. All Roles other than MPC Market Price Cap. The National Electricity Rules’ maximum price at which gas can be bid, offered, or scheduled in the market. The AEMC’s Reliability Panel reviews the MFP every four years. or RoLR receive these special Notifications for the COM status when there is a change of Role.

If a participant is nominated in a new role on the Change Request but the same participant also occupies the existing role, the master data is not included. This is the case for Change Requests where a new MDP is specified but there is no change because it is the same party.

Batch notifications

A Batch Notification contains the same information as the MSATS Web Portal, except:

The COM Notification sent to participants nominated as new parties and who are new participants in that Role includes a complete set of the active NMI Master Records the participant requires for each of the master tables.

Batch submitted next scheduled read date

Updates to the Next Scheduled Read Date The date of the next scheduled meter read to be undertaken by the current MDP or MPC, see MSATS Procedures: CATS Procedures. (NSRD Next Scheduled Read Date. The day in which the data from a meter will next be taken.) submitted by File Interface (Batch) (such as CRs 5070 or 5071) do not obey the CATS History Model See Technical Guide to MSATS (see page Page 1).

If a Meter’s NSRD is updated by Batch, the current active record on the CATS Customer Administration and Transfer Solution. A set of procedures, principles and obligations made under the National Electricity Rules as part of Market Settlement and Transfer Solutions (MSATS), and applicable to NMI (National Metering Identifier) small and large classifications._METER_REGISTER Table for the supplied Meter Serial on the Change Request is updated.

This is the existing Meter Serial record, where the:

  • MaintActFlg = A and the EndDate = 31-Dec-9999.

  • MaintUpdtDt is 31-Dec-9999.

This record is updated with the new NSRD but the MaintUpdtDt is not changed from the high date.

Batch next scheduled read date updates

Notifications to FRMPs and Change Request responses to MDPs for updates to Next scheduled read dates (NSRDs) submitted by Batch are sent out in batches of up to 500 at a time. If MSATS has more than 500 other Transactions in outbound tables awaiting sending to you, no NSRD Notifications or Change Request responses are sent.

You cannot identify how many Transactions MSATS has waiting to send you, but if your Participant Outbox remains full (for example, soon after you acknowledge a file, MSATS sends you another one), you can assume MSATS still has files to send you.

If your Participant Outbox is empty or has less than 30 catsm files, you can assume MSATS has no Transactions waiting to send you.

The processing to send these files is run every five minutes in three time blocks each Day (AEST Australian Eastern Standard Time (market time)):

Block

Time

1

4 am – 7 am

2

12 noon – 1 pm

3

9 pm – 11 pm

 

For example, if you submit NSRD updates at 08:00 Market time, the earliest you can expect to see the Change Request responses is midday.

Retrospective notifications

MSATS can also send Notifications to participants Retrospectively. If a participant selects a Retrospective Change A change to a NMI record that becomes effective on or before the date the Change Request is submitted. Reason Code, the participants associated with the Change Request (such as, they held a current Role against the NMI during the Retrospective period) receive notifications.

In the example in Table 9 Retrospective notification example Page 1, assuming:

Figure 143 Table 9 Retrospective notification example

Active participants

NMI

Role

Start date

End date

Flag

Explanation

FRMP1

6001000100

FRMP

1/7/2000

19/10/2008

A

FRMP1 receives the notification since it is the active FRMP at the time of the proposed change

FRMP2

6001000100

FRMP

20/10/2008

31/12/9999

A

If the Proposed Date changes to 5-Nov-2008, FRMP2 receives the FRMP notification for the current FRMP

 

LNSPLNSP

6001000100

LNSP

1/7/2000

31/12/9999

A

 

LRLRLR

6001000100

LR

1/7/2000

31/12/9999

A

 

MDPMDP

6001000100

MDP

1/7/2000

31/12/9999

A

 

 

Notification role status

MSATS allows multiple participants to have a role status of Current against a NMI.

When a Notification or Objection rule is defined for Current on a Retrospective Change Reason Code, it means any current participants during the Change Request period. Allowing participants having no Current relationship with a NMI, but who did at the time of the change, to be notified and have the right to object.

It excludes participants having a Current relationship with the NMI but had none at the time of the Retrospective change.

An active history record is maintained since the NMI began its existence because many MSATS Settlement operations, for example Revisions, occur a long time after the Settlement period.

The notification rule only applies if the Retrospective participant is still an Active participant in MSATS. If the Retrospective participant becomes Inactive, they do not receive the notification.

Web portal notifications search

The web portal Notifications interface allows participants to search for Notifications and view their details. There is also a link to the related Change Request and Objections.