Objections

What are objections?

Participants can log objections against change request transactions using 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. web portal or the batch handlers. The right to object to a transaction is determined by the objection and jurisdictional rules. The objection rules define, for each type of change request, which participant Roles can object using which objection codes. The jurisdictional rules determine the length of the objection logging and clearing periods.

Objections can be logged for both Prospective and retrospective change reason codes. When a participant has the right to object in a current 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., any participant acting in that Role for the period covered by the change request (such as, the Proposed Date or Actual Change Date The effective date of changes specified in a Change Request. The same date as the FromDate in a C4 Report and the Start Date in MSATS interfaces displaying NMI master data.) may be able to object. If the change request has a proposed date and end date, both of which are in the past (such as, it is updating active historic data only), the participant that is now the current Role for that period may be a different participant.

This means that more than one participant may be acting in the current Role for any change request. In this case, MSATS allows multiple participants to have a Role status of current against a NMI See Relevant Rules or Procedures. The following table provides an example of a current Role relationship for NMI 6001000100.

Participant ID	NMI	Role	Start date	End date	Active flag
FRMP1	6001000100	FRMP	1/7/2000	19/10/2008	A
FRMP2	6001000100	FRMP	20/10/2008	31/12/9999	A
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

The NMI 6001000100 currently has two active FRMPs assigned to it, FRMP1 and FRMP2.

Only FRMP1 has the ability to object to any retrospective change requests that have a Proposed Date or Actual Change Date of 1st July 2000 and End Date of 19th October 2008.

Only FRMP2 has the ability to object to any Retrospective change requests that have an Actual Change Date of 20th October 2008 and an End Date up to and including the present day or no End Date, in which case the change is assumed to apply into the future (the high date, which is 31/12/9999).

Only FRMP2 has the ability to object to any Prospective change requests.

Both FRMP1 and FRMP2 can object if the Proposed Date or Actual Change Date is before 20th October 2008 and the End Date is after 19th October 2008 or there was no End Date because both are current FRMPs for the period covered by the proposed change.

Objections can only be logged within the valid objection-logging period for each change request.

Prerequisites

The participant must know, or be able to locate the request ID for the relevant change request.
The objection must be in a status of requested or objected.
The objection period for the change request must still be open and current (such as, not closed).
The participant must be acting in a Role that allows for this type of objection for this change reason code.

For a NOACC objection, the change request may have moved to PEND status. This is the only objection code with this functionality. In addition, the objection-logging period may have passed but the NOACC code does not recognise this period. A NOACC code can only be submitted by an MDP Meter Data Provider. An organisation which installs, commissions, gathers, and verifies data remotely from meters in the National Electricity Market (NEM)..

Each objection submitted against a change request must meet certain criteria:

Identify the request ID to which it relates.
Identify the participant making the objection.
Identify the Role in which the participant is acting for the objection.
Provide an objection code.

Once the objection is logged, it passes through validation to ensure that it complies with all rules. The objection is not fully processed until all validations are passed. For each objection logged, MSATS validates:

The objection is not a duplicate.
The change request to which it relates is identified.
The change request has a status of requested or objected.
The Role in which this participant is acting is identified.
The participant is an active 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. participant.
An active objection code is supplied.

The objection code is valid for the Role in which the participant is acting according to the objection rules—see MSATS Procedures : CATS Procedure Principles and Obligations.

The objection is received within the cut-off time allowed for this jurisdiction and change reason code type according to the jurisdictional rules—see MSATS Procedures : CATS Procedure Principles and Obligations.

The participant objecting is acting in a new or current Role that is entitled to object for the Jurisdiction participating jurisdiction (defined in the NER), change reason code and NMI classification of the change request.
Once the objection has been received, the system notifies the initiator of the objection acceptance or rejection. This notification (objection response file) is sent to the participant’s outbox in the form of a .ZIP file.
A party can lodge an objection, even if there is already a valid objection logged against this change request from another party.
If a change request has been in a status of Objected for the objection-cleaning period, the status of the request changes to Cancelled.
If a change request has its status changed to Cancelled, its history is retained.
If a change request has its status changed to Cancelled, all parties that received the original notification (including the initiator) are notified of the change of status.

Searching and viewing objections

To search and view objections:

On the main menu, click Transactions and then click Objections.

The Objections - Search interface displays. From this interface you can search, view, edited or create objections. To search for an objection, do one of the following:

Enter the Change Request ID in the Search By section and click Search.

Enter the change request details in the fields in the Or section and click Search. The Date From and To fields are required.

Creating a new objection

The Objections - Search interface provides access to the Change Request interface showing details of a change request related to a particular objection. Participants can also view error messages related to objections that were loaded into the system using the batch process and for failed validations.

To create a new objection:

On the main menu, click Transactions and then click Objections.

The Objections - Search interface displays, click New.

The Objections - New interface displays, for help understanding the fields, see Objection fields. Type the Participant Transaction ID and Change Request ID.

Click the Objection Code drop-down arrow and select the objection type from the list.

Click the Role ID drop-down arrow and select from the list. The Role ID selected must be equal to a Role currently held by the participant, and it must be a valid Role for the objection type.

Click Save. If the objection passes validation, the change request is updated to include the:

Objection code.

Role ID of the participant making the objection.

Date and time the objection was logged.

Objected status.

If the objection fails validation, an error message explaining the reason for the failure displays. Edit the objection to change the incorrect details.

The objection is confirmed and a notification is sent to each participant associated with the NMI who are authorised to receive notification of objections.

This can be viewed using the participants outbox and is an XML eXtensible Mark-up Language. format in a .ZIP file.

Objection fields

Field	Description
Participant Transaction ID	Participant transaction identifier provided by the participant for each transaction they submit
Change Request ID	The unique identifier of the change request to which this objection relates
Objection Code	The objection code that identifies the reason for the objection. To learn more about objection codes, Administration.
Role ID	Role permitted to object with the given objection code. MSATS checks whether your Role status is current or new. (If it is new, then you must be nominated in this Role on the change request you are objecting to.)

Withdrawing an objection

Participants can withdraw objections they have logged against change requests. An objection cannot be withdrawn if the:

Objection A type of transaction raised in relation to a Change Request. ID provided is not valid.
Participant requesting the objection withdrawal is not the initiator of the objection.
Related change request is cancelled.

If the objection withdrawal is valid, the objection is cancelled. The change request the objection is raised against has its status updated to Requested A status point of a Change Request. or remains at Objected A status point of a Change Request. if other participants have raised objections they have not withdrawn. In the overnight processing, any change requests that have their status updated to Requested have the status updated to Pending A status point of a Change Request., if the objection period has passed.

Depending on the notification rules, participants are informed of the withdrawal of the objection and of the status of the change request for which the objection has been withdrawn. All participants that receive a notification of Objected status can expect to receive a notification when an objection is withdrawn.

When a change request’s status is changed from OBJ (Objected) to REQ (Requested) after the withdrawal of an objection (which is what happens if there are no other outstanding objections), then two notifications are sent. One is triggered by the withdrawal of the objection and includes the objection details. Another is triggered by the standard action of a change request changing status to REQ; it does not have the objection details.

If the objection withdrawal is successful, the participant withdrawing the objection is notified of the success of their request. A web portal withdrawal receives immediate notification; while a batch handler withdrawal is acknowledged by an objection withdrawal transaction in the participant outbox.

Depending on the notification rules, the relevant parties are notified whenever an objection is withdrawn. The notification has a status of OBJ if there are still other active objections or REQ if all objections are cleared. In either case, the notification includes details in the objections section.

The following example displays the objectionAction as Withdrawn:

If an objection being withdrawn is not valid (such as, the objection record does not exist, the withdrawing participant was not the initiating party or the change request to which it relates has an invalid status), an error is recorded and the objection withdrawal transaction indicates that the withdrawal was rejected. A rejected web portal withdrawal receives immediate notification; while a batch withdrawal is acknowledged with an objection transaction in the participant outbox.

Information captured against an objection withdrawal request

Field	Field code	Description
Change Request ID	REQUESTID	The unique identifier of the change request to which this objection relates.
Participant Transaction ID	PARTTRANSACTIONID	A participant transaction identifier provided by the participant for each transaction they submit.
Participant ID	PARTICIPANTID	The participant ID of the participant initiating the withdrawal.
Objection Code	OBJECTIONCODE	The objection code that identifies the previously entered objection that the participant now wants to withdraw.
Role ID	ROLEID	Role permitted to object with the given objection code

To withdraw an objection:

On the main menu, click Transactions and then click Objections.

The Objections - Search interface displays. To find the objection, follow the steps to view the Objections - List interface (Searching and viewing objections).

The Objections - List interface displays the list of objections and objection withdrawals. Click Withdraw in the Action column next to the objection ID.

A confirmation message displays, click OK.
The objection withdrawal is confirmed.