Contract termination — LFN view
Process flow from the perspective of the LF (LFN)
Process steps
Contract termination
LF (corresponds to LFN) LF (corresponds to LFA)Check identifiers
- 44016 — Contract termination with the old supplier · AS4
Flow
Prozessauslöser
START_KUENDIGUNGThe backend triggers this step with this event.
Message to LF (corresponds to LFA) · 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
LF (corresponds to LFN) LF (corresponds to LFA)Z33Check identifiers
Flow
Message from LF (corresponds to LFA) · AS4
Response per decision tree
44018,44017→ E_3001 · Check contract termination of gas supply contract
APERAK checks
44018,44017→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
Load data for processing
- Read energy supply contract
GET /getEnergySupplyContractBasic - Read market location
GET /getMarketLocationBasic - Read balancing
GET /getAccountingBasic
- Read energy supply contract
Decision trees of this process
| EBD | Name |
|---|---|
| E_3001 | Check contract termination of gas supply contract |
Process information
Trigger
Runs beforehand: Determination of the MaLo ID of the market location — these processes name the one shown here in their result.
First message
The party involved on this page is itself the sender of: „Contract termination“ to LF (corresponds to LFA) (step 1).
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 LFA — the transferring supplier · market role LF
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.
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.
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.