Response

Zip A compressed file, with the zip extension. A zip file usually contains one file with a filename extension of XML or csv. files generated due to a Change Request A transaction submitted by participants in MSATS whenever they want to create or update data held in MSATS., Notification A transaction that does not have a corresponding reply transaction, see Notification Business Transaction Pattern., Objection A type of transaction raised in relation to a Change Request. and so on are always sent to the <ParticipantID> Batch A right type assigned to a participant user by their participant administrator to access a Batch (file) application. To see these messages login with the Batch Participant ID Registered participant identifier; A company can have more than one Participant ID..

To see the responses to requests for information you initiated, such as NMI See Relevant Rules or Procedures Discovery and report requests, login with your individual Participant User ID The user ID you used to login to the system..


If your Participant User A Participant ID's users created and maintained by the Markets Portal PA in the URM. ID access right includes the Participant Mailbox - All entity, you may also see messages sent to the Batch Participant ID and messages sent to other Participant User IDs.

The 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. generated aseXML A standard for energy transactions in XML. A set of schemas and usage guidelines that define how data should be exchanged under FRC in the gas and electricity industries in Australia. response file has (see figure below):

  • The <Event> code

A successful response is 0. An error is any other number (for error help, see Page 1).

  • The rejection <Explanation>

Figure 113 Change request response with an error

 

Change request response

MSATS responds to a 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. with an approval or rejection as it reaches the Pending Validation A status point of a Change Request. status.

For each approved Change Request, a change request response (CRR) transaction is generated. By default, each response transaction is in a separate .XML eXtensible Mark-up Language. 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 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). from AEMO Australian Energy Market Operator for some types of outbound Transactions (contact the AEMO's Support Hub). ‘Bundling’ 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.

Change request response example

Objection response

MSATS responds to an Objection with an approval or rejection. MSATS informs other participants according to the applicable Change Request Status Notification Rules Rules that specify which roles are advised when a Change Request undergoes a change in status, as described in the CATS Procedures for each Change Reason Code..

Objection Response example

NMI discovery response

MSATS sends information to the Initiating party in response to a NMI Discovery Search, containing the following information:

  • The code within the <Event> element provides useful information. For a NMI Discovery a code of 0 (zero) means the result was successful but is not necessarily an exact match.

  • A four-digit code indicates an error. For example, 1404 indicates that no data was found matching the search criteria.

  • Assuming the response indicates success, the information returned depends on the jurisdictional rules. The same data is returned if the search is done in the web portal.

  • All NMIs matching the search criteria are returned up to the jurisdictional limit.

NMI discovery response example

NMI discovery type 2 response example

NMI master report response

A report response Transaction See Relevant Rules or Procedures returns the results from the report parameters you selected. All report output is delivered via Batch file even if you submit the report request from the web portal.

Report data response

The data generated for a participant report request. For more details, see C4 – NMI Master Report.