Objections

A participant can raise an Objection A type of transaction raised in relation to a Change Request. to a Change Request A transaction submitted by participants in MSATS whenever they want to create or update data held in MSATS. according to:

Other participants are informed according to the applicable Notification A transaction that does not have a corresponding reply transaction, see Notification Business Transaction Pattern. Rules The National Gas or Electricity rules. (see NMI discovery search key rules). The ability to object to a Transaction See Relevant Rules or Procedures is determined by the Objection Rules The rules applicable in MSATS that determine how Objections are used for each Change Reason Code. For more details, see the CATS Procedures. and Jurisdictional Parameters Parameters are options you pass with the endpoint (such as specifying the response format or the amount returned). There are four types of parameters: header parameters, path parameters, query string parameters, and request body parameters. The different types of parameters are often documented in separate groups on the same page. Not all endpoints contain each type of parameter. See Parameters for more details..

You can log Objections with Prospective and Retrospective Change A change to a NMI record that becomes effective on or before the date the Change Request is submitted. Reason Codes. When a participant has the right to object in a 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., any participant acting in that Role for the period covered by the Change Request (such as, at 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 object.

If the change request has a proposed and end date, where both are in the past (updating active historic data only), it is possible the participant in the Current Role for that period may be a different participant.

The MSATS Web Portal > Administration > Rules Maintenance has a list of Objection Rules and Jurisdictional Parameters for each Change Request type.

More than one participant may be acting in the Current Role for any Change Request so 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. allows multiple participants to have a role status of Current against a NMI.

For Current role relationships for NMI 6001000100 the NMI 6001000100 has two Active FRMPs assigned to it; PART1 and PART2:

  • Only PART1 can object to any Retrospective Change Requests having a Proposed Date or “Actual Change Date of 1st July 2000 and End Date of 19th October 2001.

  • Only PART2 can object to any Retrospective Change Requests having an Actual Change Date of 20th October 2001 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: 31/12/9999).

  • Only PART2 can object to any Prospective change requests.

  • Both PART2 and PART1 can object if the Proposed Date or Actual Change Date was before 20th October 2001 and the End Date was after 19th October 2001 or there was no end date because both are current FRMPs for the period covered by the proposed change.

The Objection Rules define, for each type of Change Request (Change Reason Code A code that identifies a type of Change Request. It defines rules such as what NMI information can be updated and which roles will receive a Change Request Notification each time the Change Request Status is updated.), which Participant Roles can object using the Objection codes, this includes the Role and the Role Status (a current or proposed role).

Each Objection submitted against a Change Request must meet certain criteria:

The Jurisdictional rules determine the length of the Objection period. You can only log an Objection within the Objection Logging Period The number of business days available to a participant for entering an Objection in MSATS. for the Change Request.

Table 103 Current role relationships for NMI 6001000100

Participant ID

NMI

Role

Start date

End date

Active flag

PART1

6001000100

FRMP

1/7/2000

19/10/2001

A

PART2

6001000100

FRMP

20/10/2001

31/12/9999

A

PART3

6001000100

LNSP

1/7/2000

31/12/9999

A

PART4

6001000100

LR

1/7/2000

31/12/9999

A

PART5

6001000100

MDP

1/7/2000

31/12/9999

A

 

Objection summary

NOACC objection

NOACC Objection rules:

Objection logging prerequisites

Before logging an Objection, you require the following information:

  • The Change Request ID you are objecting to.

  • The Objection status either: Requested A status point of a Change Request. or Objected.

  • The Objection Logging Period must be open and current (not closed).

  • You are acting in a Role allowing this type of Objection for the Change Reason Code.

For a new Objection, MSATS captures the information in Objections Page 1. For more details, see 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. Procedure Principles and Obligations.

Table 104 Initial objection information

Field

Field code

Description

Participant Transaction ID

PARTTRANSACTIONID

Participant provided Transaction ID for each submitted transaction

Change Request ID

REQUESTID

The unique ID of the Change Request you are objecting to.

Objection Code

OBJECTIONCODE

The Objection code identifying the Objection reason

Role ID

ROLEID

The permitted Objection Role to object for the Objection Code.

Objection logging period

If there are no outstanding Objections to a Current Change of Retailer See Relevant Rules or Procedures Transaction after the Objection Logging Period expires, the Change Request proceeds to Completed One of the status points of a Change Request. and the information in the Transaction becomes the NMI Master Record The NMI master record with an end date set to the year 9999..

Objection validation

To ensure Objections comply with the MSATS rules, once it is logged it passes through validation. The Objection is not fully processed until it passes all validations.

For each Objection logged, MSATS validates:

  • The Objection is linked to an active Change Request ID.

  • The Change Request is within its Objection Logging Period.

  • For Objections not subject to the Objection Logging Period, the Change Request is in a valid status: PEND, REQ, OBJ.

  • The Role the participant is acting in.

  • The participant is Active in MSATS.

  • The Objection is not a duplicate of an existing Objection by the participant.

  • An active Objection Code is supplied.

  • The Objection Code is valid for the Role the participant is acting in.

According to the Objection rules in the CATS Procedure Principles and Obligations.

  • The objection was received within the cut-off time allowed for Objections for this Jurisdiction and Change Reason Code.

According to the Jurisdictional Rules in the CATS Procedure Principles and Obligations.

Accepted objection

For an accepted Objection:

  • MSATS updates the status of the Change Request to OBJ.

  • MSATS sends XML eXtensible Mark-up Language. notifications to participants in line with the Notification Rules. Usually the Initiator of the Objection, the Initiator of the Change Request, and other concerned parties.

Accepted objection response

The Objection Response The information returned by an API after a request is made. Responses are usually in JSON or XML format. Transaction for an accepted Objection has:

  • Information in the Event severity element

  • 0 (zero)in the Code element.

Rejected objection

For a rejected Objection, MSATS:

  • Does not update the status of the Change Request.

  • Does not send Notifications to other parties.

Rejected objection response

The Objection Response Transaction for a rejected Objection has:

  • An error code in the Event > Code element.

For help with error codes, see MSATS Web Portal > Administration > Codes Maintenance.

  • An explanation explaining the rejection details.

Objection notifications

  • When MSATS receives an Objection, it notifies the Objection Initiator of acceptance or rejection by placing the Objection Response zip file in the Participant Outbox.

  • MSATS sends XML notifications to other participants in line with the Notification Rules. Usually the Initiator of the Change Request and other concerned parties.

When MSATS sends a Notification for an Objection or Objection Withdrawal, along with the usual information, it has a section describing the Objection with:

- The Objection Role

- The Objection Code

- Objection date (the date MSATS received the Objection).

- The ObjectionAction: Raised.

Objection withdrawal

The Initiating participant can withdraw their own Objection. Other participants are informed 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..

You can withdraw an Objection if:

  • The provided Objection ID is valid.

  • You are the Initiator of the Objection.

  • The related Change Request is not cancelled.

If the objection withdrawal is valid, MSATS cancels the Objection and updates the Change Request status to Requested or it remain Objected if other participants have raised Objections still pending.

Change Requests having their status updated to Requested are updated during the Overnight Processing to Pending A status point of a Change Request. if the Objection Logging Period has passed.

Table 105 Objection withdrawal fields

Field

Field code

Description

Change Request ID

REQUESTID

The unique identifier of the Change Request relating to the objection

Participant Transaction ID

PARTTRANSACTIONID

The 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 identifying the previously entered objection the participant wants to withdraw

Role ID

ROLEID

The Role permitted to object

 

Objection withdrawal notifications

After Objection withdrawal, depending on the Notification rules, participants are informed of the Objection withdrawal and the Change Request status. Usually, all participants receiving an Objected Notification receive the Objection Withdrawal Notification.

A web portal withdrawal receives immediate Notification on the interface, while a Batch A right type assigned to a participant user by their participant administrator to access a Batch (file) application withdrawal is acknowledged by an Objection Withdrawal Response in the participant’s Outbox.

If the Objection withdrawal is successful, the participant withdrawing the Objection is notified of its success:

  • If there are active objections, the Notification has an OBJ status.

  • If all objections are cleared, the Notification has a REQ status.

The Notification includes an Objection section with the Objection details where the ObjectionAction is Withdrawn (see Withdrawn objection notice Page 1).

MSATS records an error and the Objection Withdrawal Response indicates the withdrawal is rejected if an Objection withdrawal request is not valid such as:

  • The objection record does not exist.

  • The withdrawing participant is not the Initiating party.

  • The Change Request has an invalid status.

Figure 145 Withdrawn objection notice