Transmission of the delivery note for grid usage settlement — LF view
Before the grid usage invoice is sent, the NB transmits to the LF the underlying values of the grid usage invoice at the level of the market location. Depending on the trigger, this can be a periodic or an event-driven dispatch of a delivery note. If values relevant to the delivery note change for the time period covered by a delivery note, the delivery note already sent that contains the corresponding billing energy quantity/demand value must be cancelled by the NB. A new delivery note with a corrected billing energy quantity and, where applicable, corrected demand values must then be sent to the LF. The delivery note contains the energy quantity/quantities and the annual maximum demand that occurred, which are billed on the associated grid usage invoice. If only the billing energy quantity or the demand value has to be corrected, the new delivery note must contain the still correct, uncorrected value.
Process flow from the perspective of the LF
Process steps
Delivery note
LF NBMSCONSE_0456 Check delivery note21035Check identifiers
Flow
Message from NB · AS4
Load data for the incoming check
- Read market location
GET /getMarketLocationBasic - Read meter
GET /getCounterBasic - Read metering location
GET /getMeterLocationBasic
- Read market location
APERAK checks
13016,13019→MSCONS
Write endpoint
13016→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
Write endpoint
13019→ Transaction created — Create process dataPOST /createProcessData
Creates a new transaction in the backend with the data of the incoming message.
Load data for the check
- Read energy quantities from billing context
GET /getEnergyAmount - Read grid usage contract
GET /getGridUsageContractBasic
- Read energy quantities from billing context
Decision tree
13016,13019→ E_0456 — Check delivery note
Trigger follow-up process
- 21035 — Response re. supply point
After processing, the MACO APP starts this follow-up process itself.
Response message on delivery note
LF NB1301613019Check identifiers
- 21035 — Response re. supply point · AS4
Flow
Triggered by incoming message
The MACO APP sends this message itself, as a follow-up process after one of these incoming messages.
Message to NB · AS4
Response per decision tree
21035→ E_0456 · LF · Check delivery note
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
- Transaction updated — Update process data
Objection to rejection
LF NBZ33Check identifiers
- 29002 — Rejection of IFTSTA · AS4
Flow
Message from NB · AS4
Response per decision tree
29002→ E_0458 · Check further processing
APERAK checks
29002→Z33— APERAK check: Is referenced message known ?
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
- Transaction updated — Update process data
Cancellation of delivery note
LF NBMSCONSCheck identifiers
- 13006 — Meter reading value cancellation · AS4
Flow
Message from NB · AS4
APERAK checks
13006→MSCONS
Write endpoint
- Transaction created — Create process data
POST /createProcessData
Creates a new transaction in the backend with the data of the incoming message.
- Transaction created — Create process data
Process information
Wording of the consolidated version, profile ch. 3.2.3.1, pp. 84–86.
Preconditions
- This is a consuming market location.
- The LF is the payer of the grid usage.
- Values from MSB are available.
- The energy and demand values measured so far, in the case of an intra-year allocation start and where the market location is billed with an energy and demand price, have been transmitted by NB to LF.
- The billing of the grid usage is to be issued.
- If there is a need to apply a metering time period definition of NB with the metering time period usage purpose “grid usage”, a corresponding configuration must have been set up on time and successfully via the use cases in the chapter “Order placement of a configuration” (GPKE Part 3). This applies only if the ordered setup of a configuration falls within the billing-relevant time period of the delivery note to be created.
- The information required for the grid usage settlement has been transmitted via the use case „Billing data grid usage settlement“.
Results
A grid usage invoice can be issued.
Error case
Result in the error case
A delivery note has to be transmitted again.
Further requirements
It must be possible to assign and check a line item in the grid usage invoice unambiguously in time by means of one line item or by adding up several line items from the delivery note. The NB has to take this into account when building the delivery note.
Trigger
- The end of the billing period has been reached or
- an end of supply process has been carried out or
- there is a change of the payer of the grid usage or
- a grid operator change has been carried out or
- the switch between the base price/energy price model and the energy price/demand price model has been carried out.
First message
NB sends “Delivery note” (step 1). From here on, it is the turn of the party involved on this page.
Objective
The LF has the delivery note of the billing energy quantities/demand values, which forms one of the bases for the grid usage settlement.
Other views of the process
The same process through the eyes of the other parties involved: the same steps, each read from their point of view.
- View NB — NB
Notes on this page
The steps are the possible messages of this process, not a sequence — the source lists neither conditions nor alternatives. The small box on the step names the own view on the left: with ← it receives, with → it sends. Collapsed steps run between other market partners.