Skip to content

BILLING_CSP_DEROGATION_AMOUNT

CSP derogation amounts with respect to participant allocated payment

Deprecation Warning

This table is in the HISTORICAL TABLES package, so is likely deprecated.

Source

BILLING_CSP_DEROGATION_AMOUNT is populated by the posting of a billing run.

Volume

An indicative maximum is one record inserted per billing run, or 11 records inserted per week.

Column Schema

AMOUNT_ID

Amount identifier represented as a string, from "ta1" through to "ta6" (or "ta8" for a lymmco derogation result)

SQL Type: VARCHAR2(20) Polars Type: str

This column is mandatory, and a primary key.

BILLRUNNO

Billing run number

SQL Type: NUMBER(3) Polars Type: pl.UInt16

This column is mandatory, and a primary key.

CONTRACTYEAR

Billing contract year

SQL Type: NUMBER(4) Polars Type: pl.UInt16

This column is mandatory, and a primary key.

PARTICIPANTID

The participant allocated the payment amount for the derogation

For more information, see the dedicated documentation page.

SQL Type: VARCHAR2(10) Polars Type: pl.Categorical

This column is mandatory, and a primary key.

WEEKNO

Billing week number

Warning

There may be 53 weeks in a year, depending on how weeks align to the year start/end.

SQL Type: NUMBER(3) Polars Type: pl.UInt16

This column is mandatory, and a primary key.

DEROGATION_AMOUNT

Derogation amount associated with the amount identifier

SQL Type: NUMBER(18,8) Polars Type: pl.Float64

This column is not mandatory.

LASTCHANGED

Last changed date for the record

For more information, see the dedicated documentation page.

SQL Type: DATE Polars Type: pl.Datetime()

This column is not mandatory.

Example: 2026/01/20 00:05:00

New Data Timing

Generated when a billing run is posted

Code Examples

Polars

Casting is enums, categoricals etc is not essential, but may speed up parsing. Swapping int for pl.UInt16, pl.Int32 would also speed up parsing. However some of the datatypes are inferred, so they may be wrong.

This code deduplicates for you. Deduplication is normally only required across multiple months.

This code assumes that all columns are present, which may not be true for older files.

import polars as pl
import polars.selectors as cs

# e.g. "2029/03/15 00:05:00"
dt_s_fmt = "%Y/%m/%d %H:%M:%S"

csv_paths = ["SOMEFILE.CSV", "OTHERFILE.CSV"]

lf = (
    pl.concat(
        [
            pl.scan_csv(
                csv_path,  # must be unzipped beforehand
                skip_rows=1,  # skip the header
                infer_schema=False,  # much faster
            )
            .filter(cs.by_index(0) == "D")  # drop the footer
            .select(~cs.by_index(range(4)))  # drop metadata columns
            for csv_path in csv_paths
        ],
        how="diagonal_relaxed",
    )
    .with_columns(
        pl.col("LASTCHANGED").str.strptime(pl.Datetime, dt_s_fmt),
    )
    .cast(
        {
            "AMOUNT_ID": str,
            "BILLRUNNO": int,  # or pl.UInt16
            "CONTRACTYEAR": int,  # or pl.UInt16
            "PARTICIPANTID": pl.Categorical,
            "WEEKNO": int,  # or pl.UInt16
            "DEROGATION_AMOUNT": pl.Float64,
        }
    )
    # Deduplicate
    # We want one row per ['AMOUNT_ID', 'BILLRUNNO', 'CONTRACTYEAR', 'PARTICIPANTID', 'WEEKNO']
    # Tie-breaker: greatest value of ['LASTCHANGED']
    .sort(["LASTCHANGED"], descending=False)
    .unique(
        subset=["AMOUNT_ID", "BILLRUNNO", "CONTRACTYEAR", "PARTICIPANTID", "WEEKNO"],
        keep="last",
    )
)

Nemosis

This table is not yet available in Nemosis.

Availability

AEMO's documentation states that this table's visibility is "Public". However, it is not available in the public monthly MMSDM archive. AEMO probably call this public because it is available to all market participants over private FTP.

There is a chance that is is still public to non-participants. It may only be available for some months; or (rarely) it may be available in a non-standard location.

Deduplication and PDR Loader Configuration

The primary keys are:

PDR Loader configuration does not mention this table, so it is unclear how to choose which row to keep when there are multiple rows for a given set of primary keys.

You should probably take the row with the maximum LASTCHANGED.

Indexes

This page as JSON (schema documented here, but may change)

Download a JSON Schema specification for this table.

Official AEMO schema documentation

Other Information

Package: HISTORICAL TABLES