mako-gpke

GPKE — Geschäftsprozesse zur Kundenbelieferung mit Elektrizität

Process engine workflows for the German electricity market supplier-switch and grid access billing processes. Implements the BDEW GPKE specification and BNetzA rulings:

• BK6-24-174 (Beschluss 24.10.2024, gültig seit 06.06.2025) — GPKE Teil 1–3 (Lieferantenwechsel, Zuordnungsprozesse)
• BK6-22-024 (Beschluss 21.03.2024) — GPKE Teil 4 (Stammdatenprozesse, Konfigurationseinrichtung)

Fristen — two clocks

APERAK (the transport acknowledgement): 45 Minuten on a Werktag for UTILMD and ORDERS; a Saturday arrival is due Sunday 12:00 Berlin, everything else 12:00 of the next Werktag (APERAK AHB 1.1 § 2.4.1).

The business answer is per Prüfidentifikator and comes from mako_fristen::antwort — 11:00 / 06:00 / 05:00 / 09:00 Uhr des 1. WT nach dem ÜT for the GPKE Teil 2 core processes, 00:00 Uhr des 61. WT for a Neuanlage, the

1. WT for a Sperr-/Entsperrauftrag, 2 WT for a Teil-4 Stammdaten-Rückmeldung.

GPKE Teil 2 states every window as a wall-clock instant on a Werktag, never as a duration: a message arriving Friday afternoon is answerable until Monday morning, one arriving Tuesday evening has under sixteen hours.

There is no 24-hour message window

LFW24 (BK6-22-024) implements § 20a EnWG, which requires the supplier switch itself to complete within 24 hours. GPKE does not express that as a per-message deadline: it chains wall-clock instants on the first Werktag after the ÜT — 07:00, 09:00, 11:00, 12:00 — so the whole sequence fits inside the statutory duration. GPKE Teil 1 Kap. 7 („Fristenberechnung") defines WT, T, Zuordnungsbeginn, ÜT and ÜZ and contains no 24-hour Frist at all.

Reading the statutory 24 hours as a message window is wrong in both directions: it expires a Friday-afternoon Anmeldung on Saturday, and it reports a Tuesday-11:00 Frist as still running until Tuesday night. Every window in this crate therefore comes from mako_fristen::antwort, never from a literal, and services/makod/tests/deadline_labels.rs pins the registration sites to the constants the workflows match.

The Anmeldung is two trees, and on an assigned Marktlokation two phases

E_0622 „Prüfen, ob Anmeldung direkt ablehnbar" is a Vorprüfung: every code it publishes is an Ablehnung, and surviving it means only that the Anmeldung is not directly refusable. What the NB answers comes from E_0623, and that tree reads a fact the message does not carry — the incumbent LFA's answer to an Anfrage zur Beendigung der Zuordnung the NB has to send first.

GPKE Teil 2 § 2.1.2 SD Lieferbeginn Nr. 1 Prüfschritt 4 is the branch: „Ist die Marktlokation bzw. Tranche zum Zuordnungsbeginn einem LF zugeordnet, fährt der NB mit Prozessschritt 2 fort, ansonsten mit Prozessschritt 5." So an unassigned Marktlokation is confirmed in one pass and an assigned one is not.

gpke-beendigung-zuordnung runs both ends, told apart by which command opens the process: Anfragen / ReceiveAntwort on the NB side, ReceiveAnfrage / SendAntwort on the LFA's.

Silence is a result, not a timeout. „Verstreicht die Frist, ohne dass eine Antwort beim NB eingeht, gilt dies als Bestätigung nach Fall a). Nach Ablauf der Frist eingehende Antworten sind für den Fortlauf dieses Prozesses unerheblich." The NB's window on the LFA therefore completes the Anfrage, which is why it has its own deadline label and its own command — routing it through the ordinary TimeoutExpired would reject a Lieferantenwechsel the Festlegung confirms.

mako_pruefung::evaluate_lieferbeginn walks E_0623. Four of its eight outcomes are refusals: A50 / A57 (the LFA widersprochen, and not with the „bereits abgemeldet" code A30 / A41) and A53 / A54 (Geschäftsvorfall 3 — not enough percentage came free). Gas states the same rule as a flat code: G_0011 Z35 „Ablehnung der Abmeldeanfrage".

A50 and A57 oblige a second SG4 STS. STS+Z35 „Status der Antwort des dritten Marktbeteiligten" restates the LFA's own E_0624 code (Bedingungen [356] / [84]) — Nr. 6's „der NB gibt zusätzlich den Grund der Ablehnung des LFA an", on the wire. makod refuses to render the Ablehnung without it; the 55080 form additionally names which Tranche the restated answer is about, because Geschäftsvorfall 3 has several LFA.

The Anfrage carries SG12 NAD+Z09 „Kunde des LF" (Muss on ZW4/ZAP, Bedingung [279]) — the Kundenname from the LFN's own Anmeldung ([572]), which is how the LFA tells an Einzug from a Wechsel at E_0624 Prüfschritt 30. It is a name, so it rides C080 with the DE 3045 Namensformat and not the party-identification composite.

Meldepflichten — obligations with no answer

Four messages the NB owes have no Bestätigung, so a missing one produces no timeout and no alert:

gpke-zuordnungsmeldung renders all four. 55611 is the odd one: it belongs to the SD „Lieferende von NB an LF" (§ 2.5.2 Nr. 11 / Nr. 13), which the NB opens itself with a 55007 rather than answering an inbound Anmeldung — so it is anchored on MeldungAnchor::EigeneAnkuendigung. It is also the only message here that may name a Messlokation (SG5 LOC+Z17), because „der MSB ist ausschließlich dem Objekt Messlokation zugeordnet", and the only one whose SG4 DTM qualifier follows the Grund instead of the PID: DTM+93 under ZC8, DTM+92 under ZH1.

The other three follow the Lieferbeginn. Whether one is owed is a Versorgungsstatus question — GPKE Teil 2 § 2.1.2 Nr. 1 Prüfschritt 4 sends the NB to Prozessschritt 2 only „Ist die Marktlokation bzw. Tranche zum Zuordnungsbeginn einem LF zugeordnet" — so processd decides and issues gpke.zuordnung.informieren / .beenden / .aufheben.

Because nothing waits for them, the guard is a test rather than an alert: mako_fristen::meldung catalogues the windows and Fundstellen and services/makod/tests/meldepflicht_coverage.rs cross-checks it against the PID router.

Three wire facts the AHB fixes per PID, and the workflow refuses a message that gets them wrong: 55036 is BGM+E01 and carries no SG4 date at all, while 55037 (E02) names a DTM+93 Vertragsende and 55038 (E02) the originally confirmed DTM+92 Vertragsbeginn; the Gründe are disjoint (Z26 · ZC8/ZD9/ ZG6 · ZG5/ZG9/ZH0/ZH1); and SG12 NAD+VY names every Altlieferant on a 55036 (Bedingung [518], because Geschäftsvorfall 3 splits a Marktlokation across Tranchen).

PID Inventory

UTILMD supplier-switch and feed-in processes (S2.1/S2.2)

Legend: ✅ Implemented — full state machine, AHB-validated, production-safe. ↩ Derived — emitted by workflow as outbound ANTWORT, not routed as inbound. ❌ Removed — existed pre-LFW24; router rejects with CONTRL.

ORDERS/ORDRSP Konfigurationseinrichtung (GPKE Teil 4)

INVOIC billing processes (Netznutzungsabrechnung)

Implemented by GpkeAbrechnungWorkflow. Inbound INVOIC messages from the NB spawn a new process; the invoicd daemon listens for de.mako.process.initiated events and runs a plausibility check via invoic-checker. It then calls gpke.abrechnung.annehmen (→ REMADV) or gpke.abrechnung.ablehnen (→ COMDIS) on the Command API. Inbound REMADV and COMDIS from the NB are handled via ReceiveRemadv and ReceiveComdis commands.

The state machine itself is not this crate's: all four INVOIC billing families (GPKE, WiM, GaBi Gas, GeLi Gas) share mako-invoic, and this crate declares only the family — its PID set, its deadline label, and which of the two roles the deployment plays.

PIDs 31007/31008 (Aggreg. MMM-Rechnung Gas, NB → MGV) belong to mako-gabi-gas (BK7-24-01-008). PIDs 31003 (WiM-Rechnung) and 31009 (MSB-Rechnung) belong to the WiM domain. PID 31004 (Stornorechnung) is a Sparte-neutral, cross-process universal Storno (INVOIC AHB §3.1.2) — invoicd checks it Sparte-neutrally via check_storno, not a GPKE billing PID.

ORDERS Sperrung Strom (GPKE Teil 4, BK6-22-024)

The gas Sperrung equivalents of these PIDs (same PID numbers, different Sparte) belong to mako-geli-gas. Never mix Strom and Gas Sperrung in the same deployment module.

Direction matters here and is easy to get wrong: 17115 and 17117 travel LF → NB — the Lieferant orders the grid operator to disconnect or reconnect. 17116 is the NB asking the MSB. Two workflows model the two ends.

ERP commands. LF side: gpke.sperrung.beauftragen (17115), gpke.entsperrung.beauftragen (17117), gpke.sperrung.stornieren (39000). NB side: gpke.sperrung.bestaetigen / gpke.sperrung.fehlgeschlagen — both dispatch IFTSTA 21039 and are issued automatically by sperrd.

UTILMD Stornierung Zuordnungsprozess (GPKE Teil 1)

UTILMD Ankündigung / Zuordnung LF (GPKE Teil 1)

PARTIN Strom — Kommunikationsdaten (PARTIN AHB 1.0f)

PIDs 37008–37014 (PARTIN Gas Kommunikationsdaten) belong to mako-geli-gas.

UTILMD Neuanlage Marktlokation (GPKE Teil 1)

Workflow gpke-neuanlage handles Neuanlage requests where the MaLo does not yet exist in the grid operator's system.

Antwortfrist: 00:00 Uhr des 61. WT nach dem ÜT (GPKE Teil 2 § 2.2.2 — E_0608 re-identifies daily for up to 60 Werktage). PIDs 55602–55605 are derived response PIDs; they are never routed inbound — the NB emits them outbound.

UTILMD Lieferende von NB an LF (GPKE Teil 2 § 2.5.2)

Workflow gpke-lf-abmeldung: the NB announces that the supplier's assignment to the Marktlokation ends, and the LF answers by 05:00 Uhr des 1. WT nach dem ÜT. Not a Kündigung — the Kündigung is 55016, sent LFN → LFA without the NB.

E_0609 decides which. The three Transaktionsgründe a 55007 may carry are Z33 (Auszug wegen Stilllegung), ZQ7 (fehlende Zuordnungsermächtigung nach BKV-Deaktivierung) and ZT0 (fehlende Zuordnungsermächtigung nach Änderung des Zeitreihentyps); anything else has no path through the tree and escalates.

MSCONS Messwerte Strom — Lieferant (GPKE Teil 2/4)

Workflow gpke-messwerte accepts inbound MSCONS messages carrying metered values from the NB or MSB to the LF. These are read-only deliveries; no APERAK response is required unless the message fails validation.

All MSCONS PIDs here carry metered data. They are stateless deliveries that write no outbox entries on success.

ORDERS Datenabruf — Anfrage / Ablehnung (GPKE Teil 4)

Workflow gpke-datenabruf handles the LF-side of data-request processes: the LF sends an ORDERS Anfrage to the NB or MSB and waits for a response or explicit rejection within 24 h.

The response deadline (gpke-datenabruf-antwort) is 1 Werktag — „Unverzüglich, jedoch spätester ÜZ ist 1 WT nach dem ÜZ von Nr. 1", GPKE Teil 4 § 3.2 Prozessschritte 2 und 4 — and is enforced by a DeadlineStore entry registered on every outbound ORDERS Anfrage.

ORDERS Allokationsliste — MSCONS 13014 (GPKE MSCONS Strom)

Workflow gpke-allokationsliste handles requests and rejections for the Allokationsliste, exchanged between LF and NB via ORDERS and answered with MSCONS.

PIDs 17110/19110 here are Strom (GPKE). The same PID numbers also appear in mako-gabi-gas for the gas MMMA process (different commodity, different crate).

EDIFACT Format Versions

INVOIC (31001–31008) and ORDERS/ORDRSP Konfiguration (17134/17135, 19001/19002) use their own versioned profiles (fv20260401), independent of the UTILMD Strom release cycle.

Modules

Usage

use mako_gpke::wechselprozesse::{GpkeSupplierChangeWorkflow, SupplierChangeCommand};
use mako_engine::{builder::EngineBuilder, event_store::InMemoryEventStore};

// In tests (requires `testing` feature or `#[cfg(test)]`):
#[cfg(test)]
let ctx = EngineBuilder::new()
    .with_event_store(InMemoryEventStore::new())
    .build();

// In production, explicitly provide all stores:
// let ctx = EngineBuilder::with_stores(outbox, deadline, registry)
//     .with_event_store(my_slatedb_store)
//     .build();

let process = ctx.spawn::<GpkeSupplierChangeWorkflow>(tenant_id, workflow_id);
let events = process.execute(SupplierChangeCommand::ReceiveUtilmd {
    pid: 55001,
    // …
}).await?;

Regulatory references

• BDEW GPKE Marktprozesse für die Belieferung mit Elektrizität
• BNetzA BK6-24-174 (Beschluss 24.10.2024, gültig seit 06.06.2025) — GPKE Teil 1–3
• BNetzA BK6-22-024 (Beschluss 21.03.2024) — LFW24, superseded for the process descriptions by BK6-24-174
• EDI@Energy UTILMD Strom AHB S2.2 (FV2026-10-01)
• EDI@Energy INVOIC AHB 2.8e / AHB 1.0 (FV2025-10-01 onwards)
• EDI@Energy APERAK AHB 1.1 (FV2026-10-01) — § 2.4.1 Strom, § 2.3.1 Gas. 2.2 is the APERAK MIG revision; AHB and MIG carry different version numbers for every message type except UTILMD