How MSATS updates the NMI master tables

Changing NMI standing data

Participants entitled to change data in any of the five NMI See Relevant Rules or Procedures Master tables, for example, the LNSP if it is the TNI Code Transmission Node Identity: A four character alpha-numeric code used to identify a virtual transmission node or transmission network connection point. or the new Retailer See Relevant Rules or Procedures if it is a change of FRMP Financially Responsible Market Participant, usually a retailer, Generator, Market Customer or a Market Small Generator Aggregator, identified in respect of a connection point. Responsible for dealings with AEMO in relation to a specific load., must submit a Change Request A transaction submitted by participants in MSATS whenever they want to create or update data held in MSATS..

Proposed versus actual change date

When submitting a Change Request The way information is returned from an API. In a request, the client provides a resource URL with the proper authorization to an API server. The API returns a response with the information requested., the Initiator The participant initiating a B2B Interaction. specifies a Proposed Date. This date is the start of the Billing Period The 288 periods from 4:30 am to 4:00 am. when the new version of NMI Standing Data See National Electricitiy Rules applies. But the date when it applies is the Actual Change Date The effective date of changes specified in a Change Request. The same date as the FromDate in a C4 Report and the Start Date in MSATS interfaces displaying NMI master data. on the Change Request.

Sometimes, for example a Change of Retailer Transaction See Relevant Rules or Procedures – CR Change Request 1000 and 1030, another participant (the MDP Meter Data Provider. An organisation which installs, commissions, gathers, and verifies data remotely from meters in the National Electricity Market (NEM). in this example) is requested to supply the Actual Change Date, which is usually the date of an Actual Meter Reading The accumulated metering data or interval metering data collected from a meter either manually or by remote acquisition (as applicable).. 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 Market Settlement and Transfer Solutions. The procedures published by AEMO under clause 7.2.8 of the National Electricity Rules, which include those governing the recording of financial responsibility for energy flows at a connection point, the transfer of that responsibility between market participants, and the recording of energy flows at a connection point. inserts the Proposed Date into the Actual Change Date field when it does its initial Change Request validation.

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.

Overnight process

The overnight process (BU500) completes all Change Requests satisfying these three criteria:

  1. The Objection Logging Period is complete.
  2. There are no outstanding Objections.
  3. Pending CRs have reached their Actual Change Date.

For example, if the Actual Change Date on a Change Request is 08-Mar-2002 and the Objection Logging Period The number of business days available to a participant for entering an Objection in MSATS. 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 The NMI master record with an end date set to the year 9999., 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.

Retrospective or prospective change

Depending if it is a Retrospective or Prospective Change A change to a NMI record that takes effect on a date after the date the Change Request is submitted., the Proposed Date or Actual Change Date is in the past or future.

A Retrospective Change A change to a NMI record that becomes effective on or before the date the Change Request is submitted. can use today’s date. Optionally, for some types of Retrospective Changes, it is possible to specify an Actual End Date A date specifying the end of a period when updating existing data in CATS. It is only specified in a Change Request for a Retrospective Change correcting a past error.. 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 Customer Administration and Transfer Solution. A set of procedures, principles and obligations made under the National Electricity Rules as part of Market Settlement and Transfer Solutions (MSATS), and applicable to NMI (National Metering Identifier) small and large classifications._NMI_DATA table for Prospective and Retrospective Change Requests.

Prospective and retrospective change request examples

The examples in Prospective and retrospective Change Requests , change the CATS_NMI_DATA table and describe of how MSATS updates data.

Table 118 Prospective and retrospective Change Requests

Step

Process

Proposed change date

Completion date

Explanation

  1.  

Create the NMI

01-Feb-2002

02-Feb-2002

These two Transactions are Change Requests with Prospective changes for the effective date change so, are part of the overnight process.

For details, see Processing the updates to master records.

  1.  

Change the TNI Code

01-Mar-2002

02-Mar-2002

  1.  

Change the DLF Code

01-Jul-2002

11-Jul-2002

This is a Retrospective Transaction entered on 10-Jul-2002. Because there are no allowable Objections for 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 CATS_NMI_Data after NMI creation 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.

Table 119 CATS_NMI_Data after NMI creation

ID_ND

NMI

TNI code

DLF code

Start Date

End Date

MAINTUPDTDT

MAINTACTFLG

MAINTCREATEDT

1

XXXXXXXX24

VTT2

LELS

01-Feb-2002

31-Dec-9999

31-Dec-9999

A

02-Feb-2002 1:05

The figure below represents the same record as a diagram with the following details:

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

  2. If the record extends into the future on the Trading Date axis, it means its EndDate is the high date.

Figure 153 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

The overnight process for 1-Mar-2002 (approx. 01:00 on 2-Mar-2002), does the following:

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

  1. Creates two new active records:

  1. One for the period up to the Day before the Change Request’s Actual Change Date, containing the superseded data.
  2. One for the period starting from the Actual Change Date.

The CATS_NMI_DATA table now contains the records shown in CATS_NMI_Data after TNI creation with the following details:

  1. For the original record, record 1 (ID_ND = 1), MSATS changes:

  1. Its MaintUpdtDt to 02-Mar-2002 1:02:00 AM.
  2. 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.

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

  1. Record 2 (ID_ND = 2):

  1. 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.
  2. Has its MaintUpdtDt is 31-Dec-9999, because this is the value inserted into this field whenever a new record is created.
  3. Is created to cover the Billing Period from 01-Feb-2002 to 28-Feb-2002.

  1. Record 3 (ID_ND = 3):

  1. Has the Standing Data after the update, with the new TNI Code.
  1. Has its StartDate is the Actual Change Date.
  2. Has its End Date is the high date because it becomes the active record covering the period from 01-Mar-2002 into the future.
  3. Has its MaintUpdtDt is also 31-Dec-9999.
  4. Has the new TNI Code.
  5. Covers the Billing Period from 01-Mar-2002 to 31-Dec-9999.

Table 120 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.

ID_ND

NMI

TNI code

DLF code

Start Date

End Date

MAINTUPDTDT

MAINTACTFLG

MAINTCREATEDT

1

XXXXXXXX24

VTT2

LELS

01-Feb-2002

31-Dec-9999

02-Mar-2002 1:02

I

02-Feb-2002 1:05

2

XXXXXXXX24

VTT2

LELS

01-Feb-2002

28-Feb-2002

31-Dec-9999

A

02-Mar-2002 1:02

3

XXXXXXXX24

VHTS

LELS

01-Mar-2002

31-Dec-9999

31-Dec-9999

A

02-Mar-2002 1:02

 

CATS_NMI_Data diagram after TNI code change represents the same record as a diagram with the following details:

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

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

  3. Record 3 is the active record covering the period from 01-Mar-2002 into the future.

Figure 154 CATS_NMI_Data diagram after TNI code change

Change the DLF code

The Change Request to change the DLF Code A code used in MSATS to identify a distribution loss factor. 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:

  1. Makes record 3 (ID_ND = 3) inactive and updates the MaintUpdtDt with the system time and date.

  2. Creates two new active records (ID_ND = 4 and 5):

  1. One for the period prior to the Change Request’s Actual Change Date, containing the old version of the record 3 data.
  2. One for the period starting from the Actual Change Date.

The CATS_NMI_DATA table now contains the records shown in CATS_NMI_Data with changed DLF code, remember:

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

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

  1. Record 5 (ID_ND = 5) is the new record with the new DLF Code, starting from 01-Jul-2002.

CATS_NMI_Data diagram with changed DLF code represents the same data as a diagram.

Table 121 CATS_NMI_Data with changed DLF code

  • Blue shading = fields updated on an existing record.
  • Purple shading = fields changed leading to the creation of the two new records.

ID_ND

NMI

TNI code

DLF code

Start Date

End Date

MAINTUPDTDT

MAINTACTFLG

MAINTCREATEDT

1

XXXXXXXX24

VTT2

LELS

1-Feb-2002

31-Dec-9999

2-Mar-2002 1:02

I

2-Feb-2002 1:05

2

XXXXXXXX24

VTT2

LELS

1-Feb-2002

28-Feb-2002

31-Dec-9999

A

2-Mar-2002 1:02

3

XXXXXXXX24

VHTS

LELS

1-Mar-2002

31-Dec-9999

11-Jul-2002 1:02

I

2-Mar-2002 1:02

4

XXXXXXXX24

VHTS

LELS

1-Mar-2002

30-Jun-2002

31-Dec-9999

A

11-Jul-2002 1:02

5

XXXXXXXX24

VHTS

LRLS

1-Jul-2002

31-Dec-9999

31-Dec-9999

A

11-Jul-2002 1:02

 

Figure 155 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:

  1. What happens if you submit a Change Request with a Start and an End Date.

  2. Where another Change Request is submitted to change the TNI to VER2 for the period 01-May-2002 to 31-Aug-2002.

The figure below describes the NMI’s active TNI Code after completion of the Change Request over time.

Figure 156 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:

  1. The two existing active records (ID_ND = 4 and 5) are made inactive.

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

01-Jul-2002

31-Aug-2002

01-Sep-2002

31-Dec-9999

 

The CATS_NMI_DATA Table now contains the records shown in CATS_NMI_Data for active TNI code over time with the following details:

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

  1. MSATS creates Records 6 and 7 (ID_ND = 6 and 7). Between them, they cover the original record 4 Billing Period.

  1. Records 8 and 9 (ID_ND = 8 and 9) cover the period originally covered by record 5 (ID_ND 5).

CATS_NMI_Data diagram for active TNI code over time represents this data as a diagram.

Figure 157 CATS_NMI_Data for active TNI code over time

  • Blue shading = fields updated on an existing record.
  • Purple shading = fields changed leading to the creation of the two new records.

ID_ND

NMI

TNI code

DLF code

Start Date

End Date

MAINTUPDTDT

MAINTACTFLG

MAINTCREATEDT

1

XXXXXXXX24

VTT2

LELS

1-Feb-2002

31-Dec-9999

2-Mar-2002 1:02

I

2-Feb-2002 1:05

2

XXXXXXXX24

VTT2

LELS

1-Feb-2002

28-Feb-2002

31-Dec-9999

A

2-Mar-2002 1:02

3

XXXXXXXX24

VHTS

LELS

1-Mar-2002

31-Dec-9999

11-Jul-2002 1:02

I

2-Mar-2002 1:02

4

XXXXXXXX24

VHTS

LELS

1-Mar-2002

30-Jun-2002

13-Sep-2002 1:02

I

11-Jul-2002 1:02

5

XXXXXXXX24

VHTS

LRLS

1-Jul-2002

31-Dec-9999

13-Sep-2002 1:02

I

11-Jul-2002 1:02

6

XXXXXXXX24

VHTS

LELS

1-Mar-2002

30-Apr-2002

31-Dec-9999

A

13-Sep-2002 1:02

7

XXXXXXXX24

VER2

LELS

1-May-2002

30-Jun-2002

31-Dec-9999

A

13-Sep-2002 1:02

8

XXXXXXXX24

VER2

LRLS

1-Jul-2002

31-Aug-2002

31-Dec-9999

A

13-Sep-2002 1:02

9

XXXXXXXX24

VHTS

LRLS

1-Sep-2002

31-Dec-9999

31-Dec-9999

A

13-Sep-2002 1:02

 

Figure 158 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:

  1. Create the NMI.

  2. A prospective change to the NMI’s FRMP .

  3. A retrospective change to a NMI’s FRMP to correct an error.

Create the NMI

Part of the process of creating a NMI record includes specifying the mandatory Role The role a company has with a connection point in CATS. A single company can have more than one role associated with a NMI. Codes: LR Local Retailer. A business unit or related body corporate of the relevant local network service provider, or responsible under the laws of the relevant participating jurisdiction for the supply of electricity to franchise customers in that local area., FRMP, LNSP, MDP, MPB See MP, ROLR Retailer of Last Resort. A scheme principally designed to ensure that in the event of retailer failure, arrangements are in place to ensure customers continue to receive electricity and/or gas supply., MPC Market Price Cap. The National Electricity Rules’ maximum price at which gas can be bid, offered, or scheduled in the market. The AEMC’s Reliability Panel reviews the MFP every four years., and RP Responsible Person. The participant with formal responsibility for the provision, installation and maintenance of a metering installation..

The example in Changing a NMI’s FRMP table explains what the CATS_NMI_PARTICIPANT_RELATIONS table looks like when the NMI record is created as a First Tier NMI The electricity associated with a first tier NMI (classified as a first tier load) is purchased at a connection point directly and in its entirety from the local retailer.. 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 Changing a NMI’s FRMP diagram.

Figure 159 Changing a NMI’s FRMP table

Participant ID

NMI

Role ID

Start date

End date

MAINTACTFLG

MAINTUPDTDT

MAINTCREATEDT

RETSOUTH

XXXXXXXX24

FRMP

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

NETSOUTH

XXXXXXXX24

LNSP

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

RETSOUTH

XXXXXXXX24

LR

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

MDPSOUTH

XXXXXXXX24

MDP

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

MPSOUTH

XXXXXXXX24

MPB

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

RETSOUTH

XXXXXXXX24

ROLR

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

MCSOUTH

XXXXXXXX24

RP

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

RETSOUTH

XXXXXXXX24

MPC

1-Feb-2002

31-Dec-9999

A

31-Dec-9999

2-Feb-2002 1:44

 

Figure 160 Changing a NMI’s FRMP diagram

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:

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

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

  3. Now, the records on the CATS_NMI_PARTICIPANT_RELATIONS table, where the Role ID is FRMP, look like A prospective change to the NMI’s FRMP table.

Other Role IDs exist in this table but for simplicity, only the FRMP is shown.

A prospective change to the NMI’s FRMP diagram represents the same data a diagram.

Table 122 A prospective change to the NMI’s FRMP table

  • Blue shading = fields updated on an existing record.

  • Purple shading = fields changed leading to the creation of the two new records.

ID_NPR

Participant ID

NMI

Role ID

Start date

End date

MAINTACTFLG

MAINTUPDTDT

MAINTCREATEDT

1

RETSOUTH

XXXXXXXX24

FRMP

1-Feb-2002

31-Dec-9999

I

03-Apr-2002 1:04

2-Feb-2002 1:44

2

RETSOUTH

XXXXXXXX24

FRMP

1-Feb-2002

31-Mar-2002

A

31-Dec-9999

3-Apr-2002 1:04

3

RETEAST

XXXXXXXX24

FRMP

1-Apr-2002

31-Dec-9999

A

31-Dec-9999

3-Apr-2002 1:04

 

Figure 161 A prospective change to the NMI’s FRMP diagram

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:

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

  1. 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 A type of transaction raised in relation to a Change Request. Logging Period and there are no Objections, this Transaction is processed after five full Business As defined in the NERL. 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.

  1. Now, the records in the CATS_NMI_PARTICIPANT_RELATIONS Table where the RoleID is FRMP look like the data in A retrospective change to a NMI’s FRMP to correct an error table.

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.

A retrospective change to a NMI’s FRMP to correct an error diagram represents the same data a diagram.

Table 123 A retrospective change to a NMI’s FRMP to correct an error table

  • Blue shading = fields updated on an existing record.
  • Purple shading = fields changed leading to the creation of the two new records.

ID_NPR

Participant ID

NMI

Role ID

Start date

End date

MAINTACTFLG

MAINTUPDTDT

MAINTCREATEDT

1

RETSOUTH

XXXXXXXX24

FRMP

1-Feb-2002

31-Dec-9999

I

03-Apr-2002 1:04

2-Feb-2002 1:44

2

RETSOUTH

XXXXXXXX24

FRMP

1-Feb-2002

31-Mar-2002

I

9-Nov-2002 1:20

2-Feb-2002 1:44

3

RETEAST

XXXXXXXX24

FRMP

1-Apr-2002

31-Dec-9999

I

9-Nov-2002 1:20

3-Apr-2002 1:04

4

RETSOUTH

XXXXXXXX24

FRMP

1-Feb-2002

28-Feb-2002

A

31-Dec-9999

9-Nov-2002 1:20

5

RETWEST

XXXXXXXX24

FRMP

1-Mar-2002

31-Mar-2002

A

31-Dec-9999

9-Nov-2002 1:20

6

RETWEST

XXXXXXXX24

FRMP

1-Apr-2002

15-Aug-2002

A

31-Dec-9999

9-Nov-2002 1:20

7

RETEAST

XXXXXXXX24

FRMP

16-Aug-2002

31-Dec-9999

A

31-Dec-9999

9-Nov-2002 1:20

 

Figure 162 A retrospective change to a NMI’s FRMP to correct an error diagram