Grid usage settlement — NB view
The process describes the communication between NB and LF on the billing of grid usage and, where applicable, the automated complaint case. An invoice correction always comprises a cancellation invoice and a new invoice. In the cases listed below in particular, an annual invoice can be corrected or supplemented without this being done by cancellation:
- Change of the concession levy by submitting an attestation: check of the limit price comparison according to KAV
- Correction of the electricity grid fees on the basis of an individual agreement for atypical and energy-intensive grid usage in accordance with StromNEV
- Correction of the electricity grid fees on the basis of an individual agreement for singular grid usage in accordance with StromNEV
- KWKG levy
- Offshore grid levy. In these cases a separate, correspondingly marked invoice can be issued in which the fees paid in excess or short for the billing year are corrected and charged in accordance with the audit certificate, the individual agreement or the evidence. This invoice must refer unambiguously to the annual invoice whose item or items it corrects.
Process flow from the perspective of the NB
Process steps
Grid usage invoice
NB LFFlow
Message to LF · AS4
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
Response
NB LFCheck identifiers
Flow
Message from LF · AS4
Response per decision tree
33003→ E_0406 · LF · Check grid usage invoice
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
Notification that the original grid usage invoice was correct
NB LFCheck identifiers
- 29001 — Rejection of REMADV · AS4
Flow
Message to LF · AS4
Response per decision tree
29001→ E_0452 · Check non-payment advices
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
Response
NB LFCheck identifiers
Flow
Message from LF · AS4
Response per decision tree
33003→ E_0407 · LF · Check grid usage settlement again
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 the original invoice
NB LFCheck identifiers
- 31004 — Cancellation invoice · AS4
Flow
Message to LF · AS4
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
Response
NB LFFlow
Message from LF · AS4
Response per decision tree
33002→ E_0459 · LF · Check whether a response to the cancellation is required
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
Decision trees of this process
| EBD | Name |
|---|---|
| E_0406 | Check grid usage invoice |
| E_0407 | Check grid usage settlement again |
| E_0452 | Check non-payment advices |
| E_0459 | Check whether a response to the cancellation is required |
Process information
Wording of the consolidated version, profile ch. 3.3.1, pp. 87–89.
Preconditions
- This is a consuming market location.
- The current grid usage fees have been published by NB and were transmitted to LF in the price sheet grid usage within the use case „Transmission of price sheet NB to LF“
- The LF is assigned to the market location.
- The grid usage invoice contains only items that
- are contained as an article ID in the grid usage price sheet or
- were transmitted in advance as a surcharge/discount on an article ID of the grid usage price sheet of the NB within the use case “Billing data grid usage settlement”.
- The information required for the grid usage settlement has been transmitted via the use case „Billing data grid usage settlement“.
- The billing of the grid usage is due (cyclical invoice, partial payment invoice or final invoice, or event-driven).
- The delivery note was transmitted beforehand (except for instalment invoices) and, in the case of a rejection with a specific reason by the LF, the complaint was refuted by the NB.
- The LF is the payer of the grid usage.
Results
The LF will pay the grid usage invoice issued by the NB.
Error case
Error cases
- The grid usage invoice contains items that are not
- are contained as an article ID in the grid usage price sheet of the NB or
- were transmitted in advance as a surcharge/discount on an article ID of the grid usage price sheet of the NB within the use case “Billing data grid usage settlement”.
- The information required for the grid usage settlement has not been transmitted via the use case „Billing data grid usage settlement“.
- The information required for the grid usage settlement has been transmitted via the use case „Billing data grid usage settlement“, but was not taken into account accordingly in the grid usage invoice.
- The billing energy quantities/demand values of the grid usage invoice do not match those of the delivery note.
- The price of an article ID stated in the grid usage invoice does not match the price of the corresponding article ID stated in the grid usage price sheet of the NB.
- The grid usage invoice contains items that are not
Further requirements
- The case of a grid usage invoice that has been complained about or turns out to be incorrect (the cancellation of the original invoice is carried out either without a prior complaint by the LF or on the basis of a prior complaint by the LF) forms part of the standard process and, apart from clarifications, must be handled fully automatically. In the event of a complaint, the so-called “all-or-nothing principle” applies, according to which an invoice is either accepted in full as correct or rejected in full. If a grid usage invoice turns out to be incorrect (the cancellation of the original invoice is carried out either without a prior complaint by the LF or on the basis of a prior complaint by the LF), the corresponding delivery note must also be cancelled in this context and a corrected delivery note must be transmitted to the LF before the new invoice is sent, provided a correction of the billing energy quantities/demand values is necessary. The processes to be handled in the event of a conflict as part of receivables management or the dunning procedure are not shown and are to be resolved bilaterally.
- The grid usage invoice can be unambiguously assigned to the previously exchanged delivery note via a reference.
- The final invoice/annual invoice shows all partial payment invoices of the billing period contained in it in a comprehensible manner, stating the invoice number.
- An item in the grid usage invoice must be uniquely assignable in time and verifiable by means of one item or by adding up several items from the delivery note.
First message
The party involved on this page is itself the sender of: „Grid usage invoice“ to LF (step 1).
Objective
The NB has been informed that the LF accepts the grid usage invoice.
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 LF — LF
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.
The source does not yet name the event that triggers these steps.
Applies to: 1
The connector table lists no write call for these steps. Derived from the process flow: the own role was already involved in this process, so the transaction already exists.
For the check identifiers of these steps there is no test case in the test data set; the »Try it out« button of the write interface therefore offers no body.
Applies to: 5