Technical Guide To MSATS

Technical
Technical Guide
Guide to
to MSATS
MSATS
1.00 Draft December 2020
Version 1.00
Pre-production: Wednesday 16 November
December 2020
2016
Production: Wednesday 19 October 2016
Supplement to the MSATS B2M policies, procedures, and guides providing an
understanding of MSATS functionality and business rules
Important Notice
PURPOSE
This Technical Guide to MSATS, prepared by the Australian Energy Market Operator (AEMO), provides guidance for
pdrMonitor under the National NER or NGR (Rules).
NO RELIANCE OR WARRANTY
This document does not constitute legal or business advice and should not be relied on as a substitute for obtaining
detailed advice about the National Gas or Electricity Law, the Rules or any other applicable laws, procedures, or
policies. While AEMO has made every effort to ensure the quality of the information in this Guide, neither AEMO, nor
any of its employees, agents and consultants make any representation or warranty as to the accuracy, reliability,
completeness, currency or suitability for particular purposes of that information.
LIMITATION OF LIABILITY
To the maximum extent permitted by law, AEMO and its advisers, consultants and other contributors to this Guide (or
their respective associated companies, businesses, partners, directors, officers or employees) are not liable (whether
by reason of negligence or otherwise) for any errors, omissions, defects or misrepresentations in this document, or for
any loss or damage suffered by persons who use or rely on the information in it.
TRADEMARK NOTICES
Microsoft, Windows and SQL Server are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
UNIX is a registered trademark of The Open Group in the US and other countries.
© 2015 Google Inc, used with permission. Google and the Google logo are registered trademarks of Google Inc.
Notepad++ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
DISTRIBUTION
Available to the public.
DOCUMENT IDENTIFICATION
Business custodian: Manager, Metering
IT custodian: Manager, Retail Solutions
Prepared by: AEMO Technology Technical Writers and the Metering Team
Last update: Monday, 14 December 2020 3:08 PM
VERSION HISTORY
1.00 Initial creation
DOCUMENTS MADE OBSOLETE
The release of this document changes the version of Technical Guide to MSATS, and all versions of: Hints and Tips -
Cats & NMI Discovery, MSATS CATS History Model, and Introduction to MSATS.
FEEDBACK
Your feedback is important and helps us improve our services and products. To suggest improvements, please
contact AEMO's Support Hub.
© 2020 Australian Energy Market Operator Limited.

The material in this publication may be used in accordance with the copyright permissions on AEMO’s website.
Contents
Introduction ............................................................................................................................. 6
Purpose ......................................................................................................................................... 6
Audience........................................................................................................................................ 6
Out of scope .................................................................................................................................. 7
What’s in this guide ....................................................................................................................... 7
How to use this guide .................................................................................................................... 8
About MSATS B2M................................................................................................................. 9

What is MSATS B2M? ................................................................................................................... 9
Who can use MSATS B2M?........................................................................................................ 11
B2M roles .................................................................................................................................... 11
How you use MSATS B2M .......................................................................................................... 12
Participant CATS Transactions ............................................................................................ 41

Change requests ......................................................................................................................... 42
Rejection...................................................................................................................................... 70
Notifications ................................................................................................................................. 76
Objections.................................................................................................................................... 82
Request for data transfer ............................................................................................................. 92
NMI discovery .............................................................................................................................. 94
NMI master ................................................................................................................................ 102
AEMO CATS Transactions................................................................................................. 106

Acknowledgement and validation .............................................................................................. 107
Response .................................................................................................................................. 129
Notifications ............................................................................................................................... 137
Request for data transfer ........................................................................................................... 138
Retailer of last resort ................................................................................................................. 138
CATS History Model ........................................................................................................... 139

Why such a complex history model? ......................................................................................... 139
NMI standing data master tables .............................................................................................. 140
How MSATS manages CATS history ........................................................................................ 144
How MSATS updates the NMI master tables ............................................................................ 146
Codes ................................................................................................................................. 169

Codes maintenance .................................................................................................................. 169
Actual/cumulative indicator codes ............................................................................................. 173
Change reason codes ............................................................................................................... 174
Change request status codes.................................................................................................... 176
Customer classification codes ................................................................................................... 177
© AEMO 2020 | Technical Guide to MSATS iii

Customer threshold codes ........................................................................................................ 177
Datastream status codes ........................................................................................................... 178
DLF codes ................................................................................................................................. 179
Embedded network identifier codes .......................................................................................... 180
Error codes ................................................................................................................................ 181
Field validation data source codes ............................................................................................ 182
Jurisdiction codes ...................................................................................................................... 182
Meter register status codes ....................................................................................................... 183
Metering installation type codes ................................................................................................ 183
Network tariff codes ................................................................................................................... 184
NMI classification codes ............................................................................................................ 185
NMI status codes ....................................................................................................................... 185
Objection codes ......................................................................................................................... 185
Read type codes ....................................................................................................................... 186
Register identifier status codes ................................................................................................. 190
Role ID codes ............................................................................................................................ 190
TNI codes .................................................................................................................................. 191
Transaction type codes ............................................................................................................. 192
Unit of measure codes .............................................................................................................. 194
Rules................................................................................................................................... 195
Rules maintenance .................................................................................................................... 195
Change request field validation rules ........................................................................................ 197
Change request initiation rules .................................................................................................. 197
Jurisdictional parameters .......................................................................................................... 198
NMI discovery field access rules ............................................................................................... 199
NMI discovery search key rules ................................................................................................ 199
Change request status notification rules ................................................................................... 200
Objection rules .......................................................................................................................... 200
Standing data access rules ....................................................................................................... 201
Time frame rules ....................................................................................................................... 202
FAQs................................................................................................................................... 203
Transactions .............................................................................................................................. 203
Inbox, Outbox, and Archive ....................................................................................................... 205
NMI search ................................................................................................................................ 207
Terms................................................................................................................................................... 217
NER terms ................................................................................................................................. 217
Needing Help ....................................................................................................................................... 219

Support Hub .............................................................................................................................. 219
© AEMO 2020 | Technical Guide to MSATS iv

Information to provide ................................................................................................................ 219
References .......................................................................................................................................... 220

Australia post ............................................................................................................................. 220
AEMO website ........................................................................................................................... 220
Index ................................................................................................................................................... 223
© AEMO 2020 | Technical Guide to MSATS v

Introduction
Introduction
Purpose
This guide is a supplement to MSATS B2M policies, procedures, and guides providing
an understanding of MSATS functionality and business rules.
Audience
The audience for this guide is:
New participants building their IT systems to interact with AEMO’s.
Registered Participants:
− Creating and receiving participant CATS Transactions.
− Requiring NMI information from MSATS. Especially, the records they can
expect from a NMI Discovery search.
− IT staff involved in managing interfaces with MSATS.
Anyone wanting an understanding of MSATS functionality, business rules, and

roles.
Support staff
© AEMO 2020 | Technical Guide to MSATS 6

Introduction
Out of scope
MSATS Business-to-Business (B2B) and Enterprise Meter Data Management (eMDM)
are out of scope for this guide. For details, see the following information on AEMO’s
website:
Business-to-Business Procedures
Metering procedures, guidelines and processes
What’s in this guide

Chapter 2 About MSATS B2M on page 9 explains B2M, the roles, functionality,
interfaces, and delivery protocols.
Chapter 3 on page 38 describes participant CATS Transactions and guidelines,

including tips and common NMI Discovery search errors.
Chapter 4 AEMO CATS Transactions on page 106 describes AEMO CATS

Transactions.
Chapter 5 CATS History Model on page 139 is essential reading because it assists
understanding of the end-to-end Change Request process and how the CATS NMI
Standing Data Access Rules affect data returned from NMI Discovery or a CATS
report.
Chapter 6 Codes on page 169 specifies the codes applying to Change Requests and
CATS Standing Data.
Chapter 7 Rules on page 195 specifies the rules applying to Change Requests and
CATS Standing Data.
Chapter 8 FAQs on page 203 has a list of commonly asked MSATS questions.
Terms on page 217 has a list of NER terms used throughout this guide and where to
find MSATS terms.

Introduction
Needing Help on page 219 explains how to get help from AEMO’s Support Hub.
References on page 220 has a list of resources mentioned throughout this guide.
How to use this guide

The Retail Electricity Market Procedures – Glossary and Framework forms part
of this guide and should be read with it.
The references listed throughout this document are primary resources and take
precedence over this document.
Where there is a discrepancy between the Rules and information or a term in this
document, the Rules take precedence.
Where there is a discrepancy between the Procedures and information or a term

in this document, the Procedures take precedence.
This guide is written in plain language for easy reading.
Text in this format indicates a reference to a document on AEMO’s website.
Text in this format indicates a link to related information.
Text in this format is an action to complete in the Markets Portal interface.
Glossary Terms are capitalised and have the meanings listed against them in the
Retail Electricity Market Procedures – Glossary and Framework and Guide to
MSATS and B2B Terms.
NER terms are capitalised and have the meaning listed against them in the
National Electricity Rules (NER). Any rules terms not capitalised still have the
same meaning. NER terms are listed on page 217.
References to time are Australian Eastern Standard time (AEST) unless

otherwise specified.

About MSATS B2M
About MSATS
B2M
This chapter explains MSATS B2M functionality, roles, interfaces, and, delivery
protocols.
What is MSATS B2M?

MSATS is an IT system operated by AEMO fulfilling its obligations under the NER. The
functionality available in MSATS B2M includes:
Participant administration and User Rights Management (URM)
Consumer Administration and Transfer Solution (CATS)
Wholesale, Interconnector, Generator and Sample (WIGS)
Enterprise Metering Data Management System (eMDM)
Figure 1 MSATS B2M functionality

About MSATS B2M
Consumer Administration and Transfer

Solution
The Consumer Administration and Transfer Solution (CATS) is based on 14 types of
Transactions plus a separate RoLR function. Six Transaction types are initiated by
participants with 8 initiated by MSATS.
The 2 most significant participant Transactions are Change Requests and NMI
Discovery Search. For details, see Participant CATS Transactions on page 38.
The most significant AEMO Transaction is the RoLR functionality. For details, see
AEMO CATS Transactions on page 106
Wholesale, Interconnector, Generator

and Sample
The Wholesale, Interconnector, Generator and Sample (WIGS) govern the transfer of
consumer settlements, the registration of metering installation, and the management of
Standing Data for NMIs, classified as wholesale, interconnector, generator, or sample.
Enterprise Metering Data Management

System
The Enterprise Metering Data Management System (eMDM) includes the Profile
Preparation Service, Consumption Meter Profiling, and Data Aggregation. For details
about eMDM, see Metering procedures, guidelines, and processes on AEMO’s website.

About MSATS B2M
Who can use MSATS B2M?

Registered Participants, Energy Ombudsman, and AEMO have access to the
information in the system according to the National Electricity Rules (NER).
B2M roles
Participant B2M roles include:
Embedded Network Managers (ENM)
Financially Responsible Market Participant (FRMP)
Local Network Service Provider (LNSP)
Local Retailer (LR)
Metering Coordinator (MC or RP in MSATS)
Metering Provider - Maintenance (MPB)
Metering Provider – Data Collection (MPC)
Metering Data Providers (MDP)
Network Service Provider (NSP)
Second Network Service Provider (NSP2)

About MSATS B2M
How you use MSATS B2M

This section describes the MSATS B2M functionality, the B2M participant interfaces you
can use to interact with it, and where to find more information.
For details about set up and access to AEMO's participant interfaces, see:
Connecting to AEMO’s Electricity IT Systems
Guide to Electricity Information Systems
Delivery protocols
You change your message delivery protocol in the MSATS Web Portal > Participants >
Participant Schema interface.
Protocol Delivery
API Pull Participant API Gateway
MSATS Web Portal > Data Load Import > Participant Hub Queue > Click the File Name or
Download in the Action column.
API Participant API Gateway

Push

About MSATS B2M
Protocol Delivery
FTP Participant File Server > Participant ID > Outbox
Web MSATS Web Portal > Data Load Import > Participant Outbox

About MSATS B2M
B2M functionality, interfaces, and protocols

Functionality Description Interface / Delivery protocol Reference
e-Hub File File Web

(API) Interface upload portal
(FTP) (web) (web)
Administration Participant administrators (PAs) set up and     User rights access on page 18
maintain Participant User Rights
Guide to User Rights Management >
Participant Users with access rights can view Administration
Codes, Rules, and the System Calendar
Codes on page 169
System calendar on page 169
Rules on page 195
- Participant Inbox
Messages –     Participant File Server on page 20
Transactions, acks - MDP (MTRD & MDMT) file upload
Acknowledgement on page 107
& zips
- Participant Outbox
MDM File Format and Load Process
- Participant Archives
Guide to MSATS Web Portal > Data Load
- Participant Hub Queue: view Import
unacknowledged API Pull and MDMT
Guide to NEM Retail B2M APIs
messages
- Dayzip download: zip and save files in
your Participant Archive

About MSATS B2M
e-Hub File File Web

(FTP) (web) (web)
Metering data Metering (Datastream) Data MDMF or MDFF     Guide to eMDM (in progress)
search
Guide to MSATS Web Portal
NMI information NMI Discovery search for NMIs and their     NMI Discovery and NMI Master on pages 92
associated relationships with participants & 102
Guide to NEM Retail B2M APIs >
- getNMIDetail
- NMIDiscovery
Ombudsman (NMI Ombudsmen access to NMI Standing Data     MSATS Ombudsman Enquiry User Interface
enquiry reports) Guide
Participants reports on ombudsman
enquiries
Passwords Participant ID and Participant User     Guide to Electricity Information Systems >
password(s) Participant ID password
Changing a password in MSATS changes Guide to User Rights Management >
the password for NEM, GSH, OPDMS, and Participant User password
NOS systems

About MSATS B2M
e-Hub File File Web

(FTP) (web) (web)
- View participant information

Participant     Guide to MSATS Web Portal > FTP System
information - Manage participant contacts for Demand Status
Side Participation, Settlement Statements,
Guide to Transition of aseXML
and Market Direct notifications
- Manage your B2M aseXML schema
Profile preparation Metering Data Management (eMDM)     Guide to eMDM (in progress)
(profile information) functions such as estimation and profiling
- Next scheduled read date change request

Queue Monitoring     Guide to MSATS Web Portal > Reports &
daily count
Alerts > Queue Monitoring
- Report scheduler queue: count of pending
reports
getQueueMetaData
- Outbound notifications queue: Change
Request Notification daily estimate
- Change request queue: Change Request
daily estimate
Reports and alerts CATS and MDM reports     Guide to MSATS Reports
Report output is File Interface or API e-Hub Guide to NEM Retail B2M APIs >
only generateC4Report

About MSATS B2M
e-Hub File File Web

(FTP) (web) (web)
Settlement data View Settlement data     Guide to MSATS Web Portal > Settlement
Data
- B2M message exchange between MSATS

Transactions     Participant CATS Transactions on page 38
and participant systems
Change Requests Validation on page 107
- Connection Point transfers and Standing
Objections Data management Guide to MSATS Reports
Notifications All files exchanged with MSATS B2M Guide to NEM Retail B2M APIs >
conform to the Australian Standard for
Requests for data - submitMessages
Energy XML (aseXML)
- submitMessageAcknowledgements
Guide to MSATS Web Portal > Transactions
aseXML Standards on AEMO's website
Transaction limits Imposed on participant interaction with     Transaction limits on page 121
MSATS to prevent overload of the system
Guide to MSATS Web Portal > Participants >
View status of participant Transaction limits FTP System Status
- getMSATSLimits
- getAlerts
- getParticipantSystemStatus

About MSATS B2M
aseXML schemas
B2B schema
You change your B2B aseXML schema in the B2B Browser > Transforms and Protocol
interface.
B2M schema
You change your B2M aseXML schema in the Participants > Participant Schema
interface.
User rights access

To access MSATS functionality, Participant Users must have the appropriate user rights
access. A Participant User who can perform Transactions using the Web Portal or API,
cannot necessarily perform the same Transactions using the File Interface.
Your company’s Participant Administrator (PA) gives you access using the Interactive
(web) or Batch entities in the MSATS
Administration menu and provides you
with your access details. Your access
Because it can take 24 hours to update
right determines the interface,
in AEMO’s systems, AEMO
functionalities, and Transactions you can recommends Participant User rights for
use. web and API are set up at least 24
hours in advance.
If a Participant User is logged in when
receiving a new right, they need to
logout and login again.

About MSATS B2M
Table 1 Entity types for each interface
Interface Entity
API Interactive
File (Batch) Batch
File upload (web portal) Interactive
MSATS web portal Interactive
The initial PA is set up by the AEMO system administrator as part of the registration
process. If you don't know who your company's PA is contact AEMO's Support Hub.
The Guide to User Rights Management provides details about:
Providing access to MSATS functionality for Participant Users.
Creating and maintaining Participant ID and Participant User passwords.
Interfaces
API e-hub
Participants can submit and receive CATS Transactions and change their Participant
User password using the API Gateway. For details, see:
Guide to NEM Retail B2M APIs
Guide to AEMO’s e-Hub APIs

About MSATS B2M
Figure 2 Participant API gateway to AEMO e-Hub
API Portal API Gateway

Registration API submission
SSL certificates over MarketNet or
API keys internet
Swagger (OAS) Files
API examples
Participant
API Gateway
Participant file server
CATS Transactions between participants and the MSATS Web Portal or File Interface
are stored in the Participant File Server in two folders:
INBOX: Participants put files for MSATS in the Inbox (see Figure 3 on page 21).
Participants can place aseXML messages in zip format directly to their

Participant File Server Inbox.
OUTBOX: MSATS puts aseXML messages in the Outbox (see Figure 4 on page
22).

About MSATS B2M
MSATS web portal
Participants can submit and receive CATS Transactions in the MSATS Web Portal
interface. This interface is mostly used by participants having a limited number of files to
process. For help, see Guide to MSATS Web Portal.
Participant file server inbox to MSATS web portal
Figure 3 Participant file server inbox to MSATS web portal
MSATS

About MSATS B2M
Participant file server outbox to MSATS web portal
Figure 4 Participant file server outbox to MSATS web portal
Web Portal
Participant File Server via Web Portal (Interactive Batch
MSATS
Participant File Server via FTP
MSATS web portal file upload
Participants can upload Batch CATS Transactions using the Data Load Import >
Participant Inbox > Upload function. This is called Batch to Web Portal or Interactive
Loading). For help, see Guide to MSATS Web Portal.
Uploading Transactions using this option, places them in your Participant Inbox on the
Participant File Server (see Figure 5 on page 23).
When MSATS completes validation, you receive a response Transaction zip file. If the
data loaded successfully, the acknowledgement details are found within the
<Acknowledgements> element, towards the end of the XML file. There is only one
message acknowledgement per file. Depending on the number of transactions in the file,
there can be multiple Transaction Acknowledgements. For details, see MSATS to
participant on page 107.

About MSATS B2M
For details about how to clean up left-over files if they are not acknowledged
immediately, see Acknowledgement on page 115.
Figure 5 MSATS web portal file upload

About MSATS B2M
File interface (FTP)
Participants can submit and receive CATS Transactions using FTP to the Participant
File Server. This is called Batch to Participant File Server or Direct Loading.
This interface is mostly used by participants with many files to process by implementing
an automated Batch File Interface. For help, see Guide to MSATS Participant Batcher
software.
All communications use aseXML-formatted messages. When MSATS processes

Transactions using the File Interface, they undergo the same validity checks as those
processed using the MSATS Web Portal.
You place the Batch files in your Participant Inbox on the Participant File Server by 1 of
the following methods:
FTP software. For help, see Participant File Server on page 20.
Using a back-end process such as MSATS Participant Batcher Software to

automate the FTP loading. Use this option if you have a lot of files to process.
Direct Loading is a two-stage process. You or your IT system write a TMP file to your
Participant Inbox and then rename it to a zip file. You do not directly copy the zip file.
For help, see Creating and submitting batch transactions on page 29.
File interface rules
To create a Change Request using the File Interface, you must adhere to the following
rules:
The Participant User ID in the header’s SecurityContext element must belong to

the From Participant ID.
The Participant User ID in the header’s SecurityContext element in the XML

message must have access rights to submit Batch Transactions (the Batch entity
for Change Requests or Change Withdrawal).

About MSATS B2M
If the Batch Transaction is submitted using the Web Portal, the Participant User
ID submitting the Transaction must have the Participant Mailbox entity right.
If the Batch Transaction is submitted using the Web Portal, the nominated
Participant ID in the From element in the XML file must be the same as the
logged on Participant User ID.
File name format
The file name has four sections:
Section Description Size
Transaction For NMI Discovery, the transaction group is NMID 4

Group Alphanumeric
For CATS transactions, the transaction group is CATS
Priority h = High 1 Character

m = Medium
l = Low
Messages within each priority group are processed in last modified
order
The priority for NMI Discovery is high (h)
The priority for CATS transactions is medium (m)
Unique ID A unique participant-generated identifier for the file. Possibly the 30

Participant ID. Alphanumeric
Extension The zip includes the xml file 3 characters
Example <TransactionGroup><Priority>_<uniqueId>.extension n/a

NMIDH_partID_1009.xml
CATS_partID_1010.xml
catsm_<Participantid>batch_<uniqueId>.zip
catsm_<Participantid>_<uniqueId>.zip

About MSATS B2M
Transaction format
The information in this section is a guide only. For help creating an aseXML file, see the
aseXML Guidelines.
Table 2 below explains the information required for each Transaction.
For examples, see:
Change Request: Figure 6 on page 28.
Objection: Figure 7 on page 28.
Table 2 Transaction format
Field Format Transaction
Participant Name Up to 30 characters CR

Enter in quotes between the <From description>PART
LNSP</From description> element
Participant ID Up to 15 characters CR
Must be CAPITALISED
Enter in quotes between the <From>SOLARISP</From> element
Message YYYY-MM-DDTHH:MM:SS.sss CR
Date/Time
Transaction Group 4 characters CR

Must be CAPITALISED
Priority Up to 6 characters CR
Must be upper case
Options: High (H), Medium (M), or Low (L)
Security Context A Participant User ID belonging to the participant ID having a CR

right to perform Batch Transactions
(User ID)

About MSATS B2M
Field Format Transaction
Participant 21 Alphanumeric characters CR

Transaction ID
Change Reason 4 Numbers CR

Code
Role ID 4 Characters OBJ
Objection Code Up to 8 Characters OBJ
Role Up to 4 Characters OBJ
Proposed Date YYYYMMDD CR
NMI Checksum 1 Number CR
NMI 10 Alphanumeric characters CR

About MSATS B2M
Figure 6 Change request XML file
Figure 7 Objection XML file

About MSATS B2M
Creating and submitting batch transactions
All Transaction files are created in the same way although the data required differs
depending on the type of Transaction you are creating. For an example of a Change
Request Transaction, see Figure 6 on page 28.
You can include more than one transaction in one XML file providing they belong to the
same Transaction Group. The message consists of a header, followed by the
transactions. For details, see aseXML Guidelines.
To submit Batch files to the Participant File Server:
Create an XML file according to the aseXML specification.
Compress the file in zip format and save it with a .TMP extension, following the
MSATS filename standards. For details, see file name format on page 25.
FTP the .TMP file to your Participant Inbox adhering to file size limits.
Rename the file from TMP to zip.
MSATS performs validation and sends an ACK file to your Participant Outbox,
either accepting or rejecting the file.
The ACK file has the same name as the zip file except for the extension. For
example. if your file is catsm_12345.zip. MSATS names the ACK file
catsm_12345.ACK.
When you receive the matching .ACK file in your Participant Outbox, delete your
original zip file from your Participant Inbox.
MSATS then deletes the ACK file from your Participant Outbox.
The Inbox and Outbox are now empty.
This process (from step 1) is called the MSATS Hokey-Pokey Protocol.

When MSATS completes validation, you receive a response Transaction zip file.
For details, see MSATS to participant on page 107.

About MSATS B2M
Editing a batch change request
The process for editing a Change Request using Batch is almost identical to creating a
Change Request. A new Change Request Transaction is submitted, which contains the
correct information including one additional data element. This is the request ID of the
original Change Request in the <InitiatingRequestID> element (see Figure 8 on page
31).
When you submit the second Change Request, MSATS does the following:
1. Creates a new Change Request with the status of PVAL (pending validation).
2. Determines, during the second-level validation, that this is an edit to an existing

Change Request.
3. Cancels the existing Change Request (its status changes to CAN).
4. Creates a further new Change Request that is a ‘merging’ of the two Change
Requests that has a status or REQ. (This is the Change Request that proceeds).
5. Cancels the first Change Request.

About MSATS B2M
Figure 8 edited change request
For Change Requests edited using Batch, MSATS sends two Change Request
Response (CRR) Transactions:
1. One for the submitted Change Request providing the correct information.
2. One for the final new Change Request MSATS creates to merge the original
Change Request and the new one.
If there was a problem with the first Change Request because it failed the second-level
validations and was rejected; only the first Change Request response is received.

About MSATS B2M
Withdrawing a batch change request
To withdraw a Change Request using Batch, you must submit a message containing a
change withdrawal Transaction. The only element supplied is the <RequestID> element
(see Figure 9 below).
The Initiating participant must create the Change Request withdrawal and the user ID
identified in the <SecurityContext> element must have the right to submit a change
withdrawal Transaction by Batch.
For Change Requests withdrawn using Batch, MSATS sends a Change Request
response (CRR) indicating if the withdrawal was successful. The CRR is identical to the
CRR received when you submitted the Change Request. It does not indicate it is a
response to a Change Request withdrawal rather than a response to a new Change
Request. You can identify it by initiatingTransactionID, also used in the withdrawal
Transaction. The Request ID is the same as the initial Change Request.
Figure 9 Change request withdrawal

About MSATS B2M
Withdrawing a batch objection
The process for withdrawing an Objection using Batch is almost the same as creating an
Objection using the Batch Handlers. For a successful withdrawal, the <ObjectionID>
generated in the initial Objection is included in the file. A Batch Handler withdrawal is
acknowledged by an Objection withdrawal Transaction in your Participant Outbox.
For Objections withdrawn using the Batch Handlers, MSATS sends an Objection
Transaction file indicate if the withdrawal was successful. It is identical to the Objection
Transaction received when you submitted the Objection. The Transaction does not state
it is a response to an Objection withdrawal rather than a response to a new Objection. It
contains the initiatingTransactionID from the initial withdrawal Transaction. The
Objection ID is the same as the one being withdrawn.
To log an Objection withdrawal:
Create an XML file according to the current aseXML schema format and include
the following element:
Element Description Example
<ObjectionID> The ObjectionID from the initial <ObjectionID>76543210</ObjectionID>

CRR
2. Name the file according to AEMO specifications and compress the file into a zip
format.
3. Access your Participant Inbox and upload your file.
4. To view the response, access your Participant Outbox.
Figure 10 on page 34 is an example of an aseXML file for withdrawing Objections. The

<Header> information provided is the same as the standard for a CATS medium
Transaction. However, in the Transactions section of the file, there is a CATS Objection
withdrawal Transaction.

About MSATS B2M
These fields are:
<ObjectionID>: The ID generated when the original Objection was logged.
<InitiatingRequestID>: The Change Request ID the Objection was logged

against.
<Role>: The role the Objection was logged for.
<ObjectionCode>: The Objection code used by the Objection.
Figure 10 Withdrawing objection aseXML file

About MSATS B2M
NMI discovery type 1
To create a NMI Discovery request:
Create an XML file according to

the current aseXML schema
format. The data required differs
depending on the search criteria You can include multiple Transactions
entered (such as, Address, Meter in a single Batch file. Requests are
Serial ID or DPID). To perform a processed individually and MSATS
successful NMI Discovery search provides a single response per
using Batch, your XML file must Transaction.
contain one of the following
criteria:
− Delivery point identifier

− Meter serial number
− Physical address
2. Name the file according to AEMO specifications. The filename consists of the
Transaction Group, Priority Level, and a Transaction ID that starts with the
participant ID. Save files with an XML extension and must be in lower case.
format.
NMI discovery type 2 (obtain standing data)
To create a NMI Discovery type 2 (Obtain Standing Data) request:
1. Create an XML file according to the current aseXML schema format. The NMI
and the checksum are required for a type 2 search.
format.

About MSATS B2M
NMI Discovery type 3 (Obtain Role Data)
To create a NMI Discovery type 3 (Obtain Role Data) request:
Create an XML file according to the current aseXML schema format with a
standard NMI Discovery request header.
The Type, NMI checksum, and Reason fields are mandatory. Enter NMID for the
Transaction Group.
2. Enter ROLE_REQUEST for the Type.
format.
Notes:
Correct Retailer: The Retailer listed as the FRMP for the NMI in MSATS. They
are the End-use Customer’s chosen Retailer.
Current Retailer or current FRMP: The Retailer who is currently listed with an
active role of FRMP for a NMI in MSATS.
Most recent previous Retailer: The Retailer who was the FRMP before the NMI
was transferred to the party listed as the current FRMP in MSATS.
Creating a report request
You can also request CATS and MDM reports using Batch. When a report is processed
using Batch, it undergoes the same validity checks as a report processed using the web
portal.
All reports, whether requested using the web portal or using Batch, are delivered as zip
files placed in your Participant Outbox.

About MSATS B2M
To create a report request:
Create an XML file containing the report request according to the aseXML
schema format. Each report requires a different set of parameters; the easiest
way to identify the parameters for each report is to request it using the web portal
and check the output.
2. Name the file according to AEMO specifications: The filename consists of the
Transaction Group (CATS), Priority Level (M), and the Transaction ID (unique ID
that includes the participant ID). Files must be saved with an XML extension and
are usually in lower case, for example, catsm_ppppppp_1000.xml (see page 25).
3. Compress the file into a zip format.
Batch FTP system status
To create an FTP System Status request:
1. Create an XML file with the report request according to the aseXML schema
format. Each report requires different parameters. The easiest way to identify the
parameters for each report is to request it using the web portal and check the
output.
2. Name the file according to AEMO specifications: The filename consists of the
Transaction Group (CATS), Priority Level (M), and the Transaction ID (unique ID
that includes the participant ID). Files must be saved with an XML extension and
are usually in lower case, for example, catsm_ppppppp_1000.xml (see page 25).
3. Compress the file into a zip format.

About MSATS B2M
Set participant
Providing you have permission to do so, the Set Participant function in the web portal
allows you to act for another Participant ID without having to log out, change IDs and log
in again. The participant you are acting for displays at the top of the Markets Portal
interface. For permission to see other participant IDs using Set Participant, see your
company's Participant Administrator.
Bulk transactions
Bulk data tool (BDT)
The Bulk Data Tool (BDT) enables participants to insert and update large quantities of
MSATS Standing Data. It has minimal impact on MSATS because it bypasses the
Change Request process, including Objections and Notifications, and the MSATS
history model.
The BDT is useful for:
Mass correction of existing data.
Provision of new NMIs for Jurisdictions rolling out Full Retail Competition (FRC).
Updates to existing records made using the BDT:
Are only made to the current active records (records having an end date of
31/12/9999). No active historic records are ever affected by the BDT.
Do not conform to the CATS History model so there is no history audit trail of the
replaced data. The only indication that an existing record is updated by the BDT
is the MAINTUPDTID field is populated with BDT_ParticipantID, for example
BDT_ACTEWNGY. The record’s MAINTCREATEDT and MAINTUPDTDT are
not affected.

About MSATS B2M
All new records are created with a Start Date equal to the date prior to the date when the
BDT was run and have a MAINTUPDTID value of BDT_ParticipantID. The
MAINTCREATEDT for new records is the processing date and time.
The only records suitable for update by the BDT are ones associated with NMIs where:
All participants attached to the NMI are related at the time the update is
processed.
The NMI is Tier 1 at the time the update is processed.
The past Settlement runs are not affected (the proposed data cannot replace
existing data used in a Settlement run). For example, it is not possible to update
the DLF or TNI code for any NMI, if for any of the period covered by the Start and
End Date on the NMI record, there were active Datastream records.
Who can use BDT
The allowed Roles for updating data using the BDT is based on the same rules
governing Change Requests (a combination of the Change Reason Initiation Rules and
the Change Request Field Validation Rules).
While an LNSP can create a NMI, all associated Metering Installation (including register
identifiers) and Datastream data, if subsequent data changes are required or if additional
Metering Installation and Datastream records need creation, an authorised participant
must submit them (such as, the MPB for Metering Installation data and the MDP for
Datastreams).

About MSATS B2M
Operation
AEMO operates the BDT upon receipt of a request for update and a data file from
participants. This is different from the Change Request process where participants
control the change.
For more BDT operation details, see

To request a BDT update:
Technical Guide to Bulk Data Tool in
MSATS.
1. Place an aseXML file with the
standing data updates or inserts
in your Participant Inbox.
2. MSATS generates an acknowledgement file.
3. When MSATS processes your file, it places a response file in your Participant
Outbox.

Participant CATS Transactions
Participant
CATS Transactions
This chapter describes participant CATS Transactions and guidelines for using them,
including tips and common NMI Discovery search errors.
CATS allows participants to administer and transfer End-use Customer’s Connection

Points and their NMI information between participants. Creating and updating
information about NMIs involves 4 types of Transactions:
Change Requests (on page 42
Notifications (on page 70)
Objections (on page 82)
Requests for Data Transfer (on page 92)
CATS also includes NMI Standing Data Management:
NMI Discovery (on page 94)
NMI Master (on page 102)
Report Requests (see Guide to MSATS Reports)

Change requests
The most significant Transaction is the Change Request used by participants to submit
or update CATS Standing Data.
Participants use Change Requests to interact with MSATS for some or all aspects of
information regarding a Consumer’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.
Standing details required to support:

− The Profile Preparation Service (PPS)
− Basic Meter Profiler (BMP)
− Data Aggregation
− Settlement.
− NMI Discovery.
− Metering Register with metering installation data.
The Transaction types required to create and manage Change Requests are:
Change request
Change withdrawal
Objection
Objection withdrawal

Change request rules

A Change Request:
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 message format, capable of accommodating more

than one Change Request. For details, see aseXML Guidelines on AEMO’s
website.
Can only be assigned one DLF Code.
Is Initiated for an event using one of the Change Reason Codes on page 174.
Has a set of CATS Standing Data items varying with the selected Change
Reason Code.
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). The completion of a
Change Request and the formation of a NMI Master Record occur simultaneously.

The basic life cycle is:
1 Initiating participant
• Creates the Change Request specifying the data to change

and when
2 MSATS
• Notifies other involved parties of the change details
3 Involved parties
• Can submit an Objection, otherwise the Change Request

progresses
4 MSATS
• If an objection occurs, MSATS notifies involved parties,

including the Initiator, according to the Change Request
Status Notification Rules
5 Objecting party
• Can withdraw it before a specified number of days and the

Change Request completes
6 MSATS
• If parties do not withdraw, after the Objection period

passes, MSATS cancels the Change Request

Change request status

Table 3 Change request statuses
Code Description Notes
PVAL Pending The Transaction passed Checksum Validation.

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:
Selects the Transaction Type

Code CR.
Participant can withdraw a Change
Request until the Change Request is in
Selects the Change Reason Completed status.
Code most appropriately relating
to the relevant event (see page
174).
Populates the Change Request with the data permitted by the selected Change
Reason Code.
Submits the Change Request to MSATS, using one of the B2M interfaces.
Pending validation status (PVAL)
PVAL:
Commences when the Change Request passes initial MSATS validation.
Finalises after the Change Request has either:
a. Accepted: All required data is submitted.
b. Rejected: Data is missing or inaccurate.
Rejected status (REJ)
The Rejected (REJ) status occurs when a Change Request fails validation, either:
In Pending Validation status.
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 status occurs when a Transaction is validated, for example:
There is no missing data.
The Objection Logging Period and Objection Clearing Periods are over.
Objected status (OBJ)
The Objected status occurs when one or more Objections are received:
Event notifications are sent to the relevant parties with details of the Objections.
The status changes to:
a. Requested: When the last Objection is withdrawn, and the Objection

Logging Period has not expired.
b. Pending: When the last Objection is withdrawn, and the Objection Logging
Period has expired.
c. 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 status:
Occurs when no Objections are received, or all Objections are withdrawn, and
the Objection period passes.
Remains while any required data remains outstanding, or an Objection, not

subject to the Objection Logging Period is not raised.
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:
Is Pending, the Proposed Change Date is reached, and all required data is
present.
Is Objected, if:
a. No Objections are received, the Objection Logging Period has ended, and
an Actual Change Date exists.
b. Objections are received, all Objections are withdrawn, the Objection Logging
Period has ended, and an Actual Change Date exists.
Is simultaneous with the formation of a NMI Master Record and is effective from
the Actual Change Date.
Cancelled status (CAN)
The Cancelled status occurs when:
1. The initiator of the Change Request withdraws the Transaction
2. MSATS cancels the Change Request because:
a. Not all Objections are withdrawn at expiry of the Objection Clearing Period.
b. It is in Pending status longer than seven months from the date of initiation.
c. A Type 2 Concurrent Transfer scenario applies.

Change request role status

The status of each Role on the NMI Master Record is classified as Current. 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 Figure 11 on page 51, depending on the Change Reason
Code used (see page 174), there are five categories of information (see page 102):
Participant Role Relationships
NMI Standing Data
NMI Datastream
NMI Meter Register
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 52).

A change request is not complete until all conditions are met:
The Proposed Date has passed.
The Objection Period has passed.
It does not have any active objections.
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.
Figure 11 Generic web portal change request steps

Change request errors

Table 4 below 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 Table 4.
Table 4 does not include errors

received from a NMI Discovery
For more details about error codes, see
Search. If you receive an error
page 181.
that is not in Table 4 and require
help, please contact the Support
Hub (see details on page 219).
Table 4 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:
1. Return to the main screen
2. To change the data, click Edit
1101 Data fields provided are not valid Check the allowed fields have a Field Validation Data
for this Change Request Source Code of RA or RQ (see page 182)
To confirm allowed fields, check the Change Request
Field Validation Rules on page 197
Alternatively, check you entered a valid Change
Reason Code (see page 174)
1100 Invalid data on Change Request Check you entered a valid Embedded Network Code
Identifier (CATS_EMB_NET_ID_CODES table)
See page 179

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 185)
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. Check for a valid TNI Code (CATS_TNI_CODES table)
DLF Code) 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:
1. They are not valid for that Role
2. They were not valid for that Role for the period
covered by the Change Request
3. The Participant ID you entered is not valid
4. The name you entered is not in UPPER CASE
See Role ID Codes (CATS_PARTICIPANT_ROLES
table) on page 190
1121 The participant is not valid for the Check if the participant you nominated is valid for the
given Role Role.
See Role ID Codes (CATS_PARTICIPANT_ROLES
table) on page 190
1122 TNI Code required for the NMI (or Check if the Proposed Change Date is prior to the Start
similar) 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 Check if you tried to make a Retrospective Change and
NMI Master Record supplied an End Date prior to the Start Date of the NMI

The End Date must be the Day before, on, or after, the
1134 Date period causes a gap in the
Start Date
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 174)
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 Check the Meter Serial ID you are updating the Next
Meter 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 Check you are not creating a record without specifying
must exist for Meter a Metering Installation Type Code, see page 183
Check you are updating a valid Meter Serial ID
If invalid, create the record using CR 3001 or CR 3000,
see page 174
1148 Invalid Profile Name for NMI's Check you assigned a valid Profile Name to a
Jurisdiction Datastream in the Jurisdiction where this NMI is
located
1149 ADL must be less or equal to 2000 Check if you are changing the Average Daily Load
for NMIs with NMI Classification (ADL) on a NMI having a NMI Classification Code of
Code of SMALL SMALL and your value is greater than or equal to
2000, see page 185
MSATS has a validation designed to ensure ADLs are
reasonable
1151 Not all required fields have been Check you completed all required fields for the
entered. Please ensure all fields selected Change Reason Code, see page 197
have been completed
You must supply all fields on a Change Request where
the Field Validation Data Source Code is RI, see page
182

1150 Initiating Participant is not an The participant submitting the Change Request is not
active CATS Participant active for the period of the Transaction
152 Initiating Participant is not a valid Check if you tried to initiate a Transaction where you
initiator of the Transaction. are not a valid Initiator
If this is a Change Request initiated by a Current Role
(e.g. CR 4001), check:
1. You are the valid participant for the Role for the
period covered by this Change Request
2. 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
3. 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:
1. The Participant ID can act in the specified Role
2. The proposed participant for this Role goes back
as far as the Proposed Change Date on the
Change Request
3. 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 Check if you are trying to change an existing Change
original Change Request 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 Check the NMI is valid
match
1157 Original Change Request is not Check you supplied a valid ID on a Change Request
found or is not active
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 Check the Proposed Change Date is not too far in the
number of days. 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 202
1168 No Jurisdictional Rules found for Check the Change Request you are creating is valid for
Change Request, NMI the NMI’s Jurisdiction and NMI Classification Code
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 198
1169 Date submitted should not be in Check the Prospective Change Date, you can enter
the past for this type of Change tomorrow’s date at the earliest
Request
1172 Metering Installation Type Code Check if you are submitting a Prospective Change for a
does not exist 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 Check if you are using one of the Change Reason
already exists 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 Check you are using one of the Change Reason
not exist. Codes used to create NMIs: CR 2000, CR 2001, CR
2020, CR 2021, CR 2500, CR 2501, CR 2520 and CR
For example: NMI: 1000999900
2521
CR 1000
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 must Check the Meter Register Status Code is valid for the
be either C, R or D Change Request, see page 183
1280 No participant exists from whom Check if the NMI exists in MSATS
data is to be requested for this
You entered a Change Reason Code having some RQ
NMI
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 Your Change Request is cancelled because there is a
Change Request conflict with concurrent transfer (for details, see the MSATS
another CR 1000 series Change Procedures: CATS Procedure Principles and
Request in the system 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 Your Change Request is rejected because there is a
Change Request conflict with concurrent transfer (for details, see the MSATS
another CR 1000 series Change Procedures: CATS Procedure Principles and
Request in the system 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 MSATS has automatically Cancelled your Change
cancelled Request because it remained incomplete longer than 7
months
5036 Invalid combination of Change Check if your transfer request has an invalid Change
Reason Code for Read Type Code 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 Check if you have nominated the Roles you want to
at least one of New MDP, MPB or update
MPC
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 Check if you are changing the LR on a Child NMI not
the FRMP of the Parent NMI matching the Participant ID assigned as the Parent
FRMP

5044 The minimum mandatory data Check you provided all mandatory data
must be populated
5045 The Change Request initiator must You are not the Current Participant assigned to the
be a Current Participant Role required to submit this Change Request
5046 The Change Request must only be Check if you are submitting a Change Request for a
used on NMIs in the status of NMI with an invalid NMI Status Code
<status>
5059 MDM Contributory Suffix is You did not provide the MDM Contributory Suffix in the
mandatory 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 You tried to create a NMI when there is no NMI range
Participant ID assigned to you
5121 NMI falls within an excluded NMI You tried to create a NMI from an excluded NMI range.
range
5122 Proposed NMI is outside the You tried to create a NMI outside the allocated NMI
allocated NMI range for the range for your Participant ID.
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 To remove a Meter, check the Meter Register Status
used to remove at least one Meter Code is C or D
with a Meter Register Status Code
of current or remotely
disconnected

5051 The Change Request must be To create a Meter, check the Meter Register Status
used to create at least one Meter Code is C
with a Meter Register Status Code
of current
5052 The Change Request must be To remove a Register ID, check the Meter Register
used to remove at least one Status Code is C
Register ID with a Meter Register
status code of current
5053 The Change Request must be To create a Register ID, check the Meter Register
used to create at least one Status Code is C
Register ID with a Meter Register
Status Code of current
5054 The Change Request must be To make a Datastream inactive (I), check the
used to deactivate at least one Datastream Status Code is A
Datastream with an existing
Datastream Status Code of active
5055 The Change Request must be To create a Datastream, check the Datastream Status
used to create at least one Code is A
Datastream with a Datastream
Status Code of active

Actual change date

The change is effective from the Actual Change Date. A Change Request Initiated to
create a NMI uses the Proposed Change Date 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 ends.
If MSATS receives an Objection it completes the Day after all Objections are withdrawn,
the Objection Logging Period has ended, and an Actual Change Date exists.
Change of retailer
MSATS does not notify the LR at the time a change of FRMP occurs.
Standing data requirements for a Tier 2 Site
If a retail transfer Change Request is complete and an End-use Customer has

transferred to a second tier Retailer (such as, the FRMP is not equal to the LR):
The LNSP or the ENM in the case of Child Connection Points, must ensure the
NMI Status Code 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 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 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.
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, applying to a specific period, you must
enter a date for the ActualEndDate, 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
Table 5 on page 63.

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. Table 6 below 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 Table 5 below, 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 Table 7 on page 64.
Table 5 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 6 CATS_NMI_DATA_STREAM table with more incorrect data
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 7 CATS_NMI_DATA_STREAM table with correct data
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, Change Reason Code, and NMI Classification Code for the relevant Change
Request. The maximum number of days is the value stored in Prospective Days.

Change request withdrawal

The Initiating participant can Cancel (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.
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 Table 8 on page 66),
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 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 8 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
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.
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:
Find the Change Request.
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:
Creates a new Change Request (with a new Request ID) containing:
a. Data in the original Change Request.
b. 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
To edit a Change Request submitted by API or Batch:
Withdraw the initial change request.
Submit a new change request.
For more details about editing a Batch

Change Request, see page 30.

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, 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.
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 is not a valid initiator of the

Transaction.
Attempting to create a NMI already existing
Change Requests are missing mandatory field data.
When you submit a Change Request:
It goes through several validations (like the MSATS Web Portal validations when
you click Submit) to check if it is valid.
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 92.

Rejection avoidance
How to avoid rejected Transactions:
Ensure Change Request Field Validation Rules are applied (see page 197).
In a Change Request, only include fields having a Field Validation Data Source
Code of RI or OI.
Complete all mandatory fields (RI fields).
Ensure you are a valid Initiator of a Transaction from at least the Proposed
Change Date on the Change Request. Valid Initiators are:
− Current Role: 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 2001 or CR 2500) if
the NMI is not already in MSATS.
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 and no Meter Register Status Code.
Ensure the Proposed Change Date for a Transaction is within the allowable
number of days:
− For a Retrospective Change, it must be between today and no further into
the past than the Retrospective Period for the relevant Change Request.
− For a Prospective Change, it must be between tomorrow and no further into
the future than the Prospective Period 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 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.
− 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
to obtain:
The Request and Transaction ID from the

CATS_OUTBOUND_CHANGE_REQUESTS Table.
The rejection reason from the CATS_OUTBOUND_ERRORS table.
Obtain the request and Transaction ID

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:
a. If you know the rejection date, enter it as the Start and End Date.
b. Enter a Time From and To range.
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.
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

Run a Data Replication (C1) report for CATS_OUTBOUND_ERRORS. Your
request should look like this:
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 Figure 12 on page 74). For other common errors, see page 71.

Figure 12 Find TransactionID
Editing a rejected change request

Occasionally, when you enter a Change Request in the MSATS web portal, it is rejected
because, either:
The Proposed Change Date is not within the Prospective or Retrospective Period
(see Figure 13 below).
The data in the Change Request is incorrect or missing.
To fix the error without having to re-enter the data:
In your browser interface, once only, click the Back arrow (see Figure 13 below).
Figure 13 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.

Notifications
Notifications occur when there is a change to the status of a Change Request or when
an Objection is lodged or withdrawn. A Notification includes information about what is
proposed to change or what has changed, in the case of a COM (complete) Notification.
Notifications are sent to relevant parties throughout the different stages of the
Transaction process as determined by the notification rules. Current and new Roles are
notified of a change in Change Request status according to the Notification Rules (see
page 199).
Notifications are placed in your Participant Outbox regardless of how you created them
(web portal or Batch). MSATS puts each Notification in a separate XML message in a
separate .ZIP file. Participants can request outbound messages bundled by calling the
Support Hub.
You can view Notifications in the web portal or download the .XML message from your
Participant Outbox.
The process involves:
1. Determining who is notified.
2. Determining what is in the Notification.
3. Creating the Notification ready for distribution.
4. Keeping an audit trail of Notifications.

New parties
Notifications serve an important purpose for nominated new parties for an existing NMI
who do not currently act in the Role. When the Notification for a status COM is sent to
new parties, it includes the NMI master data required by the new party.
It includes all active records, (active historic and/or current), depending on the period
covered by the Change Request. The reason for supplying this information is to make it
easy for parties acquiring a new relationship to update their own systems with the NMI
information.
New parties on a Change Request in certain roles (FRMP, LNSP, LR, MDP, MBP, and
RP) receive these special notifications for the COM status. If the old and new parties are
the same for a Role, the special Notification for the COM status is not sent.
Some Change Requests require the specification of the Role party, even the Role is not
changing.
NMI master data in notifications

Generally, a Notification only includes information about:
The Proposed change.
For a COM Notification, what has changed.
For new parties nominated on a Change Request, Batch Notifications serve an

additional purpose for an existing NMI. When the Notification for status COM (such as,
Completed) is sent to the new parties, it includes all NMI master data for the NMI the
new participant is entitled to. It can also include active Current and active Historical
Data, depending on the period covered by the Change Request.
Supplying this information make it easy for new parties to update their own systems with
all current NMI information they acquired a relationship with.
The NMI master data applies to Notifications for Roles: FRMP, LNSP (including ENSP),
LR, MDP, MBP and RP. All Roles other than MPC or RoLR receive these special
Notifications for the COM status when there is a change of Role.

If a participant is nominated in a new role on the Change Request but the same
participant also occupies the existing role, the master data is not included. This is the
case for Change Requests where a new MDP is specified but there is no change
because it is the same party.
Batch notifications
A Batch Notification contains the same information as the MSATS Web Portal, except:
The status shows on the initiating Notification only. The web portal shows all
Notification status.
Each Notification includes the Jurisdiction, NMI Classification Code, and

Objection End Date.
It is easier to determine if an Objection-related Notification is an Objection or

Objection Withdrawal, because the <ObjectionAction> element contains Raised
or Withdrawn.
A Notification associated with an Objection includes the Objection date.
The COM Notification sent to participants nominated as new parties and who are new
participants in that Role includes a complete set of the active NMI Master Records the
participant requires for each of the master tables.
Batch submitted next scheduled read date
Updates to the Next Scheduled Read Date (NSRD) submitted by File Interface (Batch)
(such as CRs 5070 or 5071) do not obey the CATS History Model (see page 18).
If a Meter’s NSRD is updated by Batch, the current active record on the

CATS_METER_REGISTER Table for the supplied Meter Serial on the Change Request
is updated.

This is the existing Meter Serial record, where the:
MaintActFlg = A and the EndDate = 31-Dec-9999.
MaintUpdtDt is 31-Dec-9999.
This record is updated with the new NSRD but the MaintUpdtDt is not changed from the
high date.
Batch next scheduled read date updates
Notifications to FRMPs and Change Request responses to MDPs for updates to Next
scheduled read dates (NSRDs) submitted by Batch are sent out in batches of up to 500
at a time. If MSATS has more than 500 other Transactions in outbound tables awaiting
sending to you, no NSRD Notifications or Change Request responses are sent.
You cannot identify how many Transactions MSATS has waiting to send you, but if your
Participant Outbox remains full (for example, soon after you acknowledge a file, MSATS
sends you another one), you can assume MSATS still has files to send you.
If your Participant Outbox is empty or has less than 30 catsm files, you can assume
MSATS has no Transactions waiting to send you.
The processing to send these files is run every five minutes in three time blocks each
Day (AEST):
Block Time
1 4 am – 7 am
2 12 noon – 1 pm
3 9 pm – 11 pm
For example, if you submit NSRD updates at 08:00 Market time, the earliest you can
expect to see the Change Request responses is midday.

Retrospective notifications
MSATS can also send Notifications to participants Retrospectively. If a participant
selects a Retrospective Change Reason Code, the participants associated with the
Change Request (such as, they held a current Role against the NMI during the
Retrospective period) receive notifications.
In the example in Table 9 below, assuming:
A Retrospective Change Reason Code is created with a Proposed Date of 12

March 2008.
The active participants hold a relationship with NMI 6001000100.
Table 9 Retrospective notification example
Active NMI Role Start date End date Flag Explanation

participants
FRMP1 6001000100 FRMP 1/7/2000 19/10/2008 A FRMP1 receives the

notification since it is the
active FRMP at the time of
the proposed change
FRMP2 6001000100 FRMP 20/10/2008 31/12/9999 A If the Proposed Date changes

to 5-Nov-2008, FRMP2
receives the FRMP
notification for the current
FRMP
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

Notification role status

MSATS allows multiple participants to have a role status of Current against a NMI.
When a Notification or Objection rule is

defined for Current on a Retrospective
Change Reason Code, it means any The notification rule only applies if the
Retrospective participant is still an
current participants during the Change
Active participant in MSATS. If the
Request period. Allowing participants Retrospective participant becomes
having no Current relationship with a Inactive, they do not receive the
NMI, but who did at the time of the notification.
change, to be notified and have the right
to object.
It excludes participants having a Current

relationship with the NMI but had none at the time of the Retrospective change.
An active history record is maintained since the NMI began its existence because many
MSATS Settlement operations, for example Revisions, occur a long time after the
Settlement period.
Web portal notifications search

The web portal Notifications interface allows participants to search for Notifications and
view their details. There is also a link to the related Change Request and Objections.

Objections
A participant can raise an Objection to a Change Request according to:
The Objection rules defining, for

each Change Request type, The MSATS Web Portal >
which participant roles can object Administration > Rules Maintenance has
with which Objection codes. a list of Objection Rules and
Jurisdictional Parameters for each
The Jurisdiction rules defining, Change Request type.
the length of the Objection
Logging and Clearing Periods.
Other participants are informed

according to the applicable Notification Rules (see page 199). The ability to object to a
Transaction is determined by the Objection Rules and Jurisdictional Parameters.
You can log Objections with Prospective and Retrospective Change Reason Codes.
When a participant has the right to object in a Current Role, any participant acting in that
Role for the period covered by the Change Request (such as, at the Proposed Date or
Actual Change Date) 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.
More than one participant may be acting in the Current Role for any Change Request so
MSATS allows multiple participants to have a role status of Current against a NMI.
For Table 10 on page 83 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),
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:
Identify the related Change Request ID.
Identify the participant making the Objection.
Identify the Role the Participant is acting for.
Provide an Objection Code
The Jurisdictional rules determine the length of the Objection period. You can only log
an Objection within the Objection Logging Period for the Change Request.
Table 10 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
You can log an Objection even if another party has logged a valid Objection.
If a Change Request is in a status of Objected for a specified number of days,

MSATS changes the status to Cancelled.
If the Change Request status changes to Cancelled, MSATS retains the history.
If the Change Request status changes to Cancelled, all parties receiving the
original Notification (including the Initiator) are notified.
NOACC objection
NOACC Objection rules:
Only MDPs can submit a NOACC code.
It can move to PEND status. This is the only Objection code with this
functionality.
It does not recognise the Objection Logging Period.
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 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 Table 11 on page 85. For more
details, see CATS Procedure Principles and Obligations.

Table 11 Initial objection information
Field Field code Description
Participant PARTTRANSACTIONID Participant provided Transaction ID for each

Transaction ID 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 Transaction after
the Objection Logging Period expires, the Change Request proceeds to Completed and
the information in the Transaction becomes the NMI Master Record.
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 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 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.
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 if the Objection Logging Period has passed.
Table 12 Objection withdrawal fields
Field Field code Description
Change Request REQUESTID The unique identifier of the Change Request relating
ID to the objection
Participant PARTTRANSACTIONID The participant transaction identifier provided by the

Transaction ID 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
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 Figure 14 on page 91).
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 14 Withdrawn objection notice

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.
Receiving an RDAT
You receive RDATs in your Participant Outbox. The information is in an XML message
compressed in a zip file and the required data fields have NULL=”TRUE”.
To respond to an RDAT, in the MSATS Web Portal, click Respond (see Figure 15 on
page 93). 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 For help, see Guide to MSATS Web
normally the Actual Meter Read Date Portal.
(CR1500) or for a new Interval Meter
installation, the date it was National
Electricity Rules (NER) compliant.
Where a proposed Transfer 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. 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 15 Participant data requests

NMI discovery
A NMI (National Meter Identifier) is used for recording the energy usage for a specific
consumer. Examples of consumers are houses, apartments and streetlights.
Using NMI Discovery you can identify a specific NMI for settlement, auditing, and
discovery purposes:
1. End-use Customer’s NMI and NMI Checksum if they cannot provide it.
2. Enough Standing Data about the NMI to provide a quote for the End-use
Customer.
3. For NSPs or ENMs, confirm the details returned are correct as identified by the
Change Request.
NSPs are restricted to performing NMI Discovery to those NMIs for which they
have the LNSP Role, and ENMs are restricted to those Child NMIs where they
have an LNSP Role.
The examples in this section use the MSATS Web Portal NMI Discovery, they assume
you are familiar with the NMI Discovery interface.
Access to NMI data depends on the NMI Discovery Field Access Rules and the Search
Key Rules. For details, see Rules on page 195.
There are three types of NMI Discovery:
NMI Discovery Search 1 (NMID1)
Find a NMI and the NMI Checksum using one or any combination of: End-use
Customer’s address, the address’s DPID, or Meter Serial ID.
Enter a NMI and NMI Checksum to obtain Standing Data about the NMI. The
returned information assists new Retailers to prepare a quote for the End-use
Customer.
Find a NMI and Reason Code to obtain the details of the previous FRMP for the
NMI.

Used when there is a transfer error and the current FRMP wants to revert the site
to the previous FRMP.
Structured and unstructured addresses

MSATS supports two types of address formats:
1. Structured (based on an Australian Standard)
2. Unstructured
Most MSATS addresses are Structured, so when you search by address, use this format
first. If MSATS cannot find a Structured address, it uses your values to search the
Unstructured address fields.
NMI discovery search 1 – NMI

discovery
This search is used to identify the NMI characters assigned to a Connection Point.
NMI discovery search 1 is only successful if information in MSATS supports one of the
following options. Participants can use any, or all these options in the following order:
1. DPID
2. Meter Serial ID: For step-by-step instructions about

using the MSATS Web Portal NMI
Discovery, see Guide to MSATS Web
The state, locality, and postcode Portal.
are not required.
If a NMI Master Record does not
contain DPID or address
information, the NMI search is only successful if a Meter Serial ID is provided.
3. Address (without DPID)

With this option, you must provide the state and locality (or state and postcode).
You can provide either a Structured or Unstructured address:
a. For the first level search, all input information is expected in the Structured
format.
b. If the first level search is unsuccessful, you can do a second search on

Unstructured format.
c. MSATS identifies a unique Metering Installation which can be co-located with

a postal delivery point but there are instances where it has no postal delivery
point, so MSATS allows either a Structured or Unstructured Address. The
Unstructured Address does not contain state and postcode information.
Jurisdictions decide the search criteria. Currently, the rules are identical in each
Jurisdiction.
NMI discovery search 1 returned information
The following information returns for each matching NMI:
1. NMI
2. NMI Checksum
3. Parent Name (if exists)
4. Child Name (if exists)
5. The full address (only if the Jurisdiction allows. Currently, all Jurisdictions allow
the full address).

NMI discovery search 2 – obtain

standing data
This search is used to identify the NMI Standing Data recorded for the Connection Point
(NMI) and the data available for release in accordance with the NMI Standing Data
Access Rules. For details, see page 201.
Use the NMI and NMI Checksum found in your NMI Discovery Search 1 search to find
the NMI Standing Data. The data is available to Retailers and NSPs not having Explicit
Informed Consent from an End-use Customer.
The returned information assists new Retailers to prepare quotes for End-Use
Customers.
NMI discovery search 3 – obtain role

data
This search is used by Retailers to:
Progress error correction Change Requests
Identify the previous FRMP
For seeking agreement to raise a Retrospective alignment with Meter read

transfers.
The valid Standing Data items returned to the initiating Role in all Jurisdictions for a
successful NMI Discovery Search 3 request are specified in Table 13 on page 98.
The NMI Standing Data Access Rules for this Transaction define which:
Role can initiate a request for NMI Standing Data.
Standing Data items are returned when a request is submitted.

When initiating a NMI Discovery Search 3, a Retailer must ensure:
When using the reason of TRI (Transferred In Error), they are the Current
FRMP or the most recent previous FRMP for the NMI.
This applies where:
a. The Current FRMP needs to request a Retailer to transfer back a NMI

transferred in error.
b. The most recent previous FRMP has identified another Retailer has
transferred the NMI in error and is seeking to transfer it back.
When using the reason of NNS (New NMI Setup Error (see Table 13 below),
the NMI was created in the past 130 Business Days from the NMI Discovery
Search 3 date.
Table 13 NMI discovery search 3 standing data items returned for all jurisdictions per change reason code
Change Description Standing Standing data description

reason code data
All NMI A 10-digit National Metering Identifier
NNS New NMI Setup FRMP Up to 10-character code representing the identity of
Error the Current FRMP
OTR Other Transfer FRMP Up to 10-character code representing the identity of

SAB Site Abolishment FRMP Up to 10-character code representing the identity of

the Current FRMP
Start Date
Start Date of the Current FRMP record
TRI Transferred In FRMP Up to 10-character code representing the identity of

Start Date
Start Date of the Current FRMP record
TRI Transferred In FRMP Up to 10-character code representing the identity of

Error the most recent previous FRMP
End Date
End Date of the most recent previous FRMP record

Finding a NMI tips

For a successful NMI search, enter as much as information as you know:
For each field.
In the Structured Address fields.
In the correct field. For example, often the Suburb/Locality and House Number
are put in the incorrect fields. Many searches fail because the Flat/Unit Number
or Floor/Level Number is used in this field.
Address field tips
DPID
The fastest search is to use the NMI’s DPID (providing it is in MSATS). So, if you know
the DPID, try it first without any additional information.
Once the record is returned, be sure to check that it is the correct address.
Only a very small percentage of NMIs in MSATS have the DPID field populated, thus
making a search using this parameter unreliable.

Street type
If you are confident your address is correct, save some time by not entering the Street
type because it is a long list to select from. Excluding it still gives you the same result. If
the information returned isn’t what you expected, you can enter it and search again.
Locality or post code
If you’re not sure how to spell a Locality or think the address is unstructured (see Is the
address I’m searching for unstructured? on page 211), leave it out and search by
Postcode.
The search uses adjacent postcodes if it cannot find a match for the specified postcode.
Common NMI discovery errors

Table 14 Common NMI discovery error messages
Code Description Explanation
0 Success If it is an NMID1 it means records are

returned but may not exactly match your
search criteria
If it is an NMID2, it means the NMI and NMI
Checksum you entered were valid and the
Standing Data you are entitled to is returned
1403 NMI Discovery. No Access Rule for NMI Discovery is not allowed for the Role you
Jurisdiction Code are acting in.
It could be NMI Discovery:
- Is allowed in the Jurisdiction but not for
your Role
- Is not allowed in this Jurisdiction at all
1404 NMI Discovery. No Data Found There are no matches for your search criteria

Code Description Explanation
1410 More data available. Current search exceeds Your search found some matches and
Jurisdictional limit returned the maximum number of records
allowed by the Jurisdiction
Not all matching data returned, there are
more matches
1411 NMI Discovery. Locality or Postcode required Either the Locality or Postcode is mandatory
in NMID1
1412 NMI Discovery. State required The State is mandatory for NMID1
1451 NMI Standing Data: Checksum Wrong The NMI Checksum does not match the NMI
Either the NMI or NMI Checksum is incorrect
1452 NMI Standing Data: No Access Rule NMI Discovery is not allowed for the Role you
are acting in.
It could be NMI Discovery:
- Is allowed in the Jurisdiction but not for
your Role
- Is not allowed in this Jurisdiction at all
1454 NMI Standing Data: No NMI or Jurisdiction MSATS cannot find the NMI or it is not
Code included in the Batch file

NMI master
In the NMI Master – Search interface, in the MSATS Web Portal, you can locate and
view the following NMI information:
All active and inactive records for a single NMI without being restricted by a from
and to date range.
All NMIs having or having had a relationship with the Role during a nominated
date range.
To use this interface, you must specify:
The Role you are searching for.
This must be a valid Role for the Participant ID you are logged on as.
2. The participant acting in the LNSP role.
3. The enquiry Start and End Date.
The allowable date range is seven days.
Optional parameters are a NMI Range From and To. To return all records for a single
NMI, leave the To field blank.

After entering the search parameters, MSATS checks if you have a relationship with the
NMI in the selected Role within the Date Range From entered. If you do not have a
relationship during that period, no results return.
This means MSATS only looks to see if you had a relationship during the period. If you
did and it is superseded by another participant with a Retrospective Change you won’t
see any results.
NMI relationship rules

To have a relationship with the NMI, there must be a record on the
CATS_NMI_PARTICIPANT_RELATIONS Table where:
1. The Role ID is the Role you nominated.
2. You are the nominated Participant ID.
3. The record’s Start Date is <= the record’s End Date of a relationship record you
have with this NMI.
4. The record’s EndDate is >= the record’s Start Date of a relationship record you
have with this NMI.
5. The MAINTACTFLG = A.

NMI master – list

Assuming there is at least one record on the CATS_NMI_PARTICIPANT_ RELATIONS
Table matching your criteria, the NMI Master – List interface displays showing all active
and inactive records matching your criteria and the NMI relationship rules on page 103
from the CATS_NMI_DATA Table.
Not included in the results is the MaintActFlg so it’s not obvious which are the inactive or
active records. However, based on the history model you can work this out. The date in
the Updated On column is the MAINTUPDTDT (see Figure 16 below), so:
If the updated on date is The activity status (maintactflg) is
The high date – 31-Dec-9999 Active
Any other date Inactive
Figure 16 NMI Master – List interface

Show all records

To see all records you are entitled to view overlapping your participant relationship, not
only the ones matching the initial date parameters, click Show All in the Action column
(see Figure 16 on page 104).
In Show All view, you can see the Activity Status (MAINTACTFLG) for these records.
For any record in these interfaces, you can click View in the Action column to see the
record content.
View information categories

To view a list of records overlapping the report date parameters and the participant
relationship records click View Datastreams, View Relationships, or View Meter
Registers.
You can use the Updated On date in any of these interfaces to work out which records
are active or inactive.

AEMO CATS Transactions
AEMO CATS
Transactions
This chapter describes the CATS Transactions used by AEMO, including
Acknowledgement and validation and how to update large quantities of MSATS
Standing Data.
CATS Transactions used by AEMO are:
1. Acknowledgment and Validation (on page 107)
2. Change Request Response (on page 131)
3. Objection Response (on page 133)
4. NMI Discovery Response (on page 133)
5. Report Data Response (on page 137)
6. Notifications (on page 137)
7. Request for Data Transfer (on page 138)
8. Retailer of Last Resort (on page 138)

Acknowledgement and
validation
MSATS validates and responds to ALL Transactions with an acknowledgment of receipt
(ACK). Acknowledgement Transactions depend on the interface used: API, Batch, or
web. This section describes validation, ACK files and how to acknowledge one for each
interface.
MSATS to participant
MSATS does the following when submitting Transactions to participants:
Sends a zip file to your Participant Outbox.
If you do not have a back-end system to process incoming files, AEMO

recommends you save the file and look at the contents before acknowledging.
To save the zip file, right-mouse click, select Save Target As, and save it to your
local drive.
Once you acknowledge the file, MSATS moves the zip file into your Participant
Archive.
Access to the Participant Archive depends on the rights assigned to you by your
company’s Participant Administrator.
MSATS deletes the zip file from your Participant Outbox.

Validation
Transactions Initiated by participants undergo several validations prior to moving to the
Requested status.
Level 1
MSATS performs the following 1st level validations:
The user ID nominated in the <SecurityContext> element of the file is permitted

to perform each type of batch transaction submitted.
The XML is well formed (meaning that it meets the rules defined for writing XML).
The file is valid according to the rules specified in the aseXML schema.
The schema and transaction versions are supported by MSATS.
The number of transactions in the file do not exceed the transaction limits for the
transaction group imposed by MSATS.
Level 2
For each Transaction that is accepted, MSATS performs 2nd level validations and
processes the request. These second level validations include business-level validations
such as checking:
The initiator of the Transaction can or is acting in a Role that is entitled to submit
a transaction for the nominated change reason code.
All required fields for this change reason code, as required by the Field
Validation Rules, are provided.
Only fields valid for this change reason code, as required by the Field Validation
Rules, are provided.

The Change Reason Code is valid for use in the jurisdiction in which the NMI is
located.
Subsequent change request validation
After the Change Request is submitted, any subsequent Change Requests submitted by
the Initiating participant is validated as follows:
1. The NMI on the subsequent Change Request is checked against the NMI on the
initial Change Request.
2. The Participant ID on the subsequent Change Request is checked against the

Participant ID on the initial Change Request.
Validation checks
Validation checks in order of priority are:
1. Codes and dates comply with the codes and rules look-up tables in the MSATS
Web Portal > Administration > Codes and Rules Maintenance.
The following data is validated:
a. Change Request ID
b. Jurisdiction
c. Role ID
d. NMI Status Code
e. Read Type Code
f. Change Request Code
g. TNI Code
h. DLF Code
i. Metering Installation Type Code
j. Parent Name
k. Child Name

l. Proposed Change Date
2. Change Reason Codes and Field Validation Rules comply:
a. Change Reason Codes, see page 174.
b. Field Validation Rules: RI, OI, RQ, RD, RA.
3. NMI characters against the NMI Checksum.
4. The Initiating participant is an active participant and can act in the Role to initiate
the Transaction.
The following data is validated:
a. Participant ID
b. Participant Status
c. Participant Roles
5. The Proposed Change Date and the Actual Change Date are within the range
allowed by the Change Reason Code.
6. The Proposed Change Date, the Actual Change Date, and the Actual End Date
against the Timeframe Rules.
7. Information regarding Embedded Networks:
a. The codes comply with the MSATS Web Portal > Administration > Codes
Maintenance > Embedded Network Identifier Codes.
b. The Parent and Child Connection Point names are not identical for the same
NMI.
c. The Child NMI is checked against the Parent NMI.
d. There are no circular relationships.
e. Prevent Local Retailer changes on a Child NMI.
f. If a Parent NMI is not active, there are no active Child NMIs.

Validation explanations
Table 15 below summarises the validations MSATS performs when checking a Change
Request in PVAL status. If any of these validations fail, the Change Request moves to
REJ status. For Change Request lifecycle details, see page 43.
Table 15 Validations and explanations
Validation Check
Actual Change If the Change Reason Code is one submitting an ACTUALCHANGEDATE (CR
Date 1500), if the participant submitting is where the Data Request was sent. Use the
initiating Request ID to identify the original Change Request
If the ActualChangeDate is within the Retrospective Period
Changes to If the participant submitting the updated Change Request is the same participant
Change who submitted the original Change Request and the original Change Request
Requests status is not CAN, REJ, or COM
For Change Request lifecycle details, see page 43
Checksum If the NMI Checksum is valid for the NMI supplied
Date For a Prospective Change:

- The Proposed Change Date is tomorrow or later
- The Proposed Change Date is not after the Prospective Period
For a Retrospective Change:
- The Proposed Change Date is today or earlier
- The Proposed Change Date is not prior to the Retrospective Period
- If an ActualEndDate is submitted, ensure it is either today or prior to today
Embedded If the Embedded Network Code is valid for the period covered
Network
The EmbedNetParent and EmbedNetChild fields in the CATS_NMI_DATA table
are not the same
If a Child NMI is being created, a Parent NMI has been identified for the
Embedded Network
The change does not produce an Embedded Network circular relationship
It is not a change of LR on a Child NMI (unless the Transaction is creating the
Child NMI)
It does not create an orphan (i.e. if a parent is removed, there are no more parents
or children)

Validation Check
Field For the Change Reason Code:

Completeness
- All fields in the Field Validation Rules with a Data Source Code of RI are
supplied
- All fields have a Data Source Code of either RI or OI
- If it includes fields held in lookup tables and the value supplied for each field is a
Field-level
valid code on the lookup table
- If it was valid for the whole period covered by the Change Request
- If the participant submitting the Change Request is currently active and was
Initiating Party
active from the period covered by the Change Request
- For a Change Request submitted by a New Role, if the participant submitting
the Change Request is entitled to act in that Role for the period covered by the
Change Request and the participant submitting the Change Request is the
participant nominated in that New Role
- For a Change Request submitted by a Current Role, if the participant submitting
the Change Request is acting in that Role for the entire period covered by the
Change Request
- For the combination of the Jurisdiction and NMI Classification on the NMI
Jurisdictional
Master Record or Change Request and for the Change Reason Code on the
Rules
Change Request, if there is a Jurisdictional rule. In the MSATS Web Portal, see
Administration > Rules Maintenance > Jurisdictional Parameters
- If the NMI already exists (i.e. there is a NMI Master Record) and there is a NMI
Classification Code, Jurisdiction Code, or both, the NMI Classification Code and
Jurisdiction Code take precedence in determining whether Jurisdictional rules
exist

Validation Check
MDM Some of these validations also apply at the time it is about to move to COM status.
The context for this validation is if the it completes, the configuration as of the Day
after the Actual Change Date or, for the period covered by the Proposed Change
Date, must not break these rules:
- The NMI must have a valid NMI Classification Code, Jurisdiction Code, DLF
Code, NMI Status Code, TNI Code, LR, FRMP, RP, ROLR, MDP, and MPB
- It must not cause any gaps in the NMI’s history (on any of the master tables)
- Every time a Datastream record is created or updated, it must have a
Datastream Status Code, that is NOT NULL for the ADL, a valid value in
DataStreamType and a valid Profile Name
- Every time a Datastream is created or updated there must be an active NMI
covering the period when the Datastream is active
- Every time a Meter is created or changed it must always have a Metering
Installation Type Code and a Meter Register Status Code
- The Profile Name assigned to a Datastream must be valid in that NMI's
Jurisdiction
- If the NMI Classification Code is Small, the ADL must be <=2000
- If the Datastream Type is C, the Profile Name cannot be NOPROF
New NMI If the Change Reason Code is 2000, 2001, 2020, 2021, 2100, 2500, or 2501,
there isn’t an existing record on the CATS_NMI_ DATA table for this NMI
RA If, in the Field Validation Rules there are RA fields, there is a participant to send
the Data Request for the missing data to on the NMI Master Record for the period
covered
RQ If, in the Field Validation Rules there are RQ fields and no data on the NMI Master
Record for those fields, there is a participant to send the Data Request for the
missing data to on the NMI Master Record for the period covered

Two-stage batch validation process
Whenever you submit a Transaction by Batch it goes through two levels of validation,
MSATS conveys:
First level validation in an .ACK file placed in your Participant Outbox.
If you submit the Batch file using the Web Portal you also see it on the interface.
If the Transaction passes the first level validation, it passes to second level
validation.
Second level validation in a Response Transaction.
The type of Response Transaction you receive depends on the submitted

Transaction:
Type Response
Change Request (CR) Change Request Response (CRR)
Objection (OBJ) Objection Response (OBJR)
NMI Discovery Request (NMID) NMI Discovery Response (NMIR)
Report Request (RPTD) Report Response
Meter Data Notification (MDN) Meter Data Response
The Response Transaction contains the result of your request, Request IDs, or
the results of the validation. For example, Change Request, Objection, Meter
Data Notifications.

Acknowledgement
ACK files
The ACK file includes:
The results of the 1st level validation.
The status: Accept or Reject.
The Receipt IDs: one for the message and one for each Transaction.
Different Transactions have different content in their ACK files.
Change requests
For Change Requests, the numeric part of the Receipt ID corresponds to the MSATS
assigned Request ID. In Figure 17 on page 116, the Receipt ID is CATS-CR8335806, so
8335806 is the Request ID.
You can use the Request ID to search for the Change Request and check the status of
the Transaction.

Figure 17 Transaction ACK file

NMI discovery
For NMI Discovery the receipt ID identifies the corresponding file in your Participant
Outbox (see Figure 18 below and Figure 19 on page 118).
Figure 18 NMI discovery ACK

Figure 19 Participant outbox filename

Objections
For Objections, the numeric value of the Receipt ID corresponds to the MSATS
assigned Objection ID. In Figure 20 below the Receipt ID is CATS-OBJ19735, so the
Objection ID is 19735. You can use the Objection ID to search and check the status of
the Objection.
Figure 20 Objection Transaction ACK

Reports
For reports, the numeric value of the Receipt ID corresponds to the MSATS assigned
Report Request ID. In Figure 21 below the ID is CATS-215731, so the Report Request
ID 215731.
Figure 21 Report ACK

Transaction limits
Transaction limits allow participants to manage the submission and receipt of MSATS
files to prevent the application of stop files.
When the number of unacknowledged outbound files in your Participant Outbox exceeds
the upper or lower limit, a Stop File is imposed on your Participant Outbox Transactions.
Once imposed no more processing on inbound or outbound Transactions occurs until
the file numbers fall below the Lower Limit.
Stop file rules
If a participant is stopped for any of the following reasons, MSATS stops processing files
for that Transaction:
Change Request or Change Request Notification. Other Transactions are

processed.
NSRD Notification or Response reasons. MSATS does not process any CATS
Change Request transactions with Change Reason Codes: 5070 or 5071. Other
Transactions are processed.
Outbox files. MSATS only processes Meter Data Notification Transactions.
Report requests. MSATS does not process any Report Request Transactions.
Other Transactions are processed.

Viewing limits
Where a participant belongs to a group, the limits apply to the group not to the individual
Participant ID.
You can view your limits (upper and lower) for the accumulation of Change Request
Response and notification messages to monitor how many Transactions are currently
queued:
In the MSATS Web Portal > Reports and Alerts > Queue Monitoring. For help,
see Guide to MSATS Web Portal.
Using the MSATS Limits API. For help, see Guide to NEM Retail B2M APIs.
Increasing limits
Participants can temporarily increase their Change Request and Change Request
Notifications Upper Limits to the maximum allowed in the MSATS Web Portal > Reports
and Alerts > Queue Monitoring.
If you cannot see the Increase option, the functionality is unavailable to you. All Upper
Limits are reset at midnight.

Acknowledgement – API
Sending and receiving acknowledgements using an API differs according to the type of
API you use. For details, see Guide to NEM Retail B2M APIs > Participant
Implementation.
Participants can nominate the outbound protocol for B2M messages by transaction
group, so acknowledged messages can be your Participant Hub Queue and your B2M
Outbox.
Acknowledgement – batch
When you submit a Transaction using the File Interface it is validated and an
Acceptance or Rejection response returned with the Change Request Response (CRR)
Transaction Type Code.
To acknowledge a zip file in your Participant File Server Outbox, write an ACK file with
the same name as the zip file. For help, see Creating and submitting batch transactions
on page 29.
Acknowledgement - web portal
To acknowledge a zip file in the web portal:
Login to the web portal, click Data Load Import > Participant Outbox.
Select the relevant zip files and click Acknowledge Selected.
a. MSATS writes an .ACK file to your Participant Inbox and deletes the zip file.
b. MSATS detects the zip file is deleted so deletes the .ACK file it created in
your Participant Inbox.

If within 30 seconds you see the following message, MSATS is unable to delete
the zip file. Follow the steps below to delete the ACK and zip files.
ACK deletion -API
Follow the steps for Batch or web portal ACK deletion.
ACK deletion - batch
To delete an the ACK from the Participant File Server:
Login to the Participant File Server and highlight the ACK file.
On your keyboard, press Delete.
Check the Inbox and Outbox are empty.

ACK deletion - web portal
To delete an ACK from the web portal:
Login to the web portal and navigate to Data Load Import > Participant Inbox.
Select the check box next to the ACK file and click Delete Selected.
Zip deletion – API
Follow the steps for Batch or web portal zip deletion.
Zip deletion – batch
To delete the zip from the Participant File Server:
1. Login to the Participant File Server.
2. Select the zip file and on your keyboard press delete.

Zip deletion - web portal
Sometimes, the MSATS Web Portal cannot complete the Hokey-Pokey Protocol on your
behalf (producing the ACK file and deleting your zip file) so the following message
displays:
MSATS allows you to continue using the web portal for other tasks but the zip file is
sitting in your Participant Inbox and there is no ACK file in your Participant Outbox.
When MSATS completes the Hokey-Pokey Protocol there is an ACK file in your
Participant Outbox, so you must delete your zip file. You can do this in the web portal or
Participant File Server.
Make sure you save the relevant information from the .ACK file before you delete the zip
file because MSATS is not monitoring the processing for you.
When MSATS detects you deleted your zip file it deletes the ACK file in your Participant
Outbox, so the file handling cycle is complete.

To delete the zip file from the web portal:
In Data Load Import > Participant Inbox, select the check box next to the File
Name and click the Delete Selected.
MSATS zip file deletion
Before MSATS deletes a zip file, it is copied to your Participant Archive on the
Participant File Server. The time a file stays in the archive is
about six months to one year. Participant Users with access
rights can view the Participant Archive in the following
interfaces.
The web portal > Data Load Import. For help, see Guide
to MSATS Web Portal.
Participant File Server > Archive.

The folder structure follows the model in Figure 22 below. For example, the full path and
name of an archived file might be:
X:\PARTID\Archive\2003\4-Apr\07\15.22.03\catsm_abcde_123456zip
The folders underneath Day contain a maximum of 500 files. The names of these folders
correspond to the time when the first file in the folder was archived and follow each other
chronologically. The Last Modified date of each file in the directory is the original date
the file was first created in your Participant Outbox and remains unchanged.
Figure 22 Participant archive structure

View outstanding messages and acks
You can view your outstanding Messages and ACKS in the MSATS Web Portal >
Participants > Participant Schema interface.
Response
Zip files generated due to a Change Request, Notification, Objection and so on are
always sent to the <ParticipantID> Batch. To see these messages login with the Batch
Participant ID.
To see the responses to requests for information you initiated, such as NMI Discovery
and report requests, login with your individual Participant User ID.
If your Participant User 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 generated aseXML response file has (see Figure 23 on

page 130):
The <Event> code

A successful response is 0. An error is any other number (for
error help, see page Error codes on page 70).
The rejection <Explanation>

Figure 23 Change request response with an error

Change request response

MSATS responds to a Change Request with an approval or rejection as it reaches the
Pending Validation status.
For each approved Change Request, a change request response (CRR) transaction is
generated. By default, each response transaction is in a separate .XML 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 from AEMO 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.
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 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 Guide to
MSATS Reports.
Notifications
Codes update
MSATS notifies participants of any changes to codes, rules, or participant data.
Change request status notification

The Change Request Status Notification Rules define which Roles are advised when a
Change Request undergoes a change in status. For details, see page 200.
Jurisdictions specify rules to control:
1. The period when MSATS can accept retrospective information.
2. The period when participants can log an Objection.

Request for data transfer

When MSATS receives a Change Request, it checks the existing data, ensuring it can
proceed through the Validation process. If some data required to complete the Change
Request is missing from the NMI Master Record, MSATS send a Request for Data
Transfer (RDAT) to the appropriate participants according to the Change Request Field
Validation Rules (see page 197).
The nominated parties provide the requested data in a new Change Request. For more
details, see Receiving on page 92.
Retailer of last resort

The NEM Retailer of Last Resort (RoLR) Processes define the processes participants
and AEMO must follow to manage Market Transactions and communicate customer and
site information if a RoLR event is invoked in the NEM. For details see NEM RoLR
Processes, Part A and B.

CATS History Model
CATS History
Model
This chapter is essential reading for anyone wanting familiarity with the CATS history
model because it assists understanding of the end-to-end Change Request process and
how the CATS NMI Standing Data Access Rules affect data returned from NMI
Discovery or a CATS report.
It explains:
The 5 key master tables containing the NMI Standing Data and how MSATS
manages its history.
How MSATS supports Retrospective changes to NMI Standing Data, specifically

because each billing period is settled after the Market trades occur.
Why such a complex history

model?
Settlements occur on a weekly basis, but a Billing Period is settled at least four times
over approximately 30 weeks (Preliminary, Final, Revision 1 and Revision 2). So
MSATS must facilitate Settlements by Billing Period, not just using the data for a certain
Billing Period but also at any nominated date in the past. This is necessary, for example,
for a dispute.
The CATS history model must be complex enough to identify:
As of today, what the NMI Standing Data looked like over time.
For example, when a Revision 2 Settlement run is initiated (30 weeks after the
Settlements week), as well as using the latest available Metering Data, MSATS
uses the version of NMI Standing Data for the Settlement period.

CATS History Model
As of any date in the past, what the NMI Standing Data looked like on that date
and on any date prior.
For example, if between the Final and Revision 1, there are Retrospective
changes to a NMI’s TNI or DLF, Revision 1 uses the new version of NMI
Standing Data.
MSATS must work out the following for For details about the data stored in the
MSATS master tables, see Standing
any NMI:
Data for MSATS.
As of today, what is the NMI

Standing Data for today.
As of today, what is the NMI Standing Data for Settlement Week 1.
As of 31-Jan-2002, what did the NMI Standing Data for Settlement Week 1 look
like (such as, ignore all changes made since 31-Jan-2002 to the NMI Standing
Data for the Settlement week 1 period).
NMI standing data master

tables
This section describes how and when MSATS updates the five NMI Standing Data
master tables when participants submit Change Requests. It includes an explanation of
the relationship between the dates supplied with a Change Request and the dates on
the NMI Master Record.
Table 16 on page 141 describes the five MSATS master tables containing the Standing
Data stored for each NMI.
To ensure there is a complete history for these tables, each time there is a change,
MSATS:
Makes old records inactive.
Creates new records.

CATS History Model
Table 16 NMI standing data master tables
Database table MSATS name Summary
CATS_NMI_DATA NMI Standing Address, TNI Code, DLF Code,

Data Aggregate Flag, Embedded Network
IDs, Jurisdiction, NMI Status Code,
etc
CATS_NMI_PARTICIPANT_RELATIONS Participant Role Roles and associated participants.

Relationships
Separate records are maintained for
each Role and participant relationship
CATS_NMI_DATA_STREAM NMI Datastreams Suffix, ADL, Profile Name, Datastream

Type and Datastream Status of each
MDM Datastream
CATS_METER_REGISTER NMI Metering Meter Serial ID, Meter type, Meter

Installation manufacturer, test results, etc
CATS_REGISTER_IDENTIFIER NMI Register Meter Serial ID, Network Tariff Code,

Identifier Unit of Measure etc
Mandatory NMI standing data

To be valid, a NMI used in MSATS must have the following minimum data:
At least one record on the CATS_NMI_DATA table.
At least eight records on the CATS_NMI_PARTICIPANT_RELATIONS table.

One for each of the mandatory Role ID Codes (See page 190).
Other NMI standing data

A NMI can also have:
At least one record on the CATS_METER_REGISTER table.

CATS History Model
At least one record on the CATS_REGISTER_IDENTIFIER table.
If Metering Data is submitted to MDM, at least one valid record on the

CATS_NMI_DATA_STREAM table.
NMI standing data

NMI Standing Data is the information captured against a NMI, including its NMI
classification, TNI, DLF codes, and physical location details.
Participant role relationship

Participant Role Relationships define the roles played by Market Participants against a
NMI record (see page 190).
During the Change Request process, participants nominate and modify Roles for
assignment to a NMI. These changes are not permanent until the Change Request is in
Completed (COM) status. However, if information in a Change Request is modified while
it is in progress, it is assigned a new Request ID and the life cycle restarts.
When a NMI is created, all Roles must be allocated on the Change Request. This
Change Request is usually created by the LNSP and all nominated parties are sent a
Notification informing them of the NMI and the role the LNSP has asked them to
undertake. The parties can object to this nomination.
Once a NMI is created, Change Requests are submitted to change Roles or groups of
Roles. For example, there is a specific Change Reason Code to change only the Local
Retailer. The Change Retailer (for example, CR1000) generally allow nomination of a
new FRMP, MDP, RP, MPB, or MPC.

CATS History Model
NMI datastreams
NMI Datastreams define the Metering Data MSATS expects to receive for any NMI.
Datastreams are Metering Data associated with a Connection Point represented by a
NMI. A NMI can have multiple Datastreams (for example, from one or more Meters,
Channels, or Registers comprising a single Meter). Each Datastream is identified by a
suffix.
NMI metering installation

NMI Meter Register records contain data stored about Meters for each NMI. Some of the
details recorded are the Next Scheduled Read Date (if it is manually read), the Metering
Installation Type, the physical location, and the manufacturer’s details.
NMI register identifier

NMI Register Identifier records contain data stored against Meter Register identifiers for
a Metering Installation associated with a NMI. These records contain information such
as, the register ID, Network Tariff Code and a code representing the unit of measure.
Each Metering Installation can have multiple registers.

CATS History Model
How MSATS manages CATS

history
Table 17 below describes the key fields every record has in the five NMI Standing Data
tables. MSATS uses these fields to manage NMI history.
The start and end dates are referred to as the Trading Date. The record’s NMI Standing
Data, including its Start and End Dates never change. MSATS only updates an existing
record if the data becomes redundant due to a change and only the MaintUpdtDt and
the Maintactflg change.
Table 17 Key NMI standing data fields
Field name Description Data type
StartDate The start of a Billing Period (i.e. the Settlement date) for the version of Trading
NMI Standing Data this record applies to Date
The data applies from the beginning of this date (the start of the Day,
i.e. 00:00)
EndDate The end of the Billing Period for the version of NMI Standing Data this Trading
record applies to Date
The data applies until the end of this date (the end of the Day, i.e.
23:59)
MaintActFlg The status of the record, either: Code

- A (active): When MSATS creates a new record, its status is A
- I (Inactive): When the record becomes redundant due to a data
change, MSATS changes the MaintActFlg to I
MaintCreateDt The date MSATS created the record Database

date
MaintUpdtDt The date MSATS creates or updates the record: Database

date
- On record creation, it sets the MaintUpdtDt to 31-Dec-9999.
If a record’s MaintUpdtDt is 31-Dec-9999, its MaintActFlg is always
A
- On record change, it changes the MaintUpdtDt to the date and time
it changed
If a record’s MaintUpdtDt is any other date, its MaintActFlg is always
I

CATS History Model
Different field names

In MSATS, the NMI Master tables, web portal, and report XML fields have different
names. So, when you view records in these interfaces, there are different names for the
same field. Table 18 below explains the different names for the same field.
Table 18 Different naming standards
NMI master tables Report XML fields Web portal
StartDate FromDate Start Date
EndDate ToDate End Date
MaintCreateDt CreationDate This date is not supplied on the NMI Master screens
MaintUpdtDt MaintenanceDate Updated On
MaintActFlg RowStatus Activity Status

CATS History Model
How MSATS updates the NMI

master tables
Changing NMI standing data

Participants entitled to change data in any of the five NMI Master tables, for example,
the LNSP if it is the TNI Code or the new Retailer if it is a change of FRMP, must submit
a Change Request.
Proposed versus actual change date

When submitting a Change Request, the Initiator specifies a Proposed Date. This date is
the start of the Billing Period when the new version of NMI Standing Data applies. But
the date when it applies is the Actual Change Date on the Change Request.
Sometimes, for example a Change of Retailer Transaction – CR 1000 and 1030, another
participant (the MDP in this example) is requested to supply the Actual Change Date,
which is usually the date of an Actual Meter Reading. Until the MDP submits a
Transaction to supply the date the Initiator’s Change Request cannot complete.
If there is no requirement for another participant to supply the Actual Change Date,
MSATS inserts the Proposed Date into the Actual Change Date field when it does its
initial Change Request validation.

CATS History Model
Processing the updates to master

records
Change Requests are completed and NMI Master Records updated as part of an
overnight process. The process runs after midnight and after the end-of-day processing.
End-of-day process
The end-of-day process starts at 00:10 am every day and runs for around two hours.
BU500 processes pending CRs that have reached their actual start date.
Overnight process
The overnight process completes all Change Requests satisfying these three criteria:
The Objection Logging Period is complete.
There are no outstanding Objections.
The Actual Change Date has passed.
For example, if the Actual Change Date on a Change Request is 08-Mar-2002

and the Objection Logging Period is complete, the overnight process completes
the Change Request at about 01:00 on 09-Mar-2002.
A Change Request never completes until after the Actual Change Date passes.
When the overnight process updates the NMI Master Record, for records it makes
inactive due to a change, it updates its MaintUpdtDt with the date and time of the
change.
For any new record it creates due to a change, it makes its MaintCreateDt the date and
time it made the changes to the newly Inactive records. Normally, the MaintCreateDt on
any new records are the same as the MaintUpdtDt on the records made inactive.

CATS History Model
Retrospective or prospective change

Depending if it is a Retrospective or Prospective Change, the Proposed Date or Actual
Change Date is in the past or future.
A Retrospective Change can use today’s

date. Optionally, for some types of For details about data in
CATS_NMI_DATA, see page 141.
Retrospective Changes, it is possible to
specify an Actual End Date. If you supply
an Actual End Date, it is the date the
new version of the NMI Standing Data
applies.
If you don’t supply an Actual End Date, MSATS assumes it is an open-ended change
(for example, applying in the future) and overnight populates the End Date on the new
NMI Master Record with 31-Dec-9999.
These examples describe how MSATS updates data in the CATS_NMI_DATA table for
Prospective and Retrospective Change Requests.
Prospective and retrospective change

request examples
The examples in Table 19 below, change the CATS_NMI_DATA table and describe of
how MSATS updates data.
Table 19 Prospective and retrospective Change Requests
Step Process Proposed Completion Explanation

change date
date
1. Create 01-Feb- 02-Feb- These two Transactions are Change Requests with
the NMI 2002 2002 Prospective changes for the effective date change so,
are part of the overnight process.
2. Change 01-Mar- 02-Mar- For details, see Processing the updates to master
the TNI 2002 2002 records on page 147.
Code

CATS History Model
Step Process Proposed Completion Explanation

change date
date
3. Change 01-Jul- 11-Jul-2002 This is a Retrospective Transaction entered on 10-Jul-

the DLF 2002 2002. Because there are no allowable Objections for
Code this type of Change Request used to update the DLF
Code, it is processed during the overnight process for
that date (about 01:00 on 11-Jul-2002).
Create the NMI
The Change Request to create the NMI includes the following fields:
Field Value
TNICode VTT2
DLFCode LELS
ActualChangeDate 01-Feb-2002
ActualEndDate Null
In the overnight processing for 1-Feb-2002 (approximately 01:00 on 2-Feb-2002), the

record shown in Table 20 on page 150 is created in the CATS_NMI_DATA table with the
following details:
The EndDate is the high date because this record is active into the future.
The MaintActFlg is A.
The MaintUpdtDt is the high date because that is what it defaults to when the
record is created.
The ID_ND is a unique identifier MSATS assigns to each record.

CATS History Model
Table 20 CATS_NMI_Data after NMI creation
NMI Start End MAINTUPDTDT MAINTCREATEDT
MAINTACTFLG
Date Date
DLF code
TNI code
ID_ND
1 XXXXXXXX24 VTT2 LELS 01-Feb- 31-Dec- 31-Dec-9999 A 02-Feb-2002

2002 9999 1:05
The table above represents the same record as a diagram with the following details:
The dotted line at the top of an active record is used to indicate the MaintUpdtDt
is the high date (31-Dec-9999). Otherwise, the MaintUpdtDt is the date MSATS
made the record inactive.
If the record extends into the future on the Trading Date axis, it means its
EndDate is the high date.

CATS History Model
Figure 24 CATS_NMI_Data diagram after NMI creation
Change the TNI code
The Change Request to change the TNI includes the following fields:
Field Value
TNICode VHTS
ActualChangeDate 01-Mar-2002
ActualEndDate Null

CATS History Model
The overnight process for 1-Mar-2002 (approx. 01:00 on 2-Mar-2002), does the
following:
Makes the existing record on the CATS_NMI_DATA table, (made redundant by

this change), Inactive and updates its MaintUpdtDt with the system date and
time.
The data in an existing MSATS record, including its start date and end date, can
never change, so once the data is superseded by an update, MSATS makes the
original record Inactive.
Creates two new active records:
a. One for the period up to the Day before the Change Request’s Actual
Change Date, containing the superseded data.
b. One for the period starting from the Actual Change Date.
The CATS_NMI_DATA table now contains the records shown in Table 21 on page 153
with the following details:
For the original record, record 1 (ID_ND = 1), MSATS changes:
a. Its MaintUpdtDt to 02-Mar-2002 1:02:00 AM.
b. The MaintActFlg to I, making it redundant.
When MSATS makes active records redundant, it must create new active
records covering the Billing Period the original records covered. Record 1
covered 01-Feb-2002 to 31-Dec-9999.
Now record 1 (ID_ND = 1) is incorrect because its End Date is wrong. But the
data in record 1, including its End Date, cannot change so MSATS creates two
new records, records 2 and 3 (ID_ND = 2 and 3), both with MaintActFlg = A.
Record 2 (ID_ND = 2):
a. Has the original Standing Data and its End Date is the day before the Actual
Change Date. This becomes the active record covering the period from the
record’s start date until 28-Feb-2002. Apart from its End Date, record 2 is a
copy of Record 1.
b. Has its MaintUpdtDt is 31-Dec-9999, because this is the value inserted into
this field whenever a new record is created.
c. Is created to cover the Billing Period from 01-Feb-2002 to 28-Feb-2002.

CATS History Model
Record 3 (ID_ND = 3):
a. Has the Standing Data after the update, with the new TNI Code.
b. Has its StartDate is the Actual Change Date.
c. Has its End Date is the high date because it becomes the active record
covering the period from 01-Mar-2002 into the future.
d. Has its MaintUpdtDt is also 31-Dec-9999.
e. Has the new TNI Code.
f. Covers the Billing Period from 01-Mar-2002 to 31-Dec-9999.
Table 21 CATS_NMI_Data after TNI creation

- Blue shading = fields updated on an existing record.
- Purple shading = fields changed leading to the creation of the two new records.
MAINTACTFLG
Date Date
DLF code
TNI code
ID_ND
1 XXXXXXXX24 VTT2 LELS 01- 31- 02-Mar-2002 I 02-Feb-2002

Feb- Dec- 1:02 1:05
2002 9999
2 XXXXXXXX24 VTT2 LELS 01- 28- 31-Dec-9999 A 02-Mar-2002

Feb- Feb- 1:02
2002 2002
3 XXXXXXXX24 VHTS LELS 01- 31- 31-Dec-9999 A 02-Mar-2002

Mar- Dec- 1:02
2002 9999
Figure 25 on page 154 represents the same record as a diagram with the following
details:
Record 1 is now inactive, so it is only needed if there is an as at Settlements run

for any Billing Period before 02-Mar-2002.

CATS History Model
Record 2 is the active record covering the Billing Period 01-Feb-2002 until 28-
Feb-2002. It is used for any future settlements runs for Billing Periods falling in
that period.
Record 3 is the active record covering the period from 01-Mar-2002 into the
future.
Figure 25 CATS_NMI_Data diagram after TNI code change

CATS History Model
Change the DLF code
The Change Request to change the DLF Code will include the following data:
Field Value
DLFCode LRLS
ActualChangeDate 01-Jul-2002
ActualEndDate Null
The overnight processing for 10-Jul-2002 (approx. 01:00 on 11-Jul-2002) does the
following:
Makes record 3 (ID_ND = 3) inactive and updates the MaintUpdtDt with the
system time and date.
Creates two new active records (ID_ND = 4 and 5):
a. One for the period prior to the Change Request’s Actual Change Date,
containing the old version of the record 3 data.
b. One for the period starting from the Actual Change Date.
The CATS_NMI_DATA table now contains the records shown in Table 22 on page 156,
remember:
The data in an existing record, including its End Date, cannot change. So, record
3 is in correct because from 1 July onwards, the DLF Code is different.
To fix this, MSATS makes the record redundant by changing its MaintActFlg to I
and updating its MaintUpdtDt.
Record 4 (ID_ND = 4) covers the rest of the period originally covered by Record
3 (from 01-Mar-2002 until 30-Jun-2002). It contains the same data originally in
Record 3 apart from the End Date.
Record 5 (ID_ND = 5) is the new record with the new DLF Code, starting from
01-Jul-2002.
Figure 26 on page 157 represents the same data as a diagram.

CATS History Model
Table 22: CATS_NMI_Data with changed DLF code

MAINTACTFLG
Date Date
DLF code
TNI code
ID_ND
1 XXXXXXXX24 VTT2 LELS 1-Feb- 31-Dec- 2-Mar-2002 I 2-Feb-2002 1:05

2002 9999 1:02
2 XXXXXXXX24 VTT2 LELS 1-Feb- 28-Feb- 31-Dec-9999 A 2-Mar-2002 1:02

2002 2002
3 XXXXXXXX24 VHTS LELS 1-Mar- 31-Dec- 11-Jul-2002 I 2-Mar-2002 1:02

2002 9999 1:02
4 XXXXXXXX24 VHTS LELS 1-Mar- 30-Jun- 31-Dec-9999 A 11-Jul-2002 1:02

2002 2002
5 XXXXXXXX24 VHTS LRLS 1-Jul- 31-Dec- 31-Dec-9999 A 11-Jul-2002 1:02

2002 9999

CATS History Model
Figure 26 CATS_NMI_Data diagram with changed DLF code
Retrospective change to the TNI with

an end date
In the previous examples, the Change Requests submitted to change the TNI Code and
then the DLF Code were to change the data from the nominated date into the future.
This example is more complicated and describes:
What happens if you submit a Change Request with a Start and an End Date.
Where another Change Request is submitted to change the TNI to VER2 for the
period 01-May-2002 to 31-Aug-2002.
Figure 27 on page 158 describes the NMI’s active TNI Code after completion of the
Change Request over time.

CATS History Model
Figure 27 Active TNI code over time
Start Date End Date TNI
01-Feb-2002 28-Feb-2002 VTT2
01-Mar-2002 30-Apr-2002 VHTS
01-May-2002 31-Aug-2002 VER2 (New)
01-Sep-2002 31-Dec-9999 VHTS
The Change Request to change the TNI to VER2, submitted on 12-Sep-2002, includes
the following data:
Field Value
TNICode VER2
ActualChangeDate 01-May-2002
ActualEndDate 31-Aug-2002
In the overnight processing for 12-Sep-2002 (approx. 01:00 on 13-Sep-2002), the

following happens:
The two existing active records (ID_ND = 4 and 5) are made inactive.
In addition to the active records covering the period from 01-Feb-2002 to 28-Feb-
2002, not affected by this change, MSATS creates four new active records with
the following Start and End Dates.
Start Date End Date
01-Mar-2002 30-Apr-2002
01-May-2002 30-Jun-2002

CATS History Model
Start Date End Date
01-Jul-2002 31-Aug-2002
01-Sep-2002 31-Dec-9999
The CATS_NMI_DATA Table now contains the records shown in Table 23 below with
the following details:
Because the period covered by the Change Request overlaps two existing active
records: 4 and 5 (ID_ND = 4 and 5), both are made redundant.
Remember, when MSATS makes records redundant, it must create new active
records, covering the entire Billing Period covered by the original redundant
records.
MSATS creates Records 6 and 7 (ID_ND = 6 and 7). Between them, they cover
the original record 4 Billing Period.
Records 8 and 9 (ID_ND = 8 and 9) cover the period originally covered by record
5 (ID_ND 5).
Figure 28 on page 161 represents this data as a diagram.
Table 23 CATS_NMI_Data for active TNI code over time

MAINTACTFL

Date Date
DLF code
TNI code
ID_ND
1 XXXXXXXX24 VTT2 LELS 1-Feb- 31- 2-Mar-2002 I 2-Feb-2002 1:05

2002 Dec- 1:02
9999
2 XXXXXXXX24 VTT2 LELS 1-Feb- 28- 31-Dec-9999 A 2-Mar-2002 1:02

2002 Feb-
2002

CATS History Model
MAINTACTFL
Date Date
DLF code
TNI code
ID_ND
G
3 XXXXXXXX24 VHTS LELS 1-Mar- 31- 11-Jul-2002 I 2-Mar-2002 1:02
2002 Dec- 1:02
9999
4 XXXXXXXX24 VHTS LELS 1-Mar- 30- 13-Sep-2002 I 11-Jul-2002 1:02

2002 Jun- 1:02
2002
5 XXXXXXXX24 VHTS LRLS 1-Jul- 31- 13-Sep-2002 I 11-Jul-2002 1:02

2002 Dec- 1:02
9999
6 XXXXXXXX24 VHTS LELS 1-Mar- 30- 31-Dec-9999 A 13-Sep-2002

2002 Apr- 1:02
2002
7 XXXXXXXX24 VER2 LELS 1-May- 30- 31-Dec-9999 A 13-Sep-2002

2002 Jun- 1:02
2002
8 XXXXXXXX24 VER2 LRLS 1-Jul- 31- 31-Dec-9999 A 13-Sep-2002

2002 Aug- 1:02
2002
9 XXXXXXXX24 VHTS LRLS 1-Sep- 31- 31-Dec-9999 A 13-Sep-2002

2002 Dec- 1:02
9999

CATS History Model
Figure 28 CATS_NMI_Data diagram for active TNI code over time
Changing a NMI’s FRMP

The CATS_NMI_PARTICIPANT_RELATIONS table has significance because it is the
basis for determining the records from any of the five NMI Master tables, participants are
entitled to view.
This example traces the effect of the changes to this NMI’s FRMP with the following
Transactions:
Create the NMI on page 162.
A prospective change to the NMI’s FRMP on page 164.

CATS History Model
A retrospective change to a NMI’s FRMP to correct an error on page 166.
Create the NMI
Part of the process of creating a NMI record includes specifying the mandatory Role
Codes: LR, FRMP, LNSP, MDP, MPB, ROLR, MPC, and RP.
The example in Table 24 below explains what the

CATS_NMI_PARTICIPANT_RELATIONS table looks like when the NMI record is
created as a First Tier NMI. This table has the same key fields as CATS_NMI_DATA:
StartDate, EndDate, MaintActFlg, MaintCreateDt and MaintUpdtDt.
At the start of life for the FRMP NMI record, it looks like Figure 29 on page 163.
Table 24 Changing a NMI’s FRMP table

MAINTACTFLG
Participant NMI Role Start date End date MAINTUPDT MAINTCREATE

ID ID DT DT
RETSOUT XXXXXXXX FRM 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

H 24 P 2002 9999 1:44
NETSOUT XXXXXXXX LNSP 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

H 24 2002 9999 1:44
RETSOUT XXXXXXXX LR 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

H 24 2002 9999 1:44
MDPSOUT XXXXXXXX MDP 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

H 24 2002 9999 1:44
MPSOUTH XXXXXXXX MPB 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

24 2002 9999 1:44
RETSOUT XXXXXXXX ROLR 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

H 24 2002 9999 1:44
MCSOUTH XXXXXXXX RP 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

24 2002 9999 1:44

CATS History Model
MAINTACTFLG
Participant NMI Role Start date End date MAINTUPDT MAINTCREATE
ID ID DT DT
RETSOUT XXXXXXXX MPC 1-Feb- 31-Dec- A 31-Dec-9999 2-Feb-2002

H 24 2002 9999 1:44
Figure 29 Changing a NMI’s FRMP diagram
Figure 5: CATS_NMI_PARTICIPANT_RELATIONS (FRMP only) as at 2 April

Active Record
A Maintupdtdt =
31-Dec-9999
Inactive Record
I Maintupdtdt =
Record MaintCreatedt
date record was

made inactive
Now:
2 Feb 1 RETSOUTH A
Future – i.e.
End Date =
31-Dec-9999
1 Feb
Trading Date – (Start and End Date on Record)

CATS History Model
A prospective change to the NMI’s FRMP
In this example, RETEAST submitted a CR1000 to change the NMI’s FRMP with a
Proposed Date of 30-Mar-2002:
After reading the Meter on 01-Apr-2002, the MDP submitted a Transaction on

02-Apr-2002 to update the original Change Request with an Actual Change Date
of 01-Apr-2002.
The overnight process for 02-Apr-2002 (approximately 01:00 on 03-Apr-2002)

processes the Change of Retailer Transaction with an Actual Change Date of 01-
Apr-2002.
Now, the records on the CATS_NMI_PARTICIPANT_RELATIONS table, where

the Role ID is FRMP, look like Table 25 below.
Other Role IDs exist in this table but for simplicity, only the FRMP is shown.
Figure 30 on page 165 represents the same data a diagram.
Table 25 A prospective change to the NMI’s FRMP table

MAINTACTFL
Participant NMI Role Start date End date MAINTUPDT MAINTCREAT

ID ID DT EDT
ID_NPR
1 RETSOUT XXXXXXXX FRM 1-Feb- 31-Dec- I 03-Apr- 2-Feb-2002

H 24 P 2002 9999 2002 1:04 1:44
2 RETSOUT XXXXXXXX FRM 1-Feb- 31-Mar- A 31-Dec- 3-Apr-2002

H 24 P 2002 2002 9999 1:04
3 RETEAST XXXXXXXX FRM 1-Apr- 31-Dec- A 31-Dec- 3-Apr-2002

24 P 2002 9999 9999 1:04

CATS History Model
Figure 30 A prospective change to the NMI’s FRMP diagram

CATS History Model
A retrospective change to a NMI’s FRMP to correct an

error
In this final example for this NMI, a Retrospective change is submitted to correct an
error.
There was a period when the NMI was with another FRMP, but not recorded in MSATS.
The affected Retailers have agreed to fix the problem on-market:
RETWEST submits a CR1020 on Friday 01-Nov-2002 to change the NMI’s

FRMP for the Billing Period from 01-Mar-2002 to 15-Aug-2002.
They submit the Change Request with a Proposed Date of 01-Mar-2002 and an
Actual End Date of 15-Aug-2002. No Request for Data is sent to the MDP for the
Actual Change Date for this type of Change Request so the Proposed Date of
01-Mar-2002 becomes the Actual Change Date.
The time for overnight processing of this Transaction depends on the Objection
Logging Period allowed for the CR1020.
Assuming there is a five-day Objection Logging Period and there are no

Objections, this Transaction is processed after five full Business Days elapse.
Meaning it completes in the overnight process for 08-Nov-2002 (approx. 01:00
on 09-Nov-2002) with an Actual Change Date of 01-Mar-2002.
Now, the records in the CATS_NMI_PARTICIPANT_RELATIONS Table where
the RoleID is FRMP look like the data in Table 26 on page 167.
Each previously active record is treated individually and split up as required so

record 2 is split in two and Record 3 is split in two.
Figure 31 on page 168 represents the same data a diagram.

CATS History Model
Table 26 A retrospective change to a NMI’s FRMP to correct an error table

MAINTACTFL
Participant NMI Start date End date MAINTUPDT MAINTCREAT
ID DT EDT
ID_NPR
Role ID
G
1 RETSOUT XXXXXXX FRM 1-Feb- 31-Dec- I 03-Apr- 2-Feb-2002
H X24 P 2002 9999 2002 1:04 1:44
2 RETSOUT XXXXXXX FRM 1-Feb- 31-Mar- I 9-Nov-2002 2-Feb-2002

H X24 P 2002 2002 1:20 1:44
3 RETEAST XXXXXXX FRM 1-Apr- 31-Dec- I 9-Nov-2002 3-Apr-2002

X24 P 2002 9999 1:20 1:04
4 RETSOUT XXXXXXX FRM 1-Feb- 28-Feb- A 31-Dec- 9-Nov-2002

H X24 P 2002 2002 9999 1:20
5 RETWES XXXXXXX FRM 1-Mar- 31-Mar- A 31-Dec- 9-Nov-2002

T X24 P 2002 2002 9999 1:20
6 RETWES XXXXXXX FRM 1-Apr- 15-Aug- A 31-Dec- 9-Nov-2002

T X24 P 2002 2002 9999 1:20
7 RETEAST XXXXXXX FRM 16-Aug- 31-Dec- A 31-Dec- 9-Nov-2002

X24 P 2002 9999 9999 1:20

CATS History Model
Figure 31 A retrospective change to a NMI’s FRMP to correct an error diagram

Codes
Codes
This chapter specifies the codes applying when participants submit a Change Request
or seek access to CATS Standing Data.
For valid combinations of read type codes, metering installation type codes, and change
reason codes, see CATS Procedure Principles and Obligations.
You can find codes in the MSATS Web
Codes Portal > Administration > Codes

Maintenance.
maintenance You can download individual tables

from the MSATS Web Portal > Reports
and Alerts > CATS > C1 Data
Replication Resynchronisation Report
AEMO updates the codes tables in
MSATS, as required and if a change is
made sends a message to all
participants in the Data Replication Resynchronisation (C1) Report.
For details about the use of codes. See MSATS Procedures: CATS Procedure
Principles and Obligations.
Table 27 below explains the CATS Configuration Codes and where you can find them.
Table 27 CATS configuration codes
Name Description Table or reference More details
Actual/cumulative Identifies the CATS_REGISTER_IDENTIFIER Page 173

indicator codes type of Meter
Reading
Change Reason Change Request CATS_CHANGE_REASON_CODES Page 174

Codes codes

Codes
Change Request Codes notifying CATS_CR_STATUS_CODES Page 176

Status Codes relevant
participants of
the progression
of a Change
Request
Customer End-User n/a Page 177

Classification Classification
Codes
Customer The level of an n/a Page 177

Threshold Codes End-Use
Customer’s
electricity
consumption
Datastream Status Determine if a MSATS Procedures: CATS Procedure Page 178

Codes Datastream is Principles and Obligations
used in
Settlements
Deregistration Denotes if a CATS_DEREG_CODES MSATS Web

Code participant is Portal >
deregistered Administration >
Codes
Maintenance
DLF Codes Distribution Loss CATS_DLF_CODES Page 179

Factor codes
and their
relevant values
Embedded Identify the CATS_EMB_NET_ID_CODES Page 180

Network Identifier Embedded
Codes Network a NMI
belongs to
Error Codes Error codes and CATS_ERROR_CODES Page 52

their
Page 181
descriptions
used in B2M,
eMDM, and B2B
Field Validation Defines the CATS_DATA_SOURCE_CODES Page 182

Data Source source of the
Codes data

Codes
Jurisdiction Codes Identify the CATS_JURISDICTION_CODES Page 182

Jurisdiction
where a NMI is
situated
Meter Register Denotes the CATS_METER_REGISTER Page 183

Status Codes status of the
Meter
Metering The type of CATS_METER_INSTALL_TYPE_CODES Page 183

Installation Type Metering
Codes Installation as
specified in the
NER
MSATS System Working and MSATS_NATIONAL_CALENDAR MSATS Web

Calendar non-working Portal >
days in the NEM Administration >
System
Calendar
Network Tariff The tariff CATS_NETWORKTARIFF_CODES Page 184

Codes applying to a
Meter Register
NMI Classification Define the flow CATS_NMI_CLASS_CODES Page 185

Codes of electricity at
the Connection
Point
NMI Ranges Participant IDs CATS_NMI_RANGES MSATS Web

and their NMI Portal >
Ranges Administration >
Codes
Maintenance
NMI Status Codes Determine if a CATS_NMI_STATUS_CODES Page 185

NMI is used for
a Retail transfer
Objection Codes Used to object to CATS_OBJECTION_CODES Page 185

Change Request
Parent Name Embedded CATS_EMB_NET_ID_CODES Page 180

Codes Network
Identifier Codes

Codes
Read Type Codes Signal if a Meter CATS_READ_TYPE_CODES Page 186

is read on a
particular
Proposed
Change Date
Register Identifier Indicate if a CATS_REGISTER_IDENTIFIER Page 190

Status Codes Meter Register
is active
Registered List of CATS_PARTICIPANTS n/a

Participant IDs Registered
Participant IDs
Role ID Codes Participant IDs CATS_PARTICIPANT_ROLES Page 190

and their Role
Roles MSATS roles CATS_ROLES B2M rolesPage

11
TNI Codes Transmission CATS_TNI_CODES Page 191

Connection
Point Identifier
codes
Transaction Type MSATS CATS_TRANS_TYPE_CODES Page 192

Codes Transaction
types
Unit of measure Meter Register n/a Page 194

Codes measure Energy
Consumption

Codes
Actual/cumulative indicator
codes
The Actual/Cumulative (ActCumInd)
Code is an attribute of a Meter Register For more details, see MSATS
ID, identifying if the reading is actual or Procedures: CATS Procedure Principles
cumulative (see Table 28 below): and Obligations
Actual: Implies a volume of

energy metered between two
dates.
Cumulative: Indicates a Meter Reading for a specific date.

MSATS requires a second Meter Reading to determine the consumption
between the two read dates.
Table 28 Actual/cumulative indicator codes
Code Description Type
A Actual Interval
C Cumulative Consumption

Codes
Change reason codes

Change Reason Codes govern the population of data in a Change Request. All Change
Requests require a Change Reason
Code:
You can find a list of Change Reason
Identifying the type of Transaction Codes in the MSATS Web Portal >
(for example, Change of Retailer, Administration > Codes Maintenance >
Creation of a NMI, and so on) Change Reason Codes
For specific requirements for each
Defining the reason for the Change Reason Code, see CATS
Transaction. Procedure Principles and Obligations.
For any Change Reason Code, some

elements are defined globally. For
example, they apply in all Jurisdictions. While others are defined separately for each
Jurisdiction (see page 198).
Change Reason Codes are separated into groups of events and contain rules
specifying:
Which participant(s) must provide the data and when.
Which data must exist in the NMI Master Record before the Change Request can
complete.
Change reason code parameters

Each Change Reason Code has the following parameters:
1. The participants permitted to initiate a Change Request.
2. The data items in the Change Request.
3. The data that must already be present in MSATS before the Change Request
can complete.

Codes
4. Whether another participant must supply the exact date of the change. For
example, is the MDP required to supply the date of the Actual Meter Reading to
Complete the Change Request.
5. The date range window.
6. The Roles notified of a Change Request each stage they are notified.
7. The Objection Logging Period.
8. The Objection Clearing Period.
9. The participants who can Object to Change Request and the basis for Objection.
Change reason code rules

The Change Reason Codes control the following information:
Controls Rule
The role / role status that can initiate the CR CR Initiation
Whether it is retrospective Jurisdictional
The number of days into the past or future when the change can be made Jurisdictional
The number of days allowed for objections Jurisdictional
The number of days after when an objected to CR is cancelled Jurisdictional
The valid Objection codes (by NMI classification / Role and Role Status) Objection
The mandatory and optional data provided by the Initiating participant Field
Validation
The mandatory and optional data provided by another party (e.g. LNSP or MDP) Field
before the change can complete Validation

Codes
Controls Rule
Which parties are notified during each stage of the CR lifecycle Notification
Address information
For certain Change Reason Codes, participants must provide data items associated with
address information, as either:
1. Mandatory information, including locality (suburb), state, and postcode.
2. Optional information, including information in the Unstructured Address format,

except for state and postcode information, or other information participants can
provide in the Structured Address format, which is mandatory in this format.
Change request status codes

Code Description Code Description Code Description
CAN Cancelled PEND Pending REJ Rejected
COM Completed PVAL Pending REQ Requested

validation
OBJ Objected

Codes
Customer classification codes

The Customer Classification Codes in Table 29 below relate to an End-Use Customer or
previous End-Use Customer at a single Connection Point where the NMI applies. See
relevant Jurisdictional regulation for full details of Customer Classification Codes.
Table 29 Customer classification codes
Code Description
BUSINESS The End-Use Customer has identified the primary use of the
Connection Point is for business purposes.
RESIDENTIAL The End-Use Customer has identified the primary use of the
Connection Point is for residential purposes.
Customer threshold codes

The Customer Threshold Codes in Table 30 below are used to indicate the level of an
End-Use Customer’s electricity consumption at a single Connection Point where a NMI
applies. They are based on the LNSP’s determination of the annualised consumption for
an End-Use Customer at a single Connection Point.
A Customer Threshold Code is mandatory for all NMIs with a NMI Status Code of A or
D, and a Customer Classification Code of BUSINESS.
Table 30 Customer threshold codes

- These codes are defined in the National Energy Retail Regulations.
Customer Description
Threshold Code
LOW Consumption is less than the Lower Consumption Threshold

Codes
Customer Description
Threshold Code
MEDIUM Consumption is equal to or greater than the Lower Consumption Threshold, but
less than the Upper Consumption Threshold
HIGH Consumption is equal to or greater than the Upper Consumption Threshold
Datastream status codes

Datastreams are Metering Data associated with a Connection Point (NMI). A NMI can
have multiple Datastreams, for example, from one or more Meters or from one or more
channels or Meter Registers, comprising a single Meter. Each Datastream is identified
by a suffix, associated to the NMI. The type is dependent on the Metering Installation
Type.
Datastreams define the data the MDM can expect from each NMI. They are used to
determine if a Datastream is used in the
Settlements process, because the NMI is
Tier 2 or the Metering Data is required as You can find Datastream Status Codes
part of the Load Profile process. In the in MSATS Procedures: CATS Procedure
MDM process, the Datastream Status Principles and Obligations.
Code is.
For example, if the Metering Installation

Type is:
Consumption, the Datastream Type is C (Basic).
COMMSn or MRIM, the Datastream Type is I.
The definition of the Datastream also includes the profile name it is associated with and
if the Datastream is active (if metering data must be supplied).
This information is useful to the Metering Provider (MP), Profile Preparation Service
(PPS), and Basic Meter Profiler (BMP) as they determine the relevant data for use in
creating a Profile or which profile it is applied.

Codes
Datastream Status Codes are part of Standing Data for MSATS. They manage Metering
Data and determine if the Datastream is used in the Settlements process, either
because:
The NMI is Tier 2.
Metering Data is required for the NMI as part of the creating a Load Profile
process.
When required by a Change Reason Code, participants must nominate the Datastream
Status Code for the selected NMI on the Change Request.
If a Datastream Status Code is set to A (active), MSATS uses this flag to indicate
Metering Data is expected for the NMI for:
Aggregation in the Settlements process.
Netting off in the determination of a Profile shape.
DLF codes
Distribution Loss Factors (DLF) Codes are three- or four-character defined by LNSPs.
To avoid duplication of codes, the first character of the code, identifies the LNSP area.
Each DLF code has:
An associated Jurisdiction: The LNSP must obtain the regulatory approval

necessary under the Jurisdictional Rules for their network before requesting
entry in MSATS.
A value: consisting of a leading numeral of 1 or 0, a decimal place, and up to five

numerals following the decimal place.
A description.

Codes
Embedded network identifier

codes
Embedded Network Identifier Codes define the relationships between child and parent
NMIs in an Embedded Network. In MSATS, each Embedded Network is allocated an
Embedded Network Identifier Code:
The parent NMI for the Embedded Network (the one connected to the
Distribution Network) has the Embedded Network Identifier Code recorded in the
Embedded Network ID Parent field.
All direct child NMIs have the same Embedded Network ID Code recorded in the
Embedded Network ID Child field.
If this field is not populated in a NMI record, it is assumed it is not the Child of
any Parent

Codes
Error codes
You can find MSATS and B2B error codes in the following resources. For details, see
References on page 220.
B2B validation module matrix

You use the B2B Validation Module Matrix to use with the Validation Module Software to
ensure B2B message content in your systems aligns with the B2B Procedures.
Data replication resynchronisation (C1)

report
Download the Data Replication Resynchronisation (C1) Report from MSATS Web Portal
> Reports and Alerts > Table > CATS_ERROR_CODES. For help, see Guide to MSATS
Reports.

Codes
Meter data validation matrix

You use the Meter Data Validation Matrix to link B2M and eMDM validation codes to
their respective error codes.
MSATS web portal

You can copy and paste a table of error codes and their messages to a spreadsheet
from MSATS Web Portal > Administration > Codes Maintenance > Error Codes.
SMP validation matrix

The SMP Validation Matrix covers the errors related to receiving and processing
messages by the e-Hub. It also covers the associated NACK errors, descriptions, and
HTTP error codes.
Field validation data source

codes
The Data Source Code is a field in the Field Validation Rules table (see page 197)
defining the source of the data.
Jurisdiction codes
The Jurisdiction Codes:
Identify the Jurisdiction where a NMI is situated.

Codes
Are used to apply Jurisdiction-based business rules.
Is associated with each NMI in MSATS.
Is used in many rules and many validations to enforce correct transactions.
Meter register status codes

The Meter Register Status Codes identify:
The status of the Meter.
The status of the Meter Register.
Metering installation type

codes
The Metering Installation Type Codes identify the type of Metering Installation as
specified in the NER. They indicate if a Meter is manually or remotely read.
This affects the transfer transaction process flow because:
If a Meter is manually read, the Metering Data Provider (MDP) must supply the
Actual Change Date before the transaction completes.
If manually read (MSATS flag is set to Y) and the Change Request Field
Validation Rules are set up to request a date, MSATS sends requests the
nominated party to provide it (for example the new MDP).
For Interval meters, the Manually Read Field, indicates MDPs must supply the
date of change manually. It does not indicate the Metering type. This confirms
the Metering Installation is National Electricity Rules (NER) compliant.
If it is remotely read, the transaction completes at the requested transfer date.

Codes
Allocating
metering
For more details, see DataStreamType
installation codes in Standing Data for MSATS
Consequences of allocating certain

Metering Installation Codes:
If the Metering Installation Type Code is COMMSx, COMMS4C, COMMS4D,

MRIM, MRAM, VICAMI, or UMCP:
a. If the Datastream Suffix is Nx (for example, N1), the DataStreamType must

be I (Interval) or P (P = Profile Area, Sample Meters only).
b. The ProfileName must be NOPROF
2. If the Metering Installation Type Code is BASIC:
a. The DataStreamType must be C.
b. In Victoria, Tasmania, and ACT: The ProfileName must be NSLP.
c. In NSW, QLD, and SA: The ProfileName must be NSLP or the relevant
Controlled Load Profile (CLP).
d. The Datastream Suffix must be numeric (for example, 11).
Network tariff codes

Network Tariff codes represent the tariff applying to a nominated Meter Register. These
are the fees charged by the Distribution Network, passed on to the End-use Customer
by the Retailer.
Network Tariff codes do not support the Settlement of the wholesale NEM. They are
included in MSATS because they can assist Retailers to prepare quotes.
If the NMI is known and the Jurisdiction allows, a new Retailer can view the Network
Tariff Code using NMI Discovery.

Codes
NMI classification codes

NMI Classification Codes:
Define, for retail Connection Points, the volume of energy consumed.
Identify Wholesale, Generator, and Directional Interconnector Connection Points.

Informing MSATS of the flow of electricity at the Connection Point.
Are based on the total annual load of the NMI.
The NMI Classification Codes LARGE and SMALL are used in the CATS Procedure
Principles and Obligations and are parameters for defining Change Reason Codes,
Time Frame Rules, and Objection Rules.
NMI status codes

The NMI Status Codes determine if a NMI is used for a retail transfer. The NMI Status
Code X is the only status not allowing NMI transfers between Retailers.
Objection codes
Participants use Objection Codes to object to a Change Request. They are applied to
each Jurisdiction and each Change
Reason Code in accordance with the
following Objection Rules: See the relevant Jurisdictional
regulation for full details of the NMI
Identify the reason a participant Classification Codes.
has objected to a Change
Request.
Are used within the Objection

Rules table.

Codes
Specify the business rules for The MSATS Procedures: CATS

Objections, under what Procedure Principles and Obligations
circumstances, and by which defines the use of each Read Type
Code with certain combinations of
roles.
Change Reason and Metering
Installation Codes.
Read type
codes
The Read Type codes relate to the Proposed Change Date and are used to signal if a
Meter is read on:
The Next Scheduled Read Date.
A Special Read Date
Or is an Estimated Read.
No Meter Reading is required

Codes
Read type code scenarios

Table 31 below assists participants to understand the consequences and permissible actions for different combinations of Change
Requests, Read Type Codes, and Metering Installation Types. Also, which Read Type Code are used for a Change Request and what
communications between participants, if any, are expected.
Table 31 Consequences and permissible actions for different combinations of Change Requests, read type codes, and metering installation types
Change Read Type Metering Consequences and permissible actions

Reason Code Code Installation Types
1000 NS 4A, 5 & 6 The MDP must advise by Objection Transaction if the Proposed Change Date is not within the NSRD
allowable window (-3/+2 days)
If no Actual Meter Reading was obtained during the NSRD allowable window, the MDP must advise the
reason by an Objection Transaction
The Transfer can only complete on a Day that an Actual Meter Reading is taken
The Actual Change Date submitted by the MDP can only be within the NSRD allowable window
RR 4A, 5 & 6 The Proposed Change Date serves no purpose for this Change Request and Read Type Code
combination, because:
- The MDP is not required to advise if no Actual Meter Reading was obtained
- The Transfer can only complete on a Day when an Actual Meter Reading is taken, which can be any
Day

Codes

SP 4A, 5 & 6 The Transfer can only complete on a Day an Actual Meter Reading is taken. The MDP may perform a
Special Meter Reading on receipt of REQ Notification
If no Actual Meter Reading was obtained during the NSRD allowable window, the MDP must advise the
reason by an Objection Transaction
1010 PR 4A, 5 & 6 If the Proposed Change Date is not the date when an Actual Meter Reading takes place, the MDP must
advise the reason by an Objection Transaction
1040
The Transfer can only complete on a Day that an Actual Meter Reading is taken.
The Actual Completion Date must align with the Proposed Change Date or be within a date range agreed
between the New FRMP and the MDP
The CR 1040 Meter Reading must be a move-in Meter Reading
The CR 1010 is any Meter Reading
102X PR 4A, 5 & 6 If the Proposed Change Date is not the date when an Actual Meter Reading is taken, the MDP advises
the reason by an Objection Transaction
The Proposed date is always the Actual Change Date (e.g. the MDP does not submit the CR 1500 with
an Actual Change Date)
1030 SP 4A, 5 & 6 The MDP may perform a Special Meter Reading on receipt of REQ Notification and a corresponding B2B
Service Order Request
The Transfer can only complete on a Day when an Actual Meter Reading is taken

Codes

All UM UMCP only If no Interval Metering Data is available (i.e. because of an inventory/load data problem) for the Proposed
Change Date, the MDP must advise the reason by an Objection Transaction
The Actual Change Date submitted by the MDP aligns with the Proposed Change Date unless otherwise
agreed between the New FRMP and the MDP
EI (comms 1, 2, 3 & 4 If no Interval Metering Data is available for a Proposed Change Date, the MDP must advise the reason
only) by an Objection Transaction
The Actual Change Date submitted by the MDP aligns with the Proposed Change Date unless otherwise
agreed between the New FRMP and the New MDP

Codes
Register identifier status

codes
For Roles and responsibilities, see
The Register Identifier Status Code in MSATS Procedures: CATS procedure,
principles, and obligations.
Table 32 below indicate if a Meter
Register is active.
Table 32 Register identifier status codes
Code Name Description
C Current Applies when a Meter Register at the NMI is current, i.e. connected to a
Connection Point
R Removed Applies when a Meter Register at the NMI is removed, i.e. not connected to a
Connection Point
Role ID codes
Participants are assigned a relationship to a NMI in a nominated Role, identifying their
responsibility. Each Role associated with a NMI has obligations associated with that
NMI. For example, if a participant is assigned the Role of LNSP, that participant takes on
LNSP responsibilities for the NMI.
For any NMI, you can identify the participant allocated to each Role, for example, who is
the LNSP, FRMP, RP, MDP, and so on.
The NMI Master Record contains each Current Role for each NMI. Each proposed Role
for a NMI is referred to as a New Role.
Codes
The Role ID Codes are used to define:
Which participants can initiate a Change Request.
Which participants can supply data when needed to complete a Change

Request.
The Change Request Status Notification Rules.
The Objection Rules.
The access rights to CATS Standing Data.
TNI codes
Transmission Node Identifier (TNI) Codes in Table 33 below are four-character codes
conceptually representing a Transmission Connection Point (or several at the same
bus), where the Distribution Network meets the Transmission Network.
All NMIs with the same TNI code belong to a part of the Distribution Network receiving
Energy through the same Transmission Connection Point(s).
In CATS, a TNI code consists of a code and a description. Each TNI code is assigned a
Transmission Loss Factor (TLF).
Table 33 TNI codes
The first character of the code identifies the Jurisdiction where the TNI is located:
TNI code first letter Jurisdiction
A Australian Capital Territory
N New South Wales
Q Queensland
S South Australia

Codes
TNI code first letter Jurisdiction
V Victoria
Transaction type codes

Code Transaction name Initiated Description
ACK Acknowledgment MSATS Response to ALL Transactions with an

acknowledgment of receipt
CODE Codes Update MSATS Notification to participants of any changes to codes,

rules, or participant data
CR Change Request Participant A request from a participant to create or update CATS

Standing Data
CRR Change Request MSATS Response to a Change Request with an approval or

Response rejection as it reaches the Pending Validation status
NMID NMI Discovery Participant A request to view CATS Standing Data.

Request
NMIR NMI Discovery MSATS CATS Standing Data information sent to a participant
Response in response to a NMI Discovery Request
NOT Change Request MSATS Notifies a participant of a change in Change Request

Status Notification status according to the applicable Change Request
OBJ Objection Participant An Objection to a Change Request according to the

applicable Objection Rules. Other participants are
informed according to the applicable Change Request
OBJR Objection Response MSATS A response to an Objection with an approval or

rejection. Other participants are informed according to
the applicable Change Request Status Notification
Rules

Codes
Code Transaction name Initiated Description
RDAT Request for MSATS A request to a participant for missing NMI Master
Participant data Record data according to the applicable Field
Validation Rules
RPTD Report Data MSATS The data generated by a report request
RPTR Report Request Participant Report request
WCR Change Request Initiating Cancel a Change Request to Completion. Other

Withdrawal participant participants are informed according to the applicable
Change Request Status Notification Rules
WOBJ Objection Withdrawal Initiating Withdraw an Objection. Other participants are informed
participant according to the applicable Change Request Status
Notification Rules

Codes
Unit of measure codes

Table 34 below defines the units of measure the Meter Register uses to measure
Energy Consumption.
Table 34 Unit of measure codes
Code Description Code Description
PF Power Factor VA VA
A Current - amps KA Current -

kiloamps
MWH Megawatt
hours KV kilo Volts
MVARH Megavar hours MVAH Million VA

Hours
WH Watt hours
VAR var
V Volts
MVAR Megavar
KVARH Kilo var Hours

MW Mega Watts
KWH Kilowatt Hours

W Watts
KVAR Kilo var

KW Kilo Watts
KVA Thousand VA
KVAH Thousand VA
hours
VARH var hours
MVA Million VA
VAH VA hours

Rules
Rules
This chapter specifies the rules applying when participants submit a Change Request or
seek access to CATS Standing Data.
Rules You can find rules in the MSATS Web

Portal > Administration > Rules
maintenance Maintenance.
You can download individual tables
from the MSATS Web Portal > Reports
AEMO updates the following codes and Alerts > CATS > C1 Data
tables in MSATS, sending a message via Replication Resynchronisation Report
the Data Replication Resynchronisation
(C1) Report to all participants when it
makes a change.
AEMO only makes changes after a formal consultation process with participants and the
outcome is a new version of the MSATS Procedures: CATS Procedure Principles and
Obligations, describing all the rules.
Table 35 below explains the CATS Configuration Rules and where you can find them.
Table 35 CATS configuration rules
Name Description Table or reference More

details
Change Request Roles permitted to CATS_CR_INITIATION_RULES Page

Initiation Rules Initiate Change 197
Requests
Change Request Govern the data CATS_TRANS_FIELD_VALIDATION Page

Field Validation required for a Change 197
Rules Request

Rules
Name Description Table or reference More

details
Change Request Govern the Roles CATS_NOTIFICATION_RULES Page

Status notified at each stage 199
Notification of the Change Request
Rules
Jurisdictional Govern Change CATS_JURISDICTIONAL_RULES Page

Parameters Request Initiation 198
NMI Discovery Govern NMI Discovery CATS_DISCOVERY_ACCESS_RULES Page

Field Access Search 199
Rules
NMI Discovery Define if the Site CATS_DISCOVERY_SEARCH_RULES Page

Search Key address is returned in 199
Rules NMI Discovery Search
Objection Rules Govern the use of CATS_OBJECTION_RULES Page

Change Request 200
Objections
Standing Data Govern the CATS CATS_STANDING_DATA_ACCESS_RULES Page

Access Rules Standing Data 201
available for each Role
in each Jurisdiction
Time Frame Govern Proposed MSATS Procedures: CATS Procedure Page

Rules Change Dates between Principles and Obligations 202
the Prospective and
Retrospective Periods

Rules
Change request field

validation rules
The Field Validation Codes are based on Data Source Codes. For any Change Reason
Code, the Field Validation Rules specify:
1. Which fields are mandatory when the Transaction is Initiated.
2. Which fields are optional when the Transaction is Initiated.
3. Which fields must be in the NMI Master Record for the Transaction to proceed
from Pending Validation to Requested.
If they are not present, which Participant must supply them
4. If the Actual Change Date must be obtained from another participant for NMIs
where the Metering Installations are manually read.
If yes, who must supply it.
The obligations on participants arising from the allocation of the Field Validation Rules,
are detailed in the section where the Change Reason Code applies.
Change request initiation rules

1. Initiation Rules are defined for each Change Reason Code.
2. New and Current Roles can Initiate a Change Request.
3. Participants can only enter a New Role on a Change Request.

Rules
Jurisdictional parameters
The type of information, search criteria, and number of results returned from the NMI
Discovery or Standing Data Search is governed by the NMI Discovery Search Key Rules
and the NMI Discovery Field Access Rules, defined by each Participating Jurisdiction.
If there are no NMI Discovery Search Key Rules or NMI Discovery Field Access Rules
defined for a Jurisdiction, it means the jurisdiction does not allow NMI Discovery for their
Jurisdiction.
Jurisdictional updates to the NMI Discovery Access and Search Key Rules are included
in a report that is sent to participants whenever there are changes.
Jurisdictions specify rules to control:
When MSATS can accept a Retrospective Change.
When participants can log an Objection.

If an Objection to the Change of Retailer Transaction is submitted by a
participant within the Objection Logging Period (see page 85), the transfer
cannot proceed until the Objection is cleared. If the Objection is not cleared, the
Change of Retailer Transaction expires (Cancelled) and MSATS notifies all
relevant Participants.
The date range for lodging and clearing objections.
The date range for lodging the Change Request.

The number of days into the future or past the Proposed Change Date can be.
Who can object or Initiate a Change Request Reversal, the reason for the
Objection or Reversal, and the NMI Classification Code appropriate to the
Objection or Reversal.

Rules
NMI discovery field access

rules
A NMI Discovery search returns NMI
information based on the Discovery Field For details about what is returned for
Access Rules. Information included is the multiple matches, see MSATS
Network Tariff Code, TNI code, DLF Procedures: CATS Procedure Principles
and Obligations.
code, Metering configuration. These
rules are governed by the NMIs
Jurisdiction.
NMI discovery search key

rules
The NMI Discovery Search Key Rules define which search parameters participants can
use in a Jurisdiction.
The entire set of CATS and NMI Standing Data for NMI Discovery Searches is the
specified subset of CATS Standing Data.
Separate rules apply to CATS Standing Data available for NMI Discovery Searches and
CATS Standing Data accessed by participants with a NMI relationship.
NMI discovery search multiple match

rules
The NMI Discovery Search Key Rules define how many matches are returned if there
are multiple.
There is a further Jurisdictional rule determining if, in the event of multiple matches, the
address of each matching NMI returned. The rule is set to Yes for all jurisdictions
allowing NMI Discovery.

Rules
Jurisdictions configure the maximum number of records returned for multiple matches.
Currently, all Jurisdictions allow up to 99 matching records.
Change request status

notification rules
MSATS initiates the Notification process when there is a change to the status of a
Change Request, or when an Objection is received or withdrawn.
The Notification Rules determine when notifications are sent. The rules are based on the
following fields:
1. Transaction type
2. Change Request status
3. Change reason
4. Affected Role type
5. Role status
Objection rules
The Objection Rules:
Are applied to each Jurisdiction and each Change Reason Code in accordance
with the Objection Rules.
Specify the way participants can use Objection Codes for each Change Reason
Code and Role.
Apply in every Jurisdiction (unless stated otherwise).

Rules
Standing data access rules

The CATS Standing Data Access Rules specify which items each Role within a
Jurisdiction can access. The items are grouped by the following:
1. Meter Register
2. NMI Data
3. NMI Datastream
4. NMI Participant Relations
5. Register ID
They define:
1. Which Role can initiate a request for NMI Standing Data.
2. Which NMI Standing Data items return for a request.
3. The NMI Data Access Rules may be defined by Jurisdiction.
4. The NMI Standing Data items returned to a FRMP or LNSP in all Jurisdictions on
a successful request. For more details, see Standing Data for MSATS.
To fully understand the standing data access rules, you must understand the CATS
History Model, see page on page 139.

Rules
Metering coordinator standing data

search
Metering Coordinators (MC) can access NMI Standing Data to identify a LARGE NMI
Classification to arrange a change of MC. For details about the NMI Standing Data items
returned to an MC, see MSATS Procedures: CATS Procedure Principles and
Obligations.
Time frame rules

The Time Frame Rules specify if a Jurisdiction, Change Reason Code, and NMI
Classification Code are a valid combination.
A Jurisdiction may specify the Time Frame Rules. Unless stated otherwise, the Time
Frame Rules apply to all Jurisdictions.
The Time Frame Rules specify:
1. If the Change Reason Code can make a Prospective or Retrospective Change.
2. The number of days in the future (Prospective Days) or the past (Retrospective
Days) allowable for the Proposed Change Date.
3. The number of days allowed for Objections (Objection Logging Period),

commencing from the next Business Day after the date the Change Request is
Initiated
4. The number of days after an Objected Change Request is Cancelled (Objection

Clearing Period), commencing from the next Business Day after the date the
Change Request is Initiated.

FAQs
FAQs
Transactions
When does a change request

complete?
A Change Request cannot complete until all conditions below are met:
The proposed date has passed.
The Objection period has passed.
There are no active Objections lodged against it.
It is not awaiting an Actual Change Date from another party.

FAQs
How do I update NMI standing data?

Updates to NMI Standing Data require a Change Request so the process can start.
Change Requests are the main Transactions participants use in MSATS.
How do I create a change request?

MSATS Web Portal > Transactions > Change Requests > New.
How do I find a previous change

request?
In the MSATS Web Portal > Transactions > Change Request – Search interface, enter
the known details: proposed date range (required), Change Request ID, NMI range,
participant details, or request details.
How do I object to a change request?

In the MSATS Web Portal > Transactions > Objections > New interface.
How do I find a previous objection?

In the MSATS Web Portal > Transactions > Objections – Search interface, enter the
known details: Date Range (required), Change Request ID, Objection Raised By,
Objection Code, or NMI Range.

FAQs
How do I find a previous notification?

In the MSATS Web Portal > Transactions > Notifications – Search interface enter the
known details: Notification Date (required), Change Request ID, Change Request
Status, Role Being Notified, or NMI Range.
What do I do if I receive a request for

data?
Either read the message in your Participant Outbox or in the MSATS Web Portal >
Transactions > Request for data search, click Respond and create new Change
Request with the data.
How do I make changes to a large

number of Tier 1 NMIs?
You can use the Bulk Data Tool (BDT) instead of change requests in the MSATS Web
Portal > Transactions > Bulk Updates.
Inbox, Outbox, and Archive
Why didn’t I receive my zip file?

Check your Participant Inbox to see if you have reached the maximum allowed number
of files sent from MSATS. If yes, you need to acknowledge them so MSATS can send
more.

FAQs
Each Transaction Group or Transaction Priority (for example, cats and nmidh files),
cannot receive more than 30 files at a time. Once you receive 30 files, MSATS stops
sending more until you or your system acknowledge the files you have.
Sometimes, the number is higher than 30 files because the MSATS Batch Handlers lose
contact with the database (for example, if there is a fail-over because the database is
unavailable). When this happens, the Batch Handler starts counting again so you could
get an additional 30 files.
Why are files not picked up from my

inbox?
Delete any zip files from your Participant Inbox corresponding to ACK files so MSATS
can process new .zip files.
If you allow more than 20 ACK files to accumulate in your Participant Outbox (for
example, MSATS has acknowledged 20 files you have not deleted from your Participant
Inbox), it stops processing files you submit to your Participant Inbox.
Why are the ACK files in my inbox not

processed
Starting from the oldest ACK file in your Participant Inbox, check if they are valid. If you
find an invalid one you must remove it so MSATS can continue processing the next one
in the queue. Then write a valid ACK file to replace the original invalid one.
MSATS stops processing the ACK files in your Participant Inbox if it detects an ACK file
it cannot read (for example, the ACK file is not well-formed). Until the invalid ACK file is
cleared MSATS cannot process ACK files.

FAQs
Why are zip files no longer in my

outbox
Once you acknowledge zip files received
from MSATS in your Participant Outbox,
the files are copied into your Participant If you
You can
submitted
use the theDayzip
search
Download
by Batch,
menu to
check thezip
Error
all files
Code inin
the
the
Participant
Event tag.
Archive. You can drill through the
Archive and save them to your local
Participant Archive by years, months, computer.
and days.
Files are deleted from the Participant

Archive after approximately 13 months.
You can access the Participant Archive from the MSATS Web Portal > Data Load Import
menu. If you cannot see the menu item, contact your company’s Participant
Administrator for access rights.
For help with user access rights, see Guide to User Rights Management.
NMI search
My search only found one NMI. How do

I know if it is a match?
If your search only returns one record that does not contradict what the End-use
Customer provided, you can assume it is the correct record. Otherwise you cannot be
certain you have found the correct NMI. For help, see Table 36 on page 208.

FAQs
Table 36 Common NMI search errors
Error Explanation
n/a You have 1 record returned but it may not be an exact match to your search criteria.
MSATS may have used the wider address search because it couldn’t find an exact address
match for the criteria you provided
For help, see I didn’t get an exact match. What do I do now? below
1404 No records matched your search criteria using either an exact address search or a wider
address search
1410 There are more NMIs matching your search criteria, but you exceeded the Jurisdictional limit of
99 records.
I didn’t get an exact match. What do I do now? below
I didn’t get an exact match. What do I

do now?
If you received a message advising there is more data available, but you have reached
the Jurisdictional limit (99), you must find a way to refine your search.
Look at the returned data to see if it contains any clues, for example:
In Figure 32 on page 209, a search for 6060 High St returned one record with a
message advising there are more matching records.
Notice there is a Flat Number and a Flat Type suggesting you need to check if
the address you are looking for is a flat.
2. If you entered a house number and street address and one record returns with a
message advising there is more than one record matching your address,
perhaps your address is a suffix, for example: 60A.
3. It is possible you cannot not uniquely identify your NMI. If you’ve exhausted all
options and are certain the address is correct see, Is the NMI I’m looking for
nearly impossible to find?

FAQs
Figure 32 returned search criteria
Is the NMI I’m looking for nearly

impossible to find?
Yes, and there are several reasons why:
Some NMIs in office towers are created with a value in the Floor Type but no
Floor Number in the Location Descriptor field.
For example, for address 96 Elizabeth St, the Floor Type is FL, other Location
Descriptor stored data is FL 2 RM 224. So, to find the NMI, you must know how
the data is stored.
Searching for 96 Elizabeth St only provides a match.
2. Some addresses have a Street Name but no Street Number.
There may be supplementary information to identify the NMI in the Location

Descriptor field, but it is impossible to find unless it is the first one returned when
you search with only the street name and no address.
3. Some data was entered incorrectly during the original data load with a forward
slash (/) in the Flat Number field, for example: 6/1. You cannot find these NMIs
using NMI Discovery because:
a. You cannot enter 6/1 in the Flat Number field.
b. If you enter 6 and 1 in the Flat and Floor Number fields, the data is not in
those fields.

FAQs
4. Sometimes, it is impossible to find a NMI with an Unstructured Address because

the Structured Address fields do not allow you to enter text exactly matching
what is stored in the Unstructured Address fields.
What if I don’t get any matches?

If you see the message 0 records found or using Batch, you get the Error 1404,
meaning: no data found, complete the steps below.
Eventually, you should get at least one match. If it is not exact, the data returned may
provide some hints, for example, the record returned may have a flat or unit number.
You can then add back your original search criteria a bit at a time. If you find a problem
(like no records returned), you can assume there is something wrong with the latest
criteria you entered.
If you still can’t find a match (for example, with only the street name, postcode, and
jurisdiction or the street name, locality, and Jurisdiction), either the information the End-
use Customer provide is incorrect or you might be working with an unusual Unstructured
Address.
Steps to try if you don’t get matches

Check your spelling is correct, for example:
− Is the street name spelt correctly?

− Have you spelt the name correctly?
− Is the address Unstructured?
2. Check Australia Post Address Data to confirm the Locality and the Postcode
spelling.
3. Check the White Pages to confirm the End-use Customer provided the correct
address spelling.
4. Try removing some criteria (the minimum data to supply is the State and either
Locality or Postcode), for example:
− Street Type

FAQs
− Flat/Unit Type or Floor/Level Type (check you have the number and type
correct).
− If all the above fails, remove firstly: The Locality and then the Postcode
(MSATS uses adjacent postcodes if no match is found).
Is the address I’m searching for

unstructured?
How can you find an Unstructured Address when you must complete the Structured
Address fields?
Most MSATS addresses are Structured, but there are some Unstructured. Most are in
country locations.
Even if you only complete the Structured Address fields MSATS looks in both the
Structured and Unstructured fields. Initially, it searches the Structured Address fields
and if there is no match, it searches the Unstructured Address fields.
MSATS has three Unstructured Address fields and there may be data in any or all of
them. MSATS takes the values entered in these fields and combines them:
Flat Number Location Descriptor Street Name

Floor Type House Number Street Type
Floor Number House Number Suffix Street Suffix
Building Name Lot Number
Then, uses the combined value to search each of the three Unstructured Address fields,
including the data you entered for Locality, Postcode and State. (for these three fields
MSATS does not search the Unstructured Address). This works well if the Unstructured
Addresses has values in Locality, Postcode, and State.
Often, the Locality in Unstructured Address fields is not populated as a separate field so
is only part of the Unstructured Address. Including it in the search causes the search to
fail.

FAQs
For example, if you entered the data in Table 37 below.
Table 37 Search criteria
Field Value Field Value Field Value
House Number 105 Street Type St Postcode 2800
Street Name Sunny Locality Orange State NSW
After completing a Structured Address search, MSATS searches for:
NMIs with the value 105 Sunny St in one of the Unstructured Address fields (it
does an Oracle-like ‘%105 SUNNY ST%’ search).
2. Orange in Locality.
3. 2800 in Postcode.
4. NSW in State.
If you think an address is unstructured:
Try removing Locality from your search and just enter the postcode in the
Postcode field.
Start with a broad search and gradually add more criteria.

FAQs
What are valid values for address

fields?
Using the File Interface, you must use
the correct enumeration values in
Structured Address fields. Otherwise You can check valid values in the Index
of Schema Releases on AEMO’s
your Transaction doesn’t pass validation
website.
and is rejected. See Address fields
requiring valid values below.
Doing a NMI Discovery Search using the

MSATS Web Portal means you don’t have to worry about valid codes because you
select them from the drop-down lists.
Address fields requiring valid values

Flat Type
Floor or Level Type
State Code
Street Suffix
Street Type

FAQs
This is an example for the AustralianFloorOrLevelType (Floor or Level Type). The valid
values in this example are B, FL, G, L, LG, M or UG.
- <xsd:simpleType name=‘AustralianFloorOrLevelType’>
- <xsd:annotation>
<xsd:documentation>Purpose - Define floor or level types as per Australian Standard
AS4590</xsd:documentation>
</xsd:annotation>
- <xsd:restriction base=‘xsd:string’>
<xsd:enumeration value=‘B’ />
<xsd:enumeration value=‘FL’ />
<xsd:enumeration value=‘G’ />
<xsd:enumeration value=‘L’ />
<xsd:enumeration value=‘LG’ />
<xsd:enumeration value=‘M’ />
<xsd:enumeration value=‘UG’ />
Does it matter if I use upper or lower

case?
No, data in MSATS address fields is stored in upper case, but if you use lower case,
MSATS converts it to upper case.
Why must I select a state after I’ve

already chosen the Jurisdiction?
The Jurisdiction is used to check the NMI Discovery Key Search Rules and NMI
Standing Data Access Rules to determine which of the following search options you can
select from (depending on the Jurisdiction, different options display on the NMI
Discovery Search interface):
Address
DPID
Meter Serial ID

FAQs
The State is part of the NMI’s address, so the value is matched against the State field in
the CATS_NMI_DATA table. It is completely different information.
Why do I get the

error ‘No access You may
can see
Discovery
Meter
see this
Register
multiple
Search
erroritems
andType
in a NMI
for the
MDM1 Datastream
or 2.
rule’? fields because a NMI can have multiple
Meters and multiple Datastreams.
This means either:
You are searching for a NMI in a Jurisdiction not allowing NMI Discovery.
The Participant ID you are logged on as is not entitled to do NMI Discovery.

Currently, only FRMPs, LNSPs, or ENMs can do NMI Discovery.
What data can I see for NMID2?

Currently, NMI Discovery is available for NMIs in all Jurisdictions. Table 38 below
describes the data returned for the selected NMI.
The NMI Discovery Field Access Rules define what you can see. Jurisdictions can either
increase or decrease the types of data available. For more details, see NMI discovery
field access rules on page 199.
Table 38 NMID2 information

- * Items with an asterisk always display. Other items display if there is stored data in MSATS.
Element Data
NMI NMI* FLATNUMBER LOTNUMBER
NMICLASSCODE* FLATTYPE POSTCODE
NMISTATUSCODE* FLOORNUMBER STATE

FAQs
Element Data
TNICODE* FLOORTYPE STREETNAME
DLFCODE* HOUSENUM STREETSUFFIX
EMBNETPARENT HOUSENUMSUFFIX STREETTYPE
EMBNETCHILD JURISDICTIONCODE UNSTRUCTUREDADDRESS1
LNSP* LOCALITY UNSTRUCTUREDADDRESS2
BUILDINGNAME LOCATIONDESCRIPTOR UNSTRUCTUREDADDRESS3
Meter METERINSTALLCODE NEXTSCHREADDATE METERSERIAL

Register
ADDLSITEINFO
MDM SUFFIX PROFILENAME STREAM STATUS CODE

Datastream
DATASTREAM TYPE
Register METERSERIAL REGISTERID DIAL FORMAT

Identifier
NETWORKTARIFFCODE TIME OF DAY CONTROLLED LOAD
NTADDLINFO MULTIPLIER ACT/CUMID
What data can I see for NMID3?

The Standing Data items returned for a NMI Discovery Search 3 are explained in the
CATS Procedure Principles and Obligations.

Terms
Terms
For a list of terms used throughout this guide, see:
Retail Electricity Market Procedures – Glossary and Framework
Guide to MSATS and B2B Terms
NER terms
Billing Period Estimated Metering Data Metering Data Provider
Business Day(s) Final Aggregation Metering Installation
Child Connection Point(s) Financially Responsible Minimum Services

Market Participant Specification
Connection Point(s)
High Voltage NEM
Day
Interval Metering Data NERL
Directional Interconnector
Large Customer NERR
Distribution Network(s)
Local Network Service Net System Load Profile
Provider
Eastern Standard Time
Network
Local Retailer
Embedded Network
Connection Network Connection
Market
Embedded Network Network Service Provider

Manager Meter(s)
NMI
Embedded Network(s) Metering
NMI Standing Data

Energy Metering Coordinator
Parent Connection Point

Energy Ombudsman Metering Data

Terms
Participating Jurisdiction RoLR Trading Day
Profile Settlements Transmission
Registered Participant(s) Settlements Ready Data Transmission Lines
Retailer(s) Settlement Statements Transmission Network(s)
Retail Customers Small Customer Transmission Node
Retail Market Procedures Small Customer Metering Voltage

Installation

Needing Help
Needing Help
Support Hub
For non-urgent issues, normal coverage is 8:00 AM to 6:00 PM on weekdays, Australian
Eastern Standard Time (AEST).
IT assistance is requested through one

AEMO recommends participants call
of the following methods: AEMO's Support Hub for all urgent
issues.
Phone: 1300 AEMO 00 (1300
236 600)
Contact Us form on AEMO’s

website
Information to provide
Please provide the following information when requesting IT assistance from AEMO:
Your name
Organisation name
Participant ID
System or application name
Environment: production or pre-production
Problem description
Screenshots

References
References
Australia post
Australia Post Address Data: Access to a database of over 13 million Australian
addresses.
AEMO website
You can find references in the following places on AEMO’s website.
aseXML standards
aseXML Guidelines: Guidelines for the Development of A Standard for Energy
Transactions in XML (aseXML) provides guidance and advice for developing
aseXML documents (Messages and Acknowledgments).
aseXML Schemas: Index of schema releases.
Business-to-business procedures
SMP Validation Matrix: covers the errors related to receiving and processing messages
by the e-Hub.
Guide to Transition of aseXML: provides information and guidance for participants

transitioning to another B2M or B2B asexml schema.

References
Electricity system guides > participant

IT interfaces
Connecting to AEMO’s Electricity IT Systems: Explains the IT interfaces available for
electricitiy participants and how to connect to them.
Guide to AEMO’s e-Hub APIs: Provides details about using AEMO’s e-Hub as an
interface to communicate information with AEMO. It assists Wholesale electricity
and gas participants developing their own APIs.
Guide to Electricity Information Systems: Provides guidance for Registered Participants

and interested parties about AEMO's participant electricity market systems.
Guide to NEM Retail B2M APIs: Explains how to build B2M retail metering APIs.
Market Settlement and Transfer

Solutions
B2B Validation Module Matrix: Links validations with respective error codes for B2B.
Guide to MSATS and B2B Terms: Assists readers to understand the terms used in the
retail electricity market procedures and MSATS.
Guide to Participant Batcher Software: Covers the setup and use of the MSATS
Participant Batcher software.
Guide to User Rights Management: Explains the user rights management functions in
AEMO's Market Systems.
MSATS Ombudsman Enquiry User Interface Guide: Provides guidance for using the
MSATS Ombudsman Enquiry system.
MSATS Participant Batcher Software: Sample software to exchange data with MSATS
using the File Interface.

References
Technical Guide to Bulk Data Tool in MSATS: Describes the Bulk Data Tool (BDT), the
relationship between aseXML data and the processing of that data.
Retail and metering

Retail Electricity Market Glossary and Framework: assist participants of the Retail
Electricity Market to understand the overall framework. It also contains a list of
terms used in the Retail Electricity Market Procedures and a full list of NEM
procedures, guidelines, and documents.
Metering procedures, guidelines and

processes
MDM File Format and Load Process: Specifies the Meter Data Management (MDM)
Format used by MDPs for the provision of Metering Data to AEMO.
Meter Data File Format Specification NEM12 & NEM13: specifies the Meter Data File
Format (MDFF) used by MDPs for the provision of Metering Data.
Meter Data Validation Matrix: Links validations with respective error codes for B2M and
eMDM.
Coming soon
Guide to eMDM: Describes the Enterprise Meter Data Management System.
Guide to MSATS Reports: Explains MSATS reports and their data.

Index
Index
1 API e-Hub, 19
1st level validations, 108 aseXML, 17
2 aseXML schemas, 18
AustralianFloorOrLevelType, 214
2nd level validations, 108
A B
B2B message content, 181

Accepted objection, 86
B2B Procedures, 181

Accepted objection response, 86
B2B schema, 18
ACK deletion - batch, 124
B2B Validation Module Matrix, 181

ACK deletion - web portal, 125
B2M and eMDM validation codes, 182

ACK deletion -API, 124
B2M aseXML schema, 16

ACK files, 115
B2M functionality, 9
Acknowledgement – API, 123
B2M functionality, interfaces, and protocols, 14

Acknowledgement - batch, 123
B2M message exchange, 17

Acknowledgement - web portal, 123
B2M participant interfaces, 12

acks & zips, 14
B2M roles, 11
ActCumInd, 173
B2M schema, 18
Actual change date, 61
Batch, 18
Actual End Date, 148
Batch File Interface, 24

Address (without DPID), 95
Batch files, 24
Address field tips, 99
Batch notifications, 78
Address information, 176
Batch Participant System Status, 37

Administration, 14
Batch to Participant File Server, 24

Allocating metering installation codes, 184
Batch to Web Portal, 22

API and Batch change request edit, 68

Index
Bulk data tool (BDT), 38 Change request withdrawal, 65
Bulk transactions, 38 Change request without a data request, 70
Bundling, 131 Change requests, 42
C Change Requests, 17
Changing a NMI’s FRMP, 161

Cancelled status (CAN), 49
Changing NMI standing data, 146

CATS, 10
Changing the CATS_NMI_DATA table, 148

CATS configuration codes, 169
Changing your Participant ID and Participant User

CATS configuration rules, 195
password(s), 15
CATS Transactions used by AEMO, 106
Codes maintenance, 169
Change of retailer, 61
Codes update, 137
Change reason code parameters, 174
Common NMI discovery errors, 100
Change reason code rules, 175
Common NMI search errors, 208
Change reason codes, 174
common Retrospective Change problem, 62
Change request completion, 61
Completed status (COM), 49
Change request errors, 52
Concurrent retail transfers, 65
Change request example, 50
Connection Point transfers, 17
Change request field validation rules, 197
Consumer Administration and Transfer Solution
(CATS), 10
Change request initiation rules, 197
Consumption Meter Profiling, 10

Change request life cycle, 43
Creating a report request, 36

Change request response, 131
Creating and submitting batch transactions, 29

Change request response example, 132
Customer classification codes, 177

Change request role status, 50
Customer threshold codes, 177

Change request rules, 43
Change request status, 45 D

Change request status codes, 176 Data Aggregation, 10
Change request status notification, 137 Data Replication Resynchronisation (C1) Report, 181
Change request status notification rules, 200 Data Source Code, 182
Change request with a data request, 69 Datastream status codes, 178

Index
Dayzip download, 14 H
Delivery, 12
Hokey-Pokey Protocol, 29
Different field names, 145

How do I create a change request?, 204
Direct Loading, 24
How do I find a previous change request?, 204
DLF codes, 179

How do I find a previous notification?, 205
Does it matter if I use upper or lower case?, 214

How do I find a previous objection?, 204
DPID, 95, 99
How do I make changes to a large number of Tier 1
NMIs?, 205
E
How do I object to a change request?, 204
Editing a batch change request, 30
How do I update NMI standing data?, 204
Editing a rejected change request, 74
How MSATS handles the edited change request, 68
Editing change requests, 67
HTTP error codes, 182
Editing the Change Request proposed date, 69
I
Embedded network identifier codes, 180
I didn’t get an exact match. What do I do now?, 208
eMDM, 10
Increasing limits, 122

end-of-day process, 147
Initiated status, 47
Enterprise Metering Data Management System
(MDM), 10
Interactive, 18
Error codes, 181

Interactive Loading, 22
F Is the address I’m searching for unstructured?, 211
Field validation data source codes, 182 Is the NMI I’m looking for nearly impossible to find?,
209
File Interface FTP, 24
J
File interface rules, 24
Jurisdiction codes, 182

File name format, 25
Jurisdictional parameters, 198
File upload, 22
Finding a NMI tips, 99 L
Finding why MSATS rejected your transaction, 72 Locality or post code, 100
Floor or Level Type, 214 M

FTP, 24
Mandatory NMI standing data, 141

Index
MDFF, 15 NMI Discovery search, 15
MDMF, 15 NMI discovery search 1 – NMI discovery, 95
MDMT, 14 NMI discovery search 1 returned information, 96
Messages – acks & zips, 14 NMI discovery search 2 - obtain standing data, 97
Meter Data Validation Matrix, 182 NMI discovery Search 3 - obtain role data, 97
Meter register status codes, 183 NMI discovery search key rules, 199
Meter Serial ID, 95 NMI Discovery Search Key Rules, 199
Metering coordinator standing data search, 202 NMI discovery search multiple match rules, 199
Metering data, 15 NMI discovery type 1, 35
Metering installation type codes, 183 NMI discovery type 2 (obtain standing data), 35
MSATS B2M functionality, 9 NMI discovery type 2 response example, 135
MSATS to participant, 107 NMI Discovery type 3 (Obtain Role Data), 36
MSATS Web Portal, 21 NMI enquiry reports, 15
MSATS web portal change request edit, 67 NMI information, 15
MSATS zip file deletion, 127 NMI master, 102
MTRD, 14 NMI master data in notifications, 77
My search only found one NMI. How do I know if it is a NMI master report response, 136
match?, 207
NMI metering installation, 143
N
NMI register identifier, 143
NACK errors, 182
NMI relationship rules, 103
Network tariff codes, 184

NMI search FAQs, 207
New NMI Setup Error, 98
NMI standing data, 142
NMI classification codes, 185

NMI standing data master tables, 141
NMI creation, 62
NMI status codes, 185
NMI datastreams, 143

NMID2 information, 215
NMI discovery field access rules, 199
NMIs and their associated relationships with
participants, 15
NMI discovery response, 133
NNS, 98
NMI discovery response example, 134
NOACC objection, 84

Index
Notification role status, 81 Participant file server inbox to MSATS web portal, 21
Notifications, 17, 76 Participant file server outbox to MSATS web portal, 22
O Participant Hub Queue, 14
Participant Inbox, 14
Objected status (OBJ), 48
Participant information, 16
Objection codes, 185
Participant Outbox, 14
Objection logging period, 85
Participant role relationship, 142

Objection logging prerequisites, 84
Participant User Rights, 14

Objection notifications, 88
Participants reports on ombudsman enquiries, 15

Objection response, 133
Passwords, 15
Objection Response example, 133
Pending status (PEND), 48

Objection rules, 200
Pending validation status (PVAL), 47

Objection summary, 84
Processing the updates to master records, 147

Objection validation, 85
profile information, 16
Objection withdrawal, 33, 89
Profile preparation, 16
Objections, 17, 82
Profile Preparation Service, 10

Obtain the rejection reason, 73
Proposed versus actual change date, 146

Obtain the request and Transaction ID, 72
Prospective and retrospective Change Request

Ombudsman, 15
examples, 148
Other NMI standing data, 141
Prospective change requests, 64
OTR, 98
Protocol, 12
overnight process, 147
Q
P
Queue Monitoring, 16
participant administrators, 14
R
Participant API gateway to AEMO e-Hub, 20
RDAT, 138
Participant Archives, 14
Read type code scenarios, 187
participant contacts, 16
Read type codes, 186
Participant file server, 20
reason of NNS, 98
Participant File Server, 24

Index
reason of TRI, 98 Settlement data, 17
Receipt IDs, 115 SMP Validation Matrix, 182
Receiving an RDAT, 92 Standing data access rules, 201
Register identifier status codes, 190 Standing Data management, 17
Rejected objection, 87 Standing data requirements for a Tier 2 Site, 61
Rejected objection response, 87 Stop file rules, 121
Rejected status (REJ), 47 stop files, 121
Rejection avoidance, 71 Streamlined change requests, 65
Rejection reasons, 70 Street type, 100
Report data, 137 Structured and unstructured addresses, 95
Reports and alerts, 16 Subsequent change request validation, 109
Request for data transfer, 138 T

Requested status (REQ), 48
three types of NMI Discovery, 94
requests for data, 17

Time frame rules, 202
Response, 129
TNI codes, 191
Retailer of Last Resort, 138

Transaction ACK file, 116
Retrospective change requests, 62

Transaction format, 26
Retrospective change to the TNI with an end date,

Transaction limits, 17, 121
157
Transaction type codes, 192
Retrospective changes with an end date, 62
Transactions, 14, 17
Retrospective notification example, 80
Transferred In Error, 98
Retrospective notifications, 80
TRI, 98
Retrospective or prospective change, 148
Two-stage batch validation process, 114
Role ID codes, 190
Rules maintenance, 195 U
User rights access, 18

S
SAB, 98 V
Set participant, 38 Validation checks, 109

Index
Validation Module Software, 181 Why are files not picked up from my inbox?, 206
Validations explanations, 111 Why are the ACK files in my inbox not processed, 206
View information categories, 105 Why are zip files no longer in my outbox, 207
View outstanding messages and acks, 129 Why didn’t I receive my zip file?, 205
Viewing limits, 122 Why do I get the error ‘No access rule’?, 215
W Why must I select a state after I’ve already chosen the

Jurisdiction?, 214
Web portal notifications search, 81
WIGS, 10
What are valid codes for address fields?, 213
Withdrawing a batch change request, 32
What data can I see for NMID2?, 215
Withdrawing a batch objection, 33
What data can I see for NMID3?, 216
Z
What do I do if I receive a request for data?, 205
Zip deletion – API, 125
What if I don’t get any matches?, 210
Zip deletion - batch, 125
When does a change request complete?, 203
Zip deletion - web portal, 126
Wholesale, Interconnector, Generator and Sample
(WIGS), 10

Technical Guide To MSATS

Uploaded by

Copyright:

Available Formats

Technical Guide To MSATS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Technical Guide To MSATS

Uploaded by

Copyright:

Available Formats

Technical

© 2020 Australian Energy Market Operator Limited.

About MSATS B2M................................................................................................................. 9

Participant CATS Transactions ............................................................................................ 41

AEMO CATS Transactions................................................................................................. 106

CATS History Model ........................................................................................................... 139

Codes ................................................................................................................................. 169

© AEMO 2020 | Technical Guide to MSATS iii

Needing Help ....................................................................................................................................... 219

© AEMO 2020 | Technical Guide to MSATS iv

References .......................................................................................................................................... 220

Index ................................................................................................................................................... 223

© AEMO 2020 | Technical Guide to MSATS v

New participants building their IT systems to interact with AEMO’s.

Anyone wanting an understanding of MSATS functionality, business rules, and

© AEMO 2020 | Technical Guide to MSATS 6

Metering procedures, guidelines and processes

What’s in this guide

Chapter 3 on page 38 describes participant CATS Transactions and guidelines,

Chapter 4 AEMO CATS Transactions on page 106 describes AEMO CATS

© AEMO 2020 | Technical Guide to MSATS 7

How to use this guide

Where there is a discrepancy between the Procedures and information or a term

This guide is written in plain language for easy reading.

Text in this format indicates a reference to a document on AEMO’s website.

Text in this format indicates a link to related information.

Text in this format is an action to complete in the Markets Portal interface.

References to time are Australian Eastern Standard time (AEST) unless

© AEMO 2020 | Technical Guide to MSATS 8

What is MSATS B2M?

Participant administration and User Rights Management (URM)

Consumer Administration and Transfer Solution (CATS)

Wholesale, Interconnector, Generator and Sample (WIGS)

Enterprise Metering Data Management System (eMDM)

Figure 1 MSATS B2M functionality

© AEMO 2020 | Technical Guide to MSATS 9

Consumer Administration and Transfer

Wholesale, Interconnector, Generator

Enterprise Metering Data Management

© AEMO 2020 | Technical Guide to MSATS 10

Who can use MSATS B2M?

Embedded Network Managers (ENM)

Financially Responsible Market Participant (FRMP)

Local Network Service Provider (LNSP)

Local Retailer (LR)

Metering Coordinator (MC or RP in MSATS)

Metering Provider - Maintenance (MPB)

Metering Provider – Data Collection (MPC)

Metering Data Providers (MDP)

Network Service Provider (NSP)

Second Network Service Provider (NSP2)

© AEMO 2020 | Technical Guide to MSATS 11

How you use MSATS B2M

Connecting to AEMO’s Electricity IT Systems

Guide to Electricity Information Systems

API Pull Participant API Gateway

API Participant API Gateway

© AEMO 2020 | Technical Guide to MSATS 12

FTP Participant File Server > Participant ID > Outbox