Rejection

Rejection reasons

The most common causes for rejected Transactions are:

• Invalid data fields in Change Requests.

• Change Requests are missing mandatory field data.

• The participant initiating a Change Request A transaction submitted by participants in MSATS whenever they want to create or update data held in MSATS. is not a valid initiator of the Transaction See Relevant Rules or Procedures.

• Attempting to create a NMI See Relevant Rules or Procedures already existing

• Change Requests are missing mandatory field data.

When you submit 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.:

1. It goes through several validations (like the MSATS Web Portal validations when you click Submit) to check if it is valid.

2. You receive an ACK file and a Change Request Response confirming the file passed validation.
   If MSATS rejects it, the reason for the rejection is communicated in the Change Request Response. For details, see page Page 1.

Rejection avoidance

How to avoid rejected Transactions:

• Ensure Change Request Field Validation Rules As described in the CATS Procedures, they specify, for each Change Reason Code, the fields in MSATS populated at the creation of a transaction or at other times in the life cycle of a transaction. are applied (seeChange request field validation rules).

• In a Change Request, only include fields having a Field Validation A process to test the veracity and integrity of metering data. Data Source Code of RI or OI Open Interest.

• Complete all mandatory fields (RI fields).

• Ensure you are a valid Initiator The participant initiating a B2B Interaction. of a Transaction from at least the Proposed Change Date The proposed date when a Role transfers from one participant to another. on the Change Request. Valid Initiators are:

- Current The participant can receive files compliant to the current aseXML version. 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.: If it is initiated by a participant in a Current Role, the participant must have been in that Role for the period covered by the Change Request (for example, from at least the proposed date on the Change Request).

- New Role: If it is initiated by a participant in a New Role, the participant must be in that Role at least from the proposed date on the Change Request.

• You can only use Codes to create NMIs (for example, CR Change Request 2001 or CR 2500) if the NMI is not already in 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..

• Do not attempt to update Meter records that are not registered in MSATS. For example, a CR 3051 for a new Meter is rejected if it has no Metering Installation Type Code The type of meter attached to a NMI as described in the CATS Procedures. and no Meter Register Status Code A code used in MSATS to delineate the status of a meter. For more detail, see the CATS Procedures..

• Ensure the Proposed Change Date for a Transaction is within the allowable number of days:

- For a Retrospective Change A change to a NMI record that becomes effective on or before the date the Change Request is submitted., it must be between today and no further into the past than the Retrospective Period The maximum period where a Retrospective Change can be made. for the relevant Change Request.

- For a Prospective Change A change to a NMI record that takes effect on a date after the date the Change Request is submitted., it must be between tomorrow and no further into the future than the Prospective Period The maximum period when a Prospective Change can be made. for the Change Request.

• If you are updating a Meter record, ensure it is registered in MSATS.

• For a new Meter record (CR 3051), ensure the Metering Installation Type Code and the Meter Register The meter register data stored in MSATS, which includes both the metering register and other data. Status Code are included.

• Ensure the Proposed Change Date for a Transaction is within the allowable number of days:

- For a Retrospective Change Request: between today and the Retrospective Period The 288 periods from 4:30 am to 4:00 am..

- For a Prospective Change Request: between tomorrow and the Prospective Period.

Finding why MSATS rejected your transaction

To find why MSATS rejected your Transaction, you run a Data Replication (C1) Report A data report that loads into a data model table. Identified by its type, subtype, and version. For example: BILLING,BILLINGASPAYMENTS,2 to obtain:

1. The Request and Transaction ID from the CATS_OUTBOUND_CHANGE_REQUESTS Table.

2. The rejection reason from the CATS_OUTBOUND_ERRORS table.

Obtain the request and Transaction ID

1. Run a Data Replication (C1) report for CATS_OUTBOUND_CHANGE_ REQUESTS.

There is a limit to how many Transactions can return so it is important not to make the range too broad. To limit the number of search results:

1. If you know the rejection date, enter it as the Start and End Date.

2. Enter a Time From and To range.

2. When you receive the report, open it, and look for the Request ID.

For easy searching, extract the content from the zip file and copy it to a text editor such as Microsoft Word or NotePad++.

The content looks like the example below, where the Request ID is 4.

3. To find the rejection reason you need the Transaction ID which is under the Request ID. In the example below it is 29.

Obtain the rejection reason

1. Run a Data Replication (C1) report for CATS_OUTBOUND_ERRORS. Your request should look like this:

2. When you receive the report, open it, and look for the TransactionID you obtained above.

The rejection reason is under the TransactionID in the Code and Explanation tags (see Find TransactionIDRejection). For other common errors, see Rejection reasons .

Figure 102 Find TransactionID

Editing a rejected change request

Occasionally, when you enter a Change Request in the MSATS web portal, it is rejected because, either:

1. The Proposed Change Date is not within the Prospective or Retrospective Period (see Web browser exception).

2. The data in the Change Request is incorrect or missing.

To fix the error without having to re-enter the data:

1. In your browser interface, once only, click the Back arrow.

Figure 103 Web browser exception

2. The Change Request – Main interface displays.
   Do not click the Back arrow in the web browser or you lose your data. Click Edit.

3. The Change Request – Edit interface displays. If required, edit the Proposed Start Date and click Next.

4. The Change Request information displays, where you can edit any other required fields and click Submit.

5. If the Change Request passes validation, MSATS accepts the Transaction. Otherwise follow these steps again to fix the error.