Business data request — MSB view
The process describes the request for master data on a market or metering location between the NB and a further market partner and the request for values (excluding complaints about missing or implausible values – see under “further requirements”) on a market or metering location or tranche between the MSB and a further market partner. The business data request is addressed to the NB or MSB of the market location that was assigned to the market location for the time period for which the master data or values are required. Either master data for the point in time of the request or values for a point in time or a time period can be requested. The requesting party submits a business data request to the NB or MSB. The NB or MSB checks the request. In the case of an authorised request and a successful identification of the market or metering location, the NB or MSB transmits the requested information to the requesting party. Otherwise the NB or MSB sends the requesting party a rejection of the business data request. The data exchange within the use case “start of supply” (GPKE part 2) remains unaffected by the option of requesting this data via the use case “business data request” ahead of the start of supply. The process can also be used when the gas MSB wants to ask the electricity NB whether a SMGW is already installed at an address. If a SMGW is installed, the NB names to the gas-MSB the responsible MSB for the SMGW.
Process flow from the perspective of the MSB
Process steps
2 Response
NB LF
This step runs between other market partners and is not relevant for this view.
Check identifiers
Business data request
MSB LFZ10Z18E_0442 Check business data request for values19102ANFRAGE_WERTECheck identifiers
- 17102 — Request for values · AS4
Flow
Message from LF · AS4
Load data for the incoming check
- Read market location
GET /getMarketLocationBasic - Read metering location
GET /getMeterLocationBasic - Read tranche
GET /getTrancheBasic
- Read market location
APERAK checks
17102→Z1017102→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
Load data for the check
- Read balancing
GET /getAccountingBasic
- Read balancing
Decision tree
17102→ E_0442 — Check business data request for values
Trigger follow-up process
- 19102 — Rejection of the request values
ANFRAGE_WERTE
After processing, the MACO APP starts the follow-up process itself; which of them runs depends on the result of the processing.
Response
MSB LF17102Check identifiers
- 19102 — Rejection of the request values · AS4
- 13018 — Load curve metering location, grid coupling point, grid location · AS4
- 13017 — Meter reading (electricity) · AS4
- 13019 — Energy quantity (electricity) · AS4
- 13016 — Energy quantity and max. power (electricity) · AS4
- 13025 — Load curve market location, tranche · AS4
Flow
Triggered by incoming message
- 17102 — Request for values
The MACO APP sends this message itself, as a follow-up process after this incoming message. In addition, the backend can trigger this step with an event — the next item.
Prozessauslöser
START_ERHEBUNG_MESSWERTEThe backend triggers this step with this event.
Load data for processing
LESEN_ENERGIEMENGE_LASTGANG_BASISLESEN_ENERGIEMENGE_ZAEHLERSTAND_BASIS- Read meter
GET /getCounterBasic LESEN_ENERGIEMENGE_ENERGIEMENGE_BASIS
Message to LF · AS4
Response per decision tree
19102→ E_0442 · MSB · Check business data request for values
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
Decision trees of this process
| EBD | Name |
|---|---|
| E_0442 | Check business data request for values |
| E_0441 | Check business data request for master data |
| E_0443 | Check business data request for master data |
Process information
Wording of the consolidated version, profile ch. 3.1, pp. 29–30.
Preconditions
- The requesting party is assigned to the market or metering location throughout the requested time period or at the point in time of the request and is therefore authorised to receive the requested data, or
- If the requesting party is not assigned to the market or the metering location for the entire requested time period or is not legally entitled, an authorisation to receive the requested information must be demonstrated by the requesting party to the requested NB or MSB. The existence of corresponding contractual powers of attorney (e.g. within the metering point operator framework contract between MSB and NB or the grid usage contract between LF and NB) can be assured.
- For requests at market location level, the ID of the market location is known.
- For requests at metering location level, the ID of the metering location is known.
Results
The requesting party has received the data and can use it for the subsequent processes.
Error case
Error cases
- The requesting party is not authorised.
- The requested party does not have the data.
Further requirements
- In justified individual cases, the NB or MSB may request proof of authorization.
- Implausible or missing values are to be complained about, depending on the preconditions, via the use case “Complaint about values” (WiM Part 2) or the use case “Complaint about a configuration” (GPKE Part 3).
Trigger
Runs beforehand: Determination of the MaLo ID of the market location — these processes name the one shown here in their result.
First message
LF sends “Business data request” (step 3). From here on, it is the turn of the party involved on this page.
Objective
The requesting party has received the requested business data.
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.
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.
These read accesses are not listed in the API catalogue of this format version; the step therefore shows only their command, without address and without button.
Applies to: 4
The connector table lists no write call for these steps. Derived from the process flow: the process begins for the own role with their message, so the transaction is created.
Applies to: 3