- Created by: ellieedf
- Created on: 08-04-20 12:35
Contract Notifications and the NMC
There are two types of notification to the ECVAA (Energy Contract Volume Aggregation Agent)
- additive - will send any new trades for each relevant half hour to be added by Elexon onto the aggregate of any previous trades notificed by counterparty
- net (overwrite) methods - will simply be a new declaration for the two parties' contract position.
The GTMAs (Grid Trade Master Agreement) in place for EDF Energy pre-determines that notifications are sent through the net overwrite method.
EDF Energy is responsible for acting as the ECVNA (Energy Contract Volume Notification Agent) and generating CNs for the external counterparties and sending them to Elexon.
This is done by running the NETA-CN3B (dispatch notifications for all days from day+1 and day +7) and WTHDAYCNA (dispatch notifications for within day and day +1) alinge batches.
Neta Message Centre (NMC) is the application through which we are able to monitor our communications with the Elexon/NGET and through which we are able to track the dispatch and acceptance of our CNs.
The STT monitor the NMC to ensure that data has been successfully submitted and accepted.
Outgoing communications from EDFE include:
- Contract Notifications
- Demand PNs
Incoming communications from EDFE include:
- Forward Contract Reports
- Counterparty AFR Reports
- The blue diamond means the message is sent to the System Operator (NGET)
- The crown means the message in send to the ECVAA (Elexon)
- Green sqaure - accepted
- Hollow square - not despatched
- Hollow triangle - pending despatch
- blue sqaure - despatched
- yellow square - acknowledged
- black square - negative acknowledged
- red triangle - partially rejected
- red square - rejected
- green triangle - partially accepted
- brown square - auto negative acknowledged
- red cross - re-despatched
The Acceptance Feedback Report (AFR) Checker allows EDF Energy to look for differences between Alinge and the position notified to Elexon for the production account in between receipts of the Forward Contract Report.
An AFR is sent from Elexon to the NMC every time a trade is notified. The Forward Contract Report details EDFE notified position against all counterparites and is recieved four times each day. By only checking the Forward Contract Report, we are exposed to long periods of time where we may have incorreclty notified a trade or had a trade incorrectly notified against us. By checking the AFR as well, we can monitor notifications more frequently.
A common AFR error occurs when a notification has not been sent to Elexon after running a balancing trade between production and consumption accounts (Baladj). The delta exists because we have created a trade between the two accounts but have not informed Elexon with a CN.
Running a WTHDAYLE ' an LE' report in alinge will notify this trade and will remove the delta for non-gate closed periods in the next run of the AFR.
An AFR delta can occur when any counterparty incorrectly notifies against EDFE or if EDFE enters the wrong details for an OTC trade (where we are not the ECVNA). In both cases the AFR delta is caused by the different between the position in Alinge and the contract position that has been notified to Elexon.
ECCLUX is the ECVNA for all trades carried out through the EPEX power exchange. We need to check to ensure that every trade that polls into alinge is notified to Elexon. However, it is rare for EPEX not to notify and is more likely deltas with ECCLUX as in the counterparty in the AFR are due to trades not polling into Alinge.
Run the "pollcheck" process to confirm whether all of our traders have polled and if there is a failure this needs to be rasied with IT. If all trades have been polled then the next course of action is to contact EPEX and inform them that you believe a trade has not been notified.