Participant outbox

Participant outbox overview

The participant outbox is used by 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. to place files for transfer to participant systems.

The files stored in the participant outbox must be acknowledged as soon as possible to ensure they are moved from the participant outbox by MSATS.

Participant outbox user rights access

Participant Administrators control access to Participant Outbox using the Data Load Import (Participant Inbox & Participant Outbox) entity in the Administration menu in the MSATS Web Portal.

Clear your participant outbox

1. On the main menu, click Data Load Import and then click Participant Outbox.

 

2. The Participant Outbox - List displays with the files waiting to be transferred from the MSATS system to a participant system. To acknowledge files, do one of the following:

• Click Select All to place a tick next to all File Names and then click Acknowledge Selected.

• Click De-select All to unselect any File Names with a tick.

• Select individual File Names and then click Acknowledge Selected.

3. Files are deleted once they are acknowledged; click OK to confirm the deletion. See Important Note below.

4. A confirmation message displays confirming the Acknowledgement.

When the number of unacknowledged outbound files in the participants outbox (that is, change request responses and notifications from MSATS) reaches a system limit, the batch handler stops generating outbound files. No outbound batch transactions are produced until the files in the participant outbox have been reduced to within the limit.

On occasions when MSATS cannot archive an acknowledged .ZIP file immediately, the following error message displays and the .ZIP file is deleted later.

However, the .ACK An acknowledgement file from AEMO with a filename extension of .ACK. The file contains messages to acknowledge the success of another file. file that is created at the same time as the .ZIP file may not be automatically deleted; therefore, it must be done manually. The contents of the .ZIP file must be read and saved prior to acknowledging it.

To do this, confirm the related .ZIP file has been moved by MSATS from the participant inbox, then select the relevant checkbox in the participant inbox for the .ACK file and click Delete Selected.

Viewing a change request response

For each accepted transaction in the .XML eXtensible Mark-up Language. file, a change request response (CRR) transaction is generated. By default, each response transaction is in a separate .XML file in a separate .ZIP file. Therefore, if there are multiple transactions in the one batch file, multiple .ZIP files are placed into the participant outbox.

Because the response is sent to the <PARTICIPANTID>batch user ID, only someone logged on to the MSATS web portal with that user ID (or with a right that provides access to all items in the participant’s outbox) can see the response message. That is, the originator of the change request may not necessarily see it.

Depending on the notification rules, the <PARTICIPANTID>BATCH user ID and other parties’ equivalent user IDs may also receive notifications to indicate the status of the change request (Administration).

Participants can request AEMO Australian Energy Market Operator to ‘bundle’ some types of outbound transactions (contact the AEMO's support hub). ‘Bundling A function in MSATS where AEMO bundles MSATS Change Request Notifications. This means that instead of sending Change Request notifications as individual XML messages containing a single transaction, many can be bundled into a single XML message (one message, with multiple transactions, in a single file).’ is the term used when there are many transactions in a single .XML file. When notifications are bundled, there is no longer a one-to-one relationship between an outbound transaction, message and .ZIP file.

To view a change request response:

1. On the main menu, click Data Load Import and then click Participant Outbox submenu.

Note: this is the same as clicking the message link on the main menu.

2. The Participant Outbox - List displays, click the File Name.

3. Click Open to open the file or Save to save it to a location on your PC.

Alternatively, click Cancel to return to your Participant Outbox - List.

4. Open the .ZIP file and select the .XML file.

5. The file contents display. Read the message to determine whether the change request is accepted.

• Accepted change request - the change request response transaction has Information written in the <Event severity> element and 0 (zero) in the <Code> element. Therefore, the status is requested (REQ), see Accepted change request example..

• Rejected Change Request - the change request response transaction has an error code in the <Code> element (1199 in the example below) and an <Explanation> element, which is a general error message with, if applicable, specific additional information. In the example, the general part of the error message says the register status does not have a valid value. Therefore, the status is rejected (REJ), see Rejected change request example..

If the change request status is REJ, no more processing takes place.

• Notifications - having updated the status of the change request to REQ or REJ, notification messages are sent to the appropriate participants (in the form of .XML files stored within .ZIP files) as per the Notification Rules for the change reason code. The participant notified may be the initiator of the change request or other parties for example, parties with a right to object. In some special cases (for example, with streamlined change reason codes), there may be no notifications at all.

The request ID you use to search for a change request is held in the RequestID field.

This is an example of a change request response transaction for an accepted change request (such as, one that passed the second level validation).

Figure 113 Accepted change request example.

This is an example of a change request response transaction for a rejected change request (such as, one that failed the second level validation).

Figure 114 Rejected change request example.