Capacity billing at exit points to final consumers — NB view
Process flow from the perspective of the NB
Process steps
Capacity invoice
NB KNCheck identifiers
- 31010 — Capacity invoice · AS4
Flow
Message to KN · 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
Remittance advices
NB KNCheck identifiers
- 33001 — Confirmation · AS4
Flow
Message from KN · AS4
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
Payment rejection
NB KNCheck identifiers
- 33002 — Refusal · AS4
Flow
Message from KN · AS4
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
Capacity billing was incorrect. Where the capacity billing is rejected by TK (KN) (process step No. 3 on payment rejection) and the check result of the NB (process step No. 4) shows that the original capacity billing was not correct and/or b) where relevant changes occur subsequently (process steps No. 5 to 8): the NB sends a cancellation invoice to TK (KN) and sends a new capacity billing.
NB TK (KN)Check identifiers
- 31004 — Cancellation invoice · AS4
Flow
Message to TK (KN) · 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
Remittance advices
NB KNFlow
Message from KN · AS4
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
Process information
Notes on this page
The source provides no use case profile for this process — objective, precondition and result are not recorded there.
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 numbers are those of the source; where one is missing, it is missing there.
Step sequence reconstructed
For this process, the BNetzA consolidated version carries no sequence diagram. The steps are reconstructed from the BDEW check identifier table: grouped by the designation, ordered by the process step. The method agrees with the consolidated version in 200 of 200 cases that can be cross-checked — the individual line is nevertheless not editorially reviewed. Check it against the rulebook before adopting it into an implementation specification.
The source does not yet name the event that triggers these steps.
Applies to: 1a
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.