Change requests

The most significant Transaction See Relevant Rules or Procedures is the Change Request A transaction submitted by participants in MSATS whenever they want to create or update data held in MSATS. used by participants to submit or update CATS Standing Data The data held in the following database tables: • CATS_NMI_Data_Stream • CATS_NMI_Data • CATS_Meter_Register • CATS_NMI_Participants_Relationships • CATS_Register_Identifier NMI Standing Data is a sub-set of the CATS Standing Data..

Participants use Change Requests to interact with 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. for some or all aspects of information regarding a Consumer An end use customer of energy.’s Connection Point, including:

• The names and Roles of companies (Participant IDs) providing a Connection Point service to a Consumer.

• The technical details associated with the Consumer’s Metering Installation.

• The specific information assisting Retailers to provide competitive offers to End-use Consumers.

Change requests include:

• Names and relationships of participants having Roles associated with the NMI See Relevant Rules or Procedures.

• Standing details required to support:

- The Profile Preparation Service (PPS Profile Preparation Service: Calculates profile shapes by using algorithms and interval energy data. The calculation of the NSLP or the CLP.)

- Basic Meter A device complying with Australian Standards, containing a measurement element(s) and a record of the accumulated quantity of the electricity flowing through the power conductor. Also known as an accumulation meter. Profiler (BMP Basic Meter Profile: The application of profile shape data to accumulated metering data to create half-hourly interval metering data for a Profile Area. Records the total amount of energy consumed at a connection point from the initial energisation of the meter.)

- Data Aggregation An aggregation implies there are at least two or more classified NMIs in the dispatchable unit for central dispatch.

- Settlement.

- NMI Discovery.

- Metering Register with metering installation data.

The Transaction types Exchange or Delivery required to create and manage Change Requests are:

• Change request

• Change withdrawal

• Objection A type of transaction raised in relation to a Change Request.

• Objection withdrawal

Change request rules

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.:

• Can only have one NMI in relation to the Change Request but can have multiple NMI suffixes and multiple Meter Serial IDs.

• Is wrapped in an 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. message format, capable of accommodating more than one Change Request. For details, see aseXML Guidelines Guidelines for the development of a Standard for Energy Transactions in XML (aseXML). on AEMO’s website.

• Can only be assigned one DLF Code A code used in MSATS to identify a distribution loss factor..

• Is Initiated for an event using one of the Change Reason Codes Page 1.

• Has a set of 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. Standing Data items varying with the selected 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..

Change request life cycle

A Change Request is a temporary Transaction going through a life cycle starting when it is created (Initiated) and ending when it is terminated (Completed One of the status points of a Change Request.). The completion of a Change Request and the formation of a NMI Master Record The NMI master record with an end date set to the year 9999. occur simultaneously.

The basic life cycle is:

Change request status

Table 40 Change request statuses

Code	Description	Notes
PVAL	Pending Validation	The Transaction passed Checksum Validation. If the change request is awaiting missing data, MSATS updates the Proposed Change Date and Initiator when it receives the missing data
REQ	Requested	MSATS has sent Notifications. MSATS has all data required to initiate the Transaction
PEND	Pending	The Transaction has passed the objection period and is either: Awaiting final details before it can complete Awaiting arrival of the Proposed Change Date
OBJ	Objected	MSATS has received an objection and the transfer is suspended until the Objection is either: Withdrawn The objection period lapses (MSATS cancels the Change Request)
CAN	Cancelled	Cancellation reasons: The proposed new retailer is deregistered as a result of a RoLR event (the RoLR process cancels in-progress Change Requests for that Retailer) A nominated number of days have passed since MSATS received Objections and they are not withdrawn The initiator of the Change Request has withdrawn it
COM	Completed	Completion reasons: There are no outstanding Objections The Proposed Change Date is either reached or passed All data MSATS was awaiting, e.g. an Actual Change Date from an MDP is delivered
REJ	Rejected	Rejection reasons: Does not pass all validation rules

 

Initiated status

Initiation is the first step in the creation of a new Change Request where the Initiating participant:

1. Selects the Transaction Type Code CR.

2. Selects the Change Reason Code most appropriately relating to the relevant event (see page Page 1).

3. Populates the Change Request with the data permitted by the selected Change Reason Code.

4. Submits the Change Request to MSATS, using one of the B2M interfaces.

Participant can withdraw a Change Request until the Change Request is in Completed status.

Pending validation status (PVAL)

1. Commences when the Change Request passes initial MSATS validation.

2. Finalises after the Change Request has either:

1. Accepted: All required data is submitted.

2. Rejected: Data is missing or inaccurate.

Rejected status (REJ)

The Rejected A status point of a Change Request. Meaning the Change Request failed a validation test in MSATS. (REJ) status occurs when a Change Request fails validation, either:

1. In Pending Validation status.

2. In Completed status. In rare circumstances where a change to data was made after this Change Request was submitted, making this change invalid.

Requested status (REQ)

The Requested A status point of a Change Request. status occurs when a Transaction is validated, for example:

1. There is no missing data.

2. The Objection Logging Period and Objection Clearing Periods are over.

Objected status (OBJ)

The Objected A status point of a Change Request. status occurs when one or more Objections are received:

1. Event notifications are sent to the relevant parties with details of the Objections.

2. The status changes to:

1. Requested: When the last Objection is withdrawn, and the Objection Logging Period has not expired.

2. Pending: When the last Objection is withdrawn, and the Objection Logging Period has expired.

3. Cancelled: When the Objection Clearing Period has expired and an Objection, subject to the Objection Logging Period is not withdrawn.

Pending status (PEND)

The Pending A status point of a Change Request. status:

1. Occurs when no Objections are received, or all Objections are withdrawn, and the Objection period passes.

2. Remains while any required data remains outstanding, or an Objection, not subject to the Objection Logging Period is not raised.

3. Changes to Completed if the Proposed Change Date is reached and all required data is present.

Completed status (COM)

The Completed status occurs when a Change Request:

1. Is Pending, the Proposed Change Date is reached, and all required data is present.

2. Is Objected, if:

1. No Objections are received, the Objection Logging Period has ended, and an Actual Change Date exists.

2. Objections are received, all Objections are withdrawn, the Objection Logging Period has ended, and an Actual Change Date exists.

3. Is simultaneous with the formation of a NMI Master Record and is effective from the Actual Change Date.

Cancelled status (CAN)

The Cancelled A status of a Change Request. status occurs when:

1. The initiator of the Change Request withdraws the Transaction

2. MSATS cancels the Change Request because:

1. Not all Objections are withdrawn at expiry of the Objection Clearing Period.

2. It is in Pending status longer than seven months from the date of initiation.

3. A Type 2 Concurrent Transfer scenario applies.

Change request role status

The status of each 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. on the NMI Master Record is classified as Current The participant can receive files compliant to the current aseXML version.. If the Change Request to CATS Standing Data is a Role, the status of the Role is changed to New.

Change request example

To demonstrate the generic steps of a Change Request, this example uses the Change Reason Code 1000 Change of Transaction, editing the Participant Role Relationship (other categories cannot be changed for the Change Reason code 1000).

As shown in Steps 6 and 7 in Generic web portal change request steps Page 1, depending on the Change Reason Code used (see page Page 1), there are five categories of information (see page Page 1):

1. Participant Role Relationships

2. NMI Standing Data

3. NMI Datastream

4. NMI Meter Register

5. NMI Register Identifier

For each category, a list of records displays on the Change Request Transaction. If they are for a particular category, they are already linked and cannot change.

If the list is blank, participants must create new information records for the category so the Change Request can pass validation (see page Page 1).

A change request is not complete until all conditions are met:

1. The Proposed Date has passed.

2. The Objection Period has passed.

3. It does not have any active objections.

4. It is not waiting for an Actual Change Date from another party.

When all conditions are met, the Change Request moves to completed status and the new participant name displays as the FRMP Financially Responsible Market Participant, usually a retailer, Generator, Market Customer or a Market Small Generator Aggregator, identified in respect of a connection point. Responsible for dealings with AEMO in relation to a specific load..

Figure 100 Generic web portal change request steps

Change request errors

For more details about error codes, see page Page 1.

Common errors and possible explanations Page 1 explains common Change Request errors and their possible explanations:

• The error number is the number returned in a Change Request response if a Transaction is submitted by Batch or Web Portal and fails validation.

• The error description is the message you see if you submit an invalid Change Request. It has some additional information identifying what caused the error. This additional information is not in Common errors and possible explanations.

• Common errors and possible explanations does not include errors received from a NMI Discovery Search. If you receive an error that is not in Common errors and possible explanations and require help, please contact the Support Hub (see details Page 1).

Table 41 Common errors and possible explanations

Number	Description	Possible explanation
1002	A duplicate row exists	Check if you submitted the same data twice This may happen if, for example, you saved a Datastream, clicked the Back button on your browser, and then clicked Save again To see the duplicate entry: Return to the main screen To change the data, click Edit
1101	Data fields provided are not valid for this Change Request	Check the allowed fields have a Field Validation Data Source Code of RA or RQ (see page Page 1) To confirm allowed fields, check the Change Request Field Validation Rules Page 1 Alternatively, check you entered a valid Change Reason Code (see page Page 1)
1100	Invalid data on Change Request	Check you entered a valid Embedded Network Code Identifier (CATS_EMB_NET_ID_CODES table) See page Page 1
1109	Invalid NMI Classification Code	Check for a valid NMI Classification Code (CATS_NMI_CLASS_CODES table) or the Start Date for the NMI Classification Code is after the Proposed Change Date on the Change Request (see page Page 1) You also see this message if you try to change the Jurisdiction on the NMI and the NMI’s Start Date is more recent than the Proposed Change Date on the Change Request
1111	Invalid TNI Code (or similar, e.g. DLF Code)	Check for a valid TNI Code (CATS_TNI_CODES table) or the Start Date for the TNI Code is after the Proposed Change Date on the Change Request
1113	Invalid Jurisdiction Code	Check if you entered an invalid Jurisdiction Code or a Jurisdiction Code with a Start Date after the Proposed Change Date on the Change Request You also see this message if you try to enter a Change Request where the Proposed Change Date is prior to the Start Date on the NMI
1120	Invalid Participant ID	Check if you nominated a participant in a Role they are not entitled to perform, either because: They are not valid for that Role They were not valid for that Role for the period covered by the Change Request The Participant ID you entered is not valid The name you entered is not in UPPER CASE See Role ID Codes (CATS_PARTICIPANT_ROLES table) Page 1
1121	The participant is not valid for the given Role	Check if the participant you nominated is valid for the Role. See Role ID Codes (CATS_PARTICIPANT_ROLES table) Page 1
1122	TNI Code required for the NMI (or similar)	Check if the Proposed Change Date is prior to the Start Date of the NMI This message is also sent if you try to remove the TNI Code from a NMI
1133	Date period causes a gap in the NMI Master Record	Check if you tried to make a Retrospective Change and supplied an End Date prior to the Start Date of the NMI The End Date must be the Day before, on, or after, the Start Date
1134	Date period causes a gap in the records in the CATS_METER_REGISTER table
1135	Date period causes a gap in Roles
1144	NMI not found for the Datastream	Check the NMI Status Code is not D or X You must activate this NMI (i.e., change its NMI Status Code to A) before you can update any Datastreams You can activate a NMI using a Change Reason Code such as 5051 (see page Page 1) This Change Request must complete before you can create the Change Request to update or create the Datastream
1146	Meter Serial ID must exist for Meter	Check the Meter Serial ID you are updating the Next Scheduled Read Date for exists for this NMI You can request a NMI Master report or you can use the NMI Master Search
1147	Metering Installation Type Code must exist for Meter	Check you are not creating a record without specifying a Metering Installation Type Code, see page Page 1 Check you are updating a valid Meter Serial ID If invalid, create the record using CR 3001 or CR 3000, see page Page 1
1148	Invalid Profile Name for NMI's Jurisdiction	Check you assigned a valid Profile Name to a Datastream in the Jurisdiction where this NMI is located
1149	ADL must be less or equal to 2000 for NMIs with NMI Classification Code of SMALL	Check if you are changing the Average Daily Load (ADL) on a NMI having a NMI Classification Code of SMALL and your value is greater than or equal to 2000, see page Page 1 MSATS has a validation designed to ensure ADLs are reasonable
1151	Not all required fields have been entered. Please ensure all fields have been completed	Check you completed all required fields for the selected Change Reason Code, see page Page 1 You must supply all fields on a Change Request where the Field Validation Data Source Code is RI, see page Page 1
1150	Initiating Participant is not an active CATS Participant	The participant submitting the Change Request is not active for the period of the Transaction
152	Initiating Participant is not a valid initiator of the Transaction.	Check if you tried to initiate a Transaction where you are not a valid Initiator If this is a Change Request initiated by a Current Role (e.g. CR 4001), check: You are the valid participant for the Role for the period covered by this Change Request The NMI exists in MSATS (If this is a Change Request initiated by the Current participant and the NMI does not exist, you get this message because MSATS cannot find the Current Participant The Proposed Change Date is after the Start Date of the NMI If this is a Change Request initiated by a New Role (e.g. CR 2001), check: The Participant ID can act in the specified Role The proposed participant for this Role goes back as far as the Proposed Change Date on the Change Request You nominated yourself in the initiating Role
1153	Date is not in the past	Check the date entered is for a Retrospective Change
1154	NMI does not match NMI on original Change Request	Check if you are trying to change an existing Change Request but the NMI you supplied is not the NMI on the original Change Request. If you supply an ID on a Change Request identical to an existing Change Request, MSATS assumes the Transaction is a change to the existing Change Request. Another possible reason is the NMIs match, but the request ID specified does not match the ID of the existing Change Request
1156	NMI and NMI Checksum do not match	Check the NMI is valid
1157	Original Change Request is not found or is not active	Check you supplied a valid ID on a Change Request Is it a CR 1500 or a change to an existing Change Request? The existing Change Request will confirm the correct ID
1160	Date is not within the allowed number of days.	Check the Proposed Change Date is not too far in the past for a Retrospective Change or too far into the future for a Prospective Change Check the maximum allowable number of days (expressed in Business Days) in the Time Frame Rules for the Change Reason Code If it is a Retrospective Change, it is the Retrospective Period If it is a Prospective Change, it is the Prospective Period See page Page 1
1168	No Jurisdictional Rules found for Change Request, NMI Classification Code	Check the Change Request you are creating is valid for the NMI’s Jurisdiction and NMI Classification Code If you are changing the Jurisdiction or NMI Classification Code you must check an entry exists for the new Jurisdiction Code or NMI Classification Code along with the Change Reason Code in the Jurisdictional Parameters, see page Page 1
1169	Date submitted should not be in the past for this type of Change Request	Check the Prospective Change Date, you can enter tomorrow’s date at the earliest
1172	Metering Installation Type Code does not exist	Check if you are submitting a Prospective Change for a Change of Retailer (e.g. CR 1000 or CR 1030) and there is no Meter record for this NMI You can contact the Current MPB to arrange for its creation or if it is permitted in the Jurisdiction, you can wait until after the Proposed Change Date and then submit a Retrospective Change Request
1178	Attempting to create a NMI that already exists	Check if you are using one of the Change Reason Codes for creating NMIs (i.e. CR 2000, CR 2001, CR 2020, CR 2021, CR 2500, CR 2501, CR 2520 and CR 2521)
1179	Attempting to edit a NMI that does not exist. For example:  NMI: 1000999900 CR 1000	Check you are using one of the Change Reason Codes used to create NMIs: CR 2000, CR 2001, CR 2020, CR 2021, CR 2500, CR 2501, CR 2520 and CR 2521 The NMI entered in the example: 1000999900 does not exist but you cannot use the Change Reason Code CR 1000 to create NMIs Check you entered the correct NMI. If yes, contact the relevant LNSP and arrange for the LNSP to create the NMI
1198	Meter Register Status Code A code used in MSATS to delineate the status of a meter. For more detail, see the CATS Procedures. must be either C, R or D	Check the Meter Register Status Code is valid for the Change Request, see page Page 1
1280	No participant exists from whom data is to be requested for this NMI	Check if the NMI exists in MSATS You entered a Change Reason Code having some RQ fields in its Field Validation Rules. RQ fields send a Data Request if there is missing data for the NMI In this case, because there is no NMI, MSATS can’t find a participant in the Role to send the Data Request to so instead sends this error message Also check, if you tried to transfer a NMI from a date prior to the Start Date of the NMI because, for this period, there is no valid participant
5026	NMI extinct	Check if you submitted a transfer request for a NMI with a NMI Status Code of X The only valid NMI statuses for transferring a NMI are G, D, N or A
5028	CAN – The change dates for this Change Request conflict with another CR 1000 series Change Request in the system	Your Change Request is cancelled because there is a concurrent transfer (for details, see the MSATS Procedures: CATS Procedure Principles and Obligations) In a Type 2 situation it means another participant submitted a Change Request to transfer Retailers with a date range matching or overlapping yours, so your Change Request is Cancelled. This can happen at any stage of the Change Request Lifecycle
5029	REJ – The change dates for this Change Request conflict with another CR 1000 series Change Request in the system	Your Change Request is rejected because there is a concurrent transfer (for details, see the MSATS Procedures: CATS Procedure Principles and Obligations) In a Type 1 situation it means you have previously submitted a Change Request for this NMI that hasn’t reached COM status, so your subsequent Change Request is Rejected In a Type 2 situation it means an existing Change Request from another participant exists with a date matching or overlapping yours, so your Change Request is Rejected
5032	CAN – Change Request has been cancelled	MSATS has automatically Cancelled your Change Request because it remained incomplete longer than 7 months
5036	Invalid combination of Change Reason Code for Read Type Code	Check if your transfer request has an invalid Change Reason Code and Read Type Code For example, you may have submitted a Retrospective Change with a Read Type Code of NS (Next Scheduled Read Date) or you may have submitted a Prospective Change with Read Type Code of PR (Previous Read)
5038	FRMP cannot be Current FRMP	Check if you are transferring a NMI to a participant where the Participant ID is the current FRMP in the CATS_NMI_PARTICIPANT_RELATIONS table
5039	MDP cannot be Current MDP	Check if your nominated MDP is the same party as the Current MDP You only nominate the MDP if it is changing from the Current MDP
5041	Invalid Transaction. Must nominate at least one of New MDP, MPB or MPC	Check if you have nominated the Roles you want to update You are required to nominate the New MC and at least one of either the New MDP, New MPB, or the New MPC
5042	The LR for a Child NMI must be the FRMP of the Parent NMI	Check if you are changing the LR on a Child NMI not matching the Participant ID assigned as the Parent FRMP
5044	The minimum mandatory data must be populated	Check you provided all mandatory data
5045	The Change Request initiator must be a Current Participant	You are not the Current Participant assigned to the Role required to submit this Change Request
5046	The Change Request must only be used on NMIs in the status of <status>	Check if you are submitting a Change Request for a NMI with an invalid NMI Status Code
5059	MDM Contributory Suffix is mandatory	You did not provide the MDM Contributory Suffix in the Change Request or at the completion of the Change Request
5060	Network Tariff Code is mandatory	You did not provide the Network Tariff Code in the Change Request or the result of completion of Change Request results in the Network Tariff Code as null
5120	No NMI range is assigned for the Participant ID	You tried to create a NMI when there is no NMI range assigned to you
5121	NMI falls within an excluded NMI range	You tried to create a NMI from an excluded NMI range.
5122	Proposed NMI is outside the allocated NMI range for the Participant ID	You tried to create a NMI outside the allocated NMI range for your Participant ID.
5047	Meter Serial ID does not exist	Check the Meter Serial ID exists
5048	Register ID does not exist	Check the Meter Register record exists
5049	Datastream does not exist	Check the Datastream exists
5050	The Change Request must be used to remove at least one Meter with a Meter Register Status Code of current or remotely disconnected	To remove a Meter, check the Meter Register Status Code is C or D
5051	The Change Request must be used to create at least one Meter with a Meter Register Status Code of current	To create a Meter, check the Meter Register Status Code is C
5052	The Change Request must be used to remove at least one Register ID with a Meter Register status code of current	To remove a Register ID, check the Meter Register Status Code is C
5053	The Change Request must be used to create at least one Register ID with a Meter Register Status Code of current	To create a Register ID, check the Meter Register Status Code is C
5054	The Change Request must be used to deactivate at least one Datastream with an existing Datastream Status Code of active	To make a Datastream inactive (I), check the Datastream Status Code is A
5055	The Change Request must be used to create at least one Datastream with a Datastream Status Code of active	To create a Datastream, check the Datastream Status Code is A

 

Actual change date

The change is effective from the 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.. A Change Request Initiated to create a NMI uses the Proposed Change Date The proposed date when a Role transfers from one participant to another. to populate the Actual Change Date allowing the Change Request to complete.

Change request completion

Providing MSATS does not receive Objections and an Actual Change Date exists it completes the Day after the Objection Logging Period The number of business days available to a participant for entering an Objection in MSATS. ends.

If MSATS receives an Objection it completes the Day after all Objections are withdrawn, the Objection Logging Period The 288 periods from 4:30 am to 4:00 am. has ended, and an Actual Change Date exists.

Change retailer

Retailers (FRMPs) transferring an End-Use Customer require a list of valid Previous Read Dates (PRDs) and the associated Quality Flag. MSATS does not notify the LR Local Retailer. A business unit or related body corporate of the relevant local network service provider, or responsible under the laws of the relevant participating jurisdiction for the supply of electricity to franchise customers in that local area. at the time a change of FRMP occurs.

See also, NEM Customer Switching on AEMO’s website.

In a small number of cases, a submitted Change Retailer See Relevant Rules or Procedures Change Request may get rejected because the MDP Meter Data Provider. An organisation which installs, commissions, gathers, and verifies data remotely from meters in the National Electricity Market (NEM). submitted new or updated Metering Data between the completion of a NMI Detail search and the Change Request submission.

PRD and quality flag process

MSATS provides Previous Read Dates for data reviewed in a 12-month retrospective period.

When MSATS receives a valid NMI Discovery Search 2 The process of entering a NMI and NMI Checksum in MSATS to obtain NMI Standing Data. For more detail, see the NMI Standing Data Access Rules in the CATS Procedures. it determines:

1. The NMI Classification is: L - Large or S - Small.

2. The NMI Status is: A – Active or D – Not Energised.

3. The NMI has at least one Meter with a Meter Register Status of: C – Current or D – Remotely De-Energised.

4. The Metering at the NMI has a Metering Installation Type Code of:

1. BASIC - Accumulation Meter

2. MRIM - Manually Read Interval Meter (not having a Meter Read Type of RWD)

3. MRAM – Small Customer Metering Installation – Type 4A

5. An active Data Stream (at least one) within a 12-month retrospective period.

6. If a NMI does not meet any of the criteria in step one above, MSATS provides an error message.

7. If multiple Metering Installation Types exist for a NMI, MSATS provides the following message: Metering Review Required.

8. Read Dates and Quality Flags for a 12-month period from the current date.

9. Uses the Quality Flags described on page Page 1.

10. Each unique PRD and associated singular Quality Flag.

Previous read date hierarchy

MSATS determines a Previous Read Date based on the following hierarchy:

1. Datastreams

2. MDPVersionDate and Time

3. Quality Flag (when both of the above are successful)

Previous read date validation

The End-Use Customer transfer proceeds without the need for the MDP to confirm a Meter reading exists using a CR1500:

1. MSATS identifies if the Change Request (CR) has a Read Type Code of PR (Previous Read) and is not a CR1040.
   If it is a CR1040, no PRD validation is required and the transfer progresses to Requested (REQ) based on transfer and CR processing validations.

2. If the Read Type Code is PR, MSATS ensures the Proposed Change Date in the CR matches the PRD
   If the PRD does not match the Proposed Change Date, MSATS rejects the CR with a 1016 error: Proposed Change Date does not align to a Previous Read Date. This validation represents the PRD at the time the CR was raised. An MDP may have provided new Metering Data since the NMID was performed.

3. Where the PRD matches the Proposed Change Date in the CR, the transfer progresses to Requested (REQ) based on existing transfer and CR processing validations without requiring a CR1500.

4. The Proposed Change Date in the CR becomes the Actual Change Date for the transfer.

Consumption data process

If the Metering Data is Consumption The electricity used over a period of time, the following process determines the PRD:

1. Find all Metering Data for the NMI within the previous 12 months.

For each active Data Stream A stream of metering data associated with a connection point, as represented by a NMI. A NMI can have multiple data streams (e.g. from one or more meters, or from one or more channels or registers that comprise a single meter).  Each data stream is identified by a unique suffix associated with the NMI., determine each of the current ToDates, if a valid Quality Flag exists.
The ToDates refer to the ToDate in the MDFF Meter Data File Format. The standard format for delivery of metering data to market participants, service providers and registered participants. file received from the MDP for the NMI. For details, see MDM Meter Data Management system includes the Profile Preparation Service, Basic Meter Profiling, and Data Aggregation. File Logically groups one or more reports delivered as a physical file, for example BILLING. Participants subscribe to files in the Markets Portal > Data Interchange > Data Subscription interface. Format and Load Process.

2. If there are multiple Data Streams, MSATS ensures the ToDate is the same date for all Data Streams for the NMI.

3. The PRD is the valid ToDate + 1 determined by MSATS.

4. If MSATS successfully determines a PRD, it looks for corresponding Quality Flags.

5. Because MSATS can receive reads for multiple meters and/or Datastreams, to determine a single Quality Flag for each PRD, MSATS applies the logic on page Page 1.

6. MSATS returns all valid PRDs and the determined Quality Flag limited to a maximum of 12 Previous Read Dates within the previous 12-month period.

 

Interval data process

If the Metering Data is Interval Period over which interval energy data is recorded by the metering installation that corresponds to a TI or submultiples of a TI., the following process determines the PRD:

1. For each unique MDP Version Date, MSATS determines the latest Interval Date of the reads for all valid Data Streams for the NMI that contains only valid Quality Flags.
   The Interval Date refers to the IntervalDate in the MDFF file received from the MDP for the NMI. For details, see MDM File Format and Load Process.

2. MSATS ensures the Interval Date determined in step 1 is the same date for all active valid Data Streams for that Interval Date.

3. The Previous Read Date (PRD) is the date after the last valid Interval Date + 1 in the MDP Version Date.

4. If MSATS determines a PRD, it looks for a corresponding valid Quality Flag.

Because MSATS can receive reads for multiple meters and/or Datastreams, to determine a single Quality Flag for each PRD, MSATS applies the logic on page Page 1.

5. For the determined PRD, the following applies:

1. Any day of data containing a single Z or E Quality Flag is not considered for the PRD process.

2. Any day of data containing a single N returns an error for that PRD.

3. Where a reading period is:

○ 1 day where two or more hours of a lower level flag exists, the Quality Flag does not reflect that level for the PRD.

○ 2–7 days where four or more hours of lower level flag exists, the Quality Flag reflects that level for the PRD.

○ 7 or more days where 48 hours or more of a lower level flag exists, the Quality Flag reflects that level for the PRD.

6. MSATS returns all valid PRDs and the determined Quality Flag limited to a maximum of 12 Previous Read Dates within the previous 12-month period.

No active meter

MSATS provides an error message: There are no current meters installed for this NMI, if it determines, for a single NMI, there are no Meters and Meter Register The meter register data stored in MSATS, which includes both the metering register and other data. Statuses of:

1. C – Current

2. D – Remotely De-Energised

Mixed metering types

MSATS provides an error message if it determines, for a single NMI, there are multiple Meter Installation Type Codes for Meters with a Meter Register Status of:

1. C – Current

2. D – Remotely De-Energised

No metering data

MSATS provides an error message: No Metering Data available, if it determines, for a single NMI, there is no valid metering data available.

MDM database unavailable

MSATS provides an error message: Unable to retrieve data at this time if it is unable to obtain Metering Data from the MDM database.

Quality flags

Consumption data quality flags

To determine a single Quality Flag (QF) for a PRD, MSATS applies the following logic.

QF combination	PRD and Quality Flag
A	A – Actual
A & F	F – Final Substitute
A & S	S – Substitute
F & S	S – Substitute
A, F, & S	S – Substitute
E	Not considered for the PRD

 

Interval data quality flags

Hierarchy	QF combination	Previous Read Date Quality Flag
1	A	Actual Reading
2	F	Final Substitute
3	A & S	Substitute
5	Z or E or anything else	Not considered for this purpose

Quality flag reading period

Based on the QF hierarchy, the following also applies for each PRD:

Reading Period	Description
N	Error returned for that read date
1 Day	When 2 or more hours of a lower-level flag exists, the QF reflects that level for the PRD
2 – 7 Days	When 4 or more hours of lower-level flag exists, the QF reflects that level for the PRD
7+ Days	When 48 hours or more of a lower-level flag exists, the QF reflects that level for the PRD

 

Standing data requirements

Tier 2 Site

If a Change Retailer Change Request completes and an End-use Customer transferred to a second tier Retailer (such as, the FRMP is not equal to the LR):

• The LNSP or the ENM Embedded Network Manager in the case of Child Connection Points, must ensure the NMI Status Code A code used in MSATS to determine if a NMI can be the subject of a retail transfer. For more detail, see the CATS Procedures. is A.

• The MDP must ensure there is a Datastream with a Datastream Status Code of A, covering the period from the date of the retail transfer.

• If the Datastream Status Code is A, the MDP must submit Metering Data to MSATS regardless of the Site The physical location of the connection point, see B2B Procedures: Customer and Site Details and Service Orders Process. status.

NMI creation

After a NMI is created, and prior to the Actual Change Date:

• The Meter(s) and default NMI Datastreams may be set up by whoever is nominated as the default party, even if it is a Tier 1 Site A site where the FRMP is the LR. This could be the case where: • The End Use Customer has transferred back to the LR as their retailer (FRMP) after a period with another retailer. • The site is not contestable. • The site is contestable but the End Use Customer has not transferred to another retailer. See also first-tier controlled load. NMI and not needed for profiling (according to Jurisdictional requirements).

• If a Datastream is not set up, the entry of the NMI into MSATS is not delayed.

Change retailer reversal

There are 2 reversal codes to reverse or undo a previous Change Retailer Change Request (CR Change Request), both behaving exactly like other CRs.

CR code	Description	Use	Initiation window	Reverses CRs
1060	Reverse Retailer – Cooling Off	Raised by the winning FRMP (e.g. the FRMP raising the CR10XX that completed within the initiation window	Within 10 Business Days	1000 1010 1030 1040
1061	Reverse Retailer – Debt Objection	Raised by the losing FRMP in Victoria only (e.g. the FRMP who was current on the NMI prior to the completion of the CR10XX)	Within 1 Business Day	1000 1010

 

Reversal process

Precondition

A previous change of FRMP role has processed to COM (complete) status.

Generic reversal example

1. FRMP raises a reversal CR.

2. MSATS validates the initiating Participant ID and Role is either for:

1. A CR1060: the same FRMP Participant ID and Role that initiated the related CR ID.

2. A CR1061: the most recent previous FRMP

3. MSATS validates the related CR ID:

1. Is eligible for reversal.

2. Has COM status.

3. Has an Actual Change Date within the retrospective time frames specified.

4. Is the most recently completed CR for the NMI being reversed such as: Role, Meter, etc.

5. The reversal meets the defined initiation time frames.

6. For a CR1061, the Jurisdiction is VIC (Victoria).

4. Where the reversal CR is a 1060 or 1061, determine there is no other related transfer impacted. For details, see the Concurrent Transfer Process in the MSATS Procedures.

5. For a valid CR, MSATS updates the CATS CR record with all values of the related CR ID, including the Proposed and Actual Change Dates.

CRs not passing validation process to Rejected (REJ) with error codes provided to the related parties.

Reversal history model

CR1060 Cooling off reversal

CR1061 Debt (Vic only)

 

 

Change request withdrawal

The Initiating participant can Cancel A ServiceOrderStatus indicating the Service Order is cancelled. (withdraw) a Change Request at any time prior to Completion. The status is then changed to cancelled (CAN) and other parties 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..

Participants cannot withdraw a Change Request if it is in Completed (COM), Cancelled (CAN), or rejected (REJ) status.

Concurrent retail transfers

Concurrent retail transfers are where there is more than one change of Retailer for a NMI at the same time. There are two types of concurrent retail transfers, Type 1 and Type 2.

Streamlined change requests

MSATS includes a category of streamlined Change Requests (see Streamlined change requests Page 1), only used with Tier 1 NMIs. Tier 1 NMIs are NMIs where, for the whole period covered by the Proposed Change Request, the FRMP, and the Local Retailer are the same participant.

Streamlined Change Requests do not have Notification A transaction that does not have a corresponding reply transaction, see Notification Business Transaction Pattern. rules. It is the responsibility of the Initiating participant to ensure all related participants are advised of the change.

If someone tries to submit a Change Request for a NMI not meeting these business rules the Change Request is Rejected.

Table 42 Streamlined change requests

CR code	Description
2003	Create NMI Details – Retrospective
3003	Create Meter Details – Retrospective
3053	Change Meter Details – Retrospective
4003	Create MDM Datastream – Retrospective
4053	Change MDM Datastream – Retrospective
5053	Change NMI Details – Retrospective

 

Type 1 Concurrent Retail Transfers

Type 1 is where the same FRMP submits more than one Change of Retailer Change Request for the one NMI. MSATS:

1. Identifies type 1 concurrent retail transfers and the FRMP initiating the Change Requests.

2. Rejects the newly submitted Change Request and sends a Change Request Notification to the initiating FRMP with the reason for the rejection.

3. Retains the existing Change Request which is unaffected and still active.

Type 2 Concurrent Retail Transfers

Type 2 is where more than one FRMP submits a Change of Retailer Change Request for one NMI. MSATS:

1. Identifies type 2 concurrent retail transfers and the FRMPs initiating them.

2. Rejects the newly submitted Change Request and sends a Change Request Notification to the initiating participant with the reason for the rejection.

3. Cancels the existing Change Request to the Retailer and sends a Change Request Notification with the reason for the cancellation to all parties related to the Change of Retailer Request (in line with normal notifications, such as: FRMP, MDP, MC etc).

Affected FRMPs

1. The affected FRMPs determine the reason for the concurrent retail transfers and investigate who is the preferred FRMP for the End-use Customer, consistent with relevant Jurisdictional requirements.

2. The preferred FRMP initiates a single valid transfer Change Request.

Editing change requests

MSATS web portal change request edit

To edit a Change Request in the MSATS Web Portal:

1. Find the Change Request.

2. Next to the Change Request, in the Actions, click Edit.

How MSATS handles the edited change request

When MSATS detects an edit to an existing Change Request, it does the following:

1. Creates a new Change Request (with a new Request ID) containing:

1. Data in the original Change Request.

2. Data in the new Change Request.

If you supply data in the new Change Request also in the original one, MSATS replaces the old value with the new value.

If you supply different data in the new Change Request not in the original one, MSATS includes the additional data in the new Change Request.

Cancels the original Change Request.

2. Cancels the Change Request you submitted.

3. The new Change Request status is set to REQ and the Objection Logging Period begins again (the edited Change Request starts its life cycle again).

API and batch change request edit

For more details about editing a Batch Change Request, see page Page 1.

To edit a Change Request submitted by API Application Programming Interface; a set of clearly defined methods of communication between various software components. or Batch A right type assigned to a participant user by their participant administrator to access a Batch (file) application:

1. Withdraw the initial change request.

2. Submit a new change request.

Editing the proposed date

Most Change Requests require a Proposed Change Date. The only exception is a CR1500 where only the ActualChangeDate is supplied.

After checking for a valid date, MSATS either:

1. Copies the value in the ProposedDate field to the ActualChangeDate field.

2. If the Field Validation Rules state another participant must supply the Actual Change Date, it sends a Data Request.

This processing is part of the Change Request’s initial validation. If, when you edit a Change Request you change the Proposed Date, MSATS replaces the new value you supplied in the Proposed Date field.

Change request with a data request

If the Change Request sent a Data Request A transaction initiated by MSATS and sent to a participant at the Pending Validation status of the Change Request life cycle., the Actual Change Date is still determined by the date supplied by the MDP, so your change to the Proposed Change Date does not have an effect.

If you need to change the Proposed Change Date on a Change Request still in progress and the Change Request does not send a Data Request to the MDP, you must withdraw the original Change Request and submit a new one:

• No delay is caused because editing a Change Request restarts the Objection Logging Period

• It ensures the ActualChangeDate is what you intend.

Change request without a data request

If the Change Request did not send a Data Request (for example, CR1020) the original Proposed Change Date is copied into the ActualChangeDate field. Changing the Proposed Change Date does not affect the original Actual Change Date.

You cannot edit the ActualChangeDate because it is not an editable field. So, even though you as the initiator, changed the Proposed Change Date, the Actual Change Date remains the same.

Retrospective and Prospective change requests

Retrospective change requests

For a Retrospective change, the Proposed Change Date must be either:

1. The date the Change Request is raised.

2. The date in the past and within the number of days allowed by the Time Frame Rules, Change Reason Code, and NMI Classification Code on the Change Request.
   The maximum number of days is the value stored in Retrospective Days.

Retrospective changes with an end date

If you want to make a Retrospective Change A change to a NMI record that becomes effective on or before the date the Change Request is submitted., applying to a specific period, you must enter a date for the Actual End Date A date specifying the end of a period when updating existing data in CATS. It is only specified in a Change Request for a Retrospective Change correcting a past error., so the change doesn’t overwrite current values.

This scenario describes a common Retrospective Change problem:

1. A NMI with an inactive Datastream is transferred to a New FRMP from 04 April 2002. The NMI is now Tier 2 so you must change the Datastream Status Code from I to A.

2. The MDP activates the Datastream from 01 April 2002. Assuming the NMI’s Start Date was 22 December 2001, the CATS_NMI_DATA_STREAM table look like CATS_NMI_DATA_STREAM table with incorrect data Page 1.

3. The MDP’s Change Request made the original record redundant (MaintActFlg = I) and created two new records to replace it.

4. Realising the error, the MDP creates another Transaction to make the Datastream Status Code Inactive (I) from 01 April 2002 until 03 April 2002.

5. CATS_NMI_DATA_STREAM table with more incorrect data Page 1 displays what happens to the CATS_NMI_DATA_STREAM table once the Change Request completes, if the MDP submitted a Change Request to make the Datastream Status Inactive from 01 April 2002 and NOT put in an ActualEndDate. As you can see, this change does not give the correct result.

6. To fix the problem using the data in CATS_NMI_DATA_STREAM table with incorrect data Page 1, the MDP must submit a Change Request with a ProposedDate of 01 April 2002 and an ActualEndDate of 03 April 2002. This change results in the correct result, see CATS_NMI_DATA_STREAM table with correct data Page 1.

Table 43 CATS_NMI_DATA_STREAM table with incorrect data

NMI	Suffix	Datastream status	Start date	End date	MaintActFlg
1XXXXXXX11	11	I	22-Dec-2001	31 Dec 9999	I
1XXXXXXX11	11	I	22-Dec-2001	31 Mar 2002	A
1XXXXXXX11	11	A	01-Apr-2002	31 Dec 9999	A

Table 44 CATS_NMI_DATA_STREAM table with more incorrect data

NMI	Suffix	Datastream status	Start date	End date	MaintActFlg
1XXXXXXX11	11	I	22-Dec-2001	31 Dec 9999	I
1XXXXXXX11	11	I	22-Dec-2001	31 Mar 2002	A
1XXXXXXX11	11	A	01-Apr-2002	31 Dec 9999	I
1XXXXXXX11	11	I	01-Apr-2002	31 Dec 9999	A

Table 45 CATS_NMI_DATA_STREAM table with correct data

NMI	Suffix	Datastream status	Start date	End date	MaintActFlg
1XXXXXXX11	11	I	22-Dec-2001	31-Dec-9999	I
1XXXXXXX11	11	I	22-Dec-2001	31-Mar-2002	A
1XXXXXXX11	11	A	01-Apr-2002	31-Dec-9999	I
1XXXXXXX11	11	I	01-Apr-2002	03-Apr-9999	A
1XXXXXXX11	11	A	04-Apr-2002	31-Dec-9999	A

 

Prospective change requests

For a Prospective change, the Proposed Change Date must be either:

1. The Day following the date when the Change Request is submitted

2. A date after the Change Request is submitted.

The maximum number of days for a Prospective change depends on the Time Frame Rules As described in the CATS Procedures, the rules allocating the number of business days to the following categories: • Objection Logging Period. • Objection Clearing Period. • Retrospective Period. • Prospective Period., Change Reason Code, and NMI Classification Code A code identifying the type of consumer to which a NMI belongs, e.g. large or small wholesale generators. for the relevant Change Request. The maximum number of days is the value stored in Prospective Days A situation where the number of days under consideration occur after the current date..

Read type code combinations

CR Code		1000		1010	1030	1040, 102X	1023
Read Type Code	Proposed change date	Prospective	Retrospective	Retrospective only	Prospective only	Retrospective only	Retrospective only
EI	Existing interval meter	Type B	Type B	X	Type B	Type B	X
GR	Greenfield NMI	X	X	X	X	X	Type C
PR	Previous read date	X	X	Type A	X	Type A	X
RR	Read required	Type A/Type B	Type B	X	X	X	X
SP	Special read	Type A	X	X	Type A/Type B	X	X
UM	Unmetered connection point	Type D	Type D	Type D	Type D	Type D	Type D

 

Request for data transfer

In the MSATS Web Portal > Transactions > Request for data interface, you can search, view current and historical, and respond to requests for data transfer (RDAT). The records you have access to in this interface are limited to your user rights.

For RDAT scenarios, see, NEM Customer Switching on AEMO’s website.

For Change Retailer CRs (10XX), based on specific scenarios, MSATS sends an RDAT to the MDP to provide the CR1500 for the Actual Change Date.

RDAT issued

If the following scenarios exist, MSATS issues an RDAT and the MDP must issue a CR1500:

• The Transaction is a CR1030 or CR1040.

• The Transaction has a Read Type Code Types of meter readings detailed in the CATS Procedures. of SP Service Provider (could be different to meter data providers). They provide the telemetry data i.e. behind the NMI data from Batteries. (Special Read).

For all other scenarios, MSATS continues to process the CR so the Proposed Change Date becomes the Actual Change Date for the transfer.

Receiving and responding to an RDAT

MDPs receive RDATs in their Participant Outbox. The information is in an XML eXtensible Mark-up Language. message compressed in a zip file and the required data fields have NULL=”TRUE”.

For help, see Guide to MSATS Web Portal.

To respond to an RDAT, in the MSATS Web Portal, click Respond (see Participant data requests Page 1). The Change Request – New screen displays where you select the Change Request type.

The Change Request type depends on the data request. The most common RDAT is to MDPs to provide the Actual Change Date for a Change of Retailer Transaction. The date you supply is normally the Actual Meter Read Date The date an actual meter reading is obtained. (CR1500) or for a new Interval Meter A meter that measures consumption of electricity for each specified interval (usually half-hourly to align with wholesale market trading intervals). It is manually read, or remotely read using a communications network. installation, the date it is National Electricity Rules See Relevant Rules or Procedures (NER National Electricity Rules. The rules made under the National Electricity Law (NEL). They govern the day-to-day operations of the National Electricity Market (NEM) and provide the framework for network regulation.) compliant.

Where a proposed Transfer Future Transfer Submission of Retailer Change Request does not have any register level Metering records or is missing data on an existing NMI record, an RDAT is also sent to the MPB See MP. Before the Transfer of Retailer Change Request can complete, the MPB must submit a CR3001 or CR3000 to create register identifier details for the NMI.

Figure 101 Participant data requests