Request for master data change from the LF to NB (responsible) — NBV view
Process flow from the perspective of the NB (NBV)
Process steps
Request to NB from LF
NB (responsible party) LF (authorised party)Z10Z16Z17Z18G_0031 Response to requestG_0034 Response to requestG_0035_G_0036 Response/rejection to the request for the market location structure44142441574418144182Check identifiers
Flow
Message from LF (authorised party) · AS4
Load data for the incoming check
- Read market location
GET /getMarketLocationBasic - Read metering location
GET /getMeterLocationBasic
- Read market location
APERAK checks
44139,44156,44180→Z1044139,44156,44180→Z1644139,44156,44180→Z1744139,44156,44180→Z18
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
Decision tree
44139→G_0031— Response to request44156→G_0034— Response to request44180→G_0035_G_0036— Response/rejection to the request for the market location structure
Trigger follow-up process
- 44142 — Response to request
- 44157 — Response to request
- 44181 — Response to request for the market location structure
- 44182 — Rejection of the request for the market location structure
After processing, the MACO APP starts the follow-up process itself; which of them runs depends on the result of the processing.
Response to request to NB from LF
NB (responsible party) LF (authorised party)441394415644180Check identifiers
Flow
Triggered by incoming message
- 44139 — Not bal.-rel. request to NB
- 44156 — Bal.-rel. request to NB with dependencies
- 44180 — Request for the market location structure
The MACO APP sends this message itself, as a follow-up process after one of these incoming messages.
Load data for processing
- Read market location
GET /getMarketLocationBasic - Read metering location
GET /getMeterLocationBasic - Read grid usage contract
GET /getGridUsageContractBasic - Read balancing
GET /getAccountingBasic
- Read market location
Message to LF (authorised party) · AS4
Response per decision tree
44142,44157,44181,44182→ E_3013 · Check request for master data change
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
Change from NB to MSB, if applicable
NB (responsible party) MSB (authorised party)START_ANFRAGE_STAMMDATENAENDERUNG_GASSTART_VERSAND_SDAECheck identifiers
- 44113 — Non-bal.rel. change from NB · AS4
Flow
Process trigger
The backend triggers this step with one of these events.
Message to MSB (authorised party) · AS4
Write endpoint
marktlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
Write endpoint
messlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
Response to change from the NB to MSB
NB (responsible party) MSB (authorised party)Z33Check identifiers
- 44115 — Response to change from NB · AS4
Flow
Message from MSB (authorised party) · AS4
Response per decision tree
44115→ E_3024 · Check change from the NB
APERAK checks
44115→Z33
Write endpoint
marktlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
Write endpoint
messlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
Change from NB to further LF, if applicable
NB (responsible party) LF (further LF as authorised party)Check identifiers
Flow
Prozessauslöser
START_VERSAND_SDAEThe backend triggers this step with this event.
Message to LF (further LF as authorised party) · AS4
Write endpoint
44123→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
Write endpoint
44112·marktlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
Write endpoint
44112·messlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
Response to change from the NB to further LF
NB (responsible party) LF (further LF as authorised party)Z33Flow
Message from LF (further LF as authorised party) · AS4
Response per decision tree
44124,44115→ E_3025 · Check change from the NB
APERAK checks
44124,44115→Z33
Write endpoint
44124→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
Write endpoint
44115·marktlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
Write endpoint
44115·messlokationsId != null→ Transaction updated — Update process dataPOST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
Decision trees of this process
| EBD | Name |
|---|---|
| E_3013 | Check request for master data change |
| E_3024 | Check change from the NB |
| E_3025 | Check change from the NB |
Process information
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 BER — the authorised party in this process step · market role LF
- View WLF — a further supplier as authorised party · market role LF
- View BER — the authorised party in this process step · market role MSB
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.