mako-wim

WiM — Wechselprozesse im Messwesen, Strom und Gas

Process engine workflows for the German metering-point-operator change processes in both Sparten: BK6-24-174 Anlagen 2a/2b (WiM Strom Teil 1 and Teil 2) and the AWH WiM Gas 2.0 (gültig ab 01.10.2026), plus the EDI@Energy AHBs that carry them.

A Prüfidentifikator (PID) is the five-digit BDEW code every message in these processes carries. It names the exact Anwendungsfall, and with it the rules, the Frist and the answer tree that apply — so the PID, not the EDIFACT message type, is what routes.

One engine, two Sparten

AWH WiM Gas 2.0 restates WiM Strom Teil 1 use-case for use-case, Frist for Frist. Only the UTILMD PID namespace splits (55xxx / 44xxx); ORDERS, ORDRSP, REQOTE, QUOTES, IFTSTA and INSRPT are Sparte-neutral AHBs carrying both. The Sparte comes from the recipient MP-ID (BDEW Allgemeine Festlegungen §2.13) and decides four things:

Fristen

Three clocks run on an inbound MSB-Wechsel order, and they are separate messages with separate commands:

Only the second discharges the Antwortfrist. The business window comes from antwort_frist_werktage(pid) and the Vorlauffristen from mako_fristen::vorlauf — never a flat value. Saturday is not a Werktag (GPKE Teil 1 Kap. 1.7, which WiM Teil 1 §1.7 defers to), and 24.12. and 31.12. count as holidays.

Antwortcodes

Every answer carries SG4 STS+E01 (UTILMD) or SG2 AJT (ORDRSP) with a code from the process's own Entscheidungsbaum. The catalogue and the executable Prüfschritte are mako-pruefung (role-msb); this crate resolves against it before anything reaches the outbox, so a code from the wrong tree is refused at the command rather than sent.

DE 1131 / DE 1082 names the Codeliste, not the Entscheidungsbaum. The AHB column reads „Codeliste Strom Nr. S_0090" for every WiM MSB-Wechsel answer, and the cluster picks which of the pair. AntwortCode::wire_codeliste() returns the wire value.

None of these alphabets is a GPKE one — A02 and A05 appear in no MSB-Wechsel tree — and the Gas lists are not the Strom lists.

PID Inventory

Legend: ✅ Implemented — full state machine + AHB rule enforcement, production-safe. ⚠️ Registered — PID routes to the workflow; handle() returns WorkflowError::NotImplemented for unhandled commands (no silent data loss). ✗ Not registered — PID is not in the router; inbound messages are dead-lettered.

MSB-Wechsel — UTILMD (WiM Strom Teil 1 Kap. 2)

Mitteilung über Gesamtvorgang — IFTSTA

The Anmeldebestätigung 55043 is vorläufig. WiM Teil 1 Kap. 2.1.1: the NB assigns the MSBN „zu dem Tag des vom MSBN mitgeteilten Termins des erfolgreichen Abschlusses des Gesamtvorgangs … mit dem Zeitpunkt 00:00 Uhr", and the MSBA's assignment ends at the same instant. AWH WiM Gas 2.0 Kap. 3.1.1 says the same with 06:00 Uhr — the Gastag boundary. This leg is what makes the Wechsel constitutive.

The numeric order is the reverse of the reading order: 21009 is the failure and 21010 the success (IFTSTA AHB 2.1 § 6.2).

Every failure path leaves the MSBA assigned. marktd derives the per-Messlokation MSB timeline from 21012 alone.

Geräteübernahme — ORDERS / ORDRSP

The Anforderung eines Geräteübernahmeangebots is REQOTE 35001, answered by QUOTES 15001 within 4 WT — preisanfrage owns that leg.

19016 is named „Ablehnung Gerätewechselabsicht" but carries ZB5 „Kein Eigenausbau des MSBA": it settles who removes the old device, not whether the Gerätewechsel happens.

PIDs 19001/19002/19015/19016 are only registered when DeploymentRoles includes Marktrolle::Nmsb. On NB instances these PIDs belong to mako-gpke (GPKE Konfiguration). Never register both simultaneously.

All six ORDERS/ORDRSP PIDs carry the Strom and the Gas Use-Case; the recipient MP-ID's Sparte picks E_0247/E_0204 against E_2011/E_2007.

Stammdaten — ORDERS

Weitere Prozesse

EDIFACT Format Versions

WiM rides eleven message types and they do not share a release cadence, so there is no single WiM format version. The profiles this crate validates against:

INSRPT ships only at FV2026-01-01 (AHB 1.1g, MIG 1.1a), INVOIC and REMADV from FV2026-04-01, ORDCHG at FV2025-04-01 and FV2026-10-01. The AHB and the MIG carry different version numbers for every message type except UTILMD — the tables above name the MIG release, which is what the „EDIFACT" column of the PID inventories cites.

Modules

The invoic family

Both sides run here: the MSB sends with SendInvoic and awaits the REMADV; the NB/LF/ESA ingests with ReceiveInvoic, then settles or disputes.

Replies correlate by conversation ID (RFF+Z13 → the 31009 reference), so they resume this family even though the shared REMADV PID statically resolves to GPKE. The state machine itself is mako-invoic's, shared with the GPKE, GaBi Gas and GeLi Gas billing families; this module declares only the family and the Gas Ablehnungs-Entscheidungsbaum.

Usage

use mako_wim::{WimDeviceChangeWorkflow, DeviceChangeCommand};
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::<WimDeviceChangeWorkflow>(tenant_id, workflow_id);
let events = process.execute(DeviceChangeCommand::ReceiveUtilmd {
    pid: 55042,  // Anmeldung MSB (nMSB → NB)
    // …
}).await?;

Geräteübernahme (WiM Teil 1, Kapitel 3.2)

Adjacent processes sharing the workflow: ORDERS 17002 (Weiterverpflichtung MSBA) answered by ORDRSP 19003/19004, and ORDERS 17009 (Ankündigung Gerätewechselabsicht) answered by ORDRSP 19015/19016.

ESA Wertebestellung (WiM Teil 2, Kapitel 4)

§34 Abs. 2 S. 2 Nr. 10 MsbG makes serving an Energieserviceanbieter a mandatory, non-discriminatory Zusatzleistung, so an MSB must be able to process the order that authorises value delivery and the one that stops it. Both sides are modelled: wertebestellung (MSB) and esa_wertebestellung (ESA), over disjoint PID sets so one deployment may hold both roles.

What is ordered

The esa module holds the Codeliste der Konfigurationen 1.4 Kapitel 4.6 catalogue — the only Messprodukte the role may order — as data: delivery path (4.6.1 EDIFACT back-end vs 4.6.2 SM-PKI from the iMS), Lokationsebene, Werteart, Energieflussrichtung, cadence, and whether BNetzA Mitteilung Nr. 3 makes the product mandatory. A Bestellgegenstand pairs a Messprodukt-Code with the DTM+76 Wunschtermin and the IMD+7081 Abonnement mode, and is carried through both aggregates: without it the process could not say what a confirmed delivery is supposed to contain.

A subscription is the (Meldepunkt, Messprodukt) pair (esa::business_key) — one Marktlokation can carry several products at once, so every follow-up message and command has to say which one it means.

An order is validated against the catalogue before it leaves the system — a product outside Kapitel 4.6, one defined for a different Lokationsebene than the request addresses, or a 4.6.2 product without its SM-PKI target is refused.

The product decides the Lokationsebene (esa::ebene_fuer_messprodukt). REQOTE AHB 1.2 §4.3 gives LOC+172 DE 3225 four permitted shapes and lets the Marktlokations-ID format ([950]) serve both the Marktlokation (hint [502]) and the Tranche (hint [504]), so an identifier cannot resolve the level — and the Tranche carries a Pflichtprodukt (9991 00000 306 4).

„Pflicht" and „nutzbar ab" are two different dates, and both are dates rather than flags: 9991 00000 077 1 and 078 9 read „Optional ab 01.10.2023, Pflicht ab 06.08.2024" while being usable from 01.10.2023. Verbindlichkeit::Pflicht { ab } carries its start and Messprodukt::ist_pflicht_am is what E_0252 Prüfschritt 1 asks — a Vergangenheitswerte-Anfrage may reach back before the cut-over.

The Angebot is a priced offer

UC 4.1.1 has the ESA asking for „die Übermittlung von Werten und die damit verbundenen Kosten". QUOTES AHB 1.1a §4.3 makes the substance Muss — SG4 CUX, one to three SG27 PIA+Z02 Artikel-IDs, one SG31 PRI+CAL each (Z01 Einrichtungs- / Z02 Transaktions- / Z03 Betriebspreis) and one to 23 PIA+5 … :SRW OBIS-Kennzahlen — so esa::Angebot carries all of it and the process keeps it past the Bestellung: it is what the INVOIC 31009 is checked against and what a delivery-surveillance sweep expects to arrive.

It is also the discriminator. DTM+273 is Muss on the only published 15003 use case, so a refusal carries a Bindungsfrist too; the priced position is what tells an Angebot from an Ablehnung.

The Prüfidentifikator is not in BGM

BGM DE 1004 is a Dokumentennummer throughout these handbooks; the PID travels in SG1 RFF+Z13. DE 1001 carries a BDEW document code: Z57 on the order handshake, Z83 on the MSCONS 13027 delivery, Z09 on the IFTSTA 21042.

Correlation

Only the opening REQOTE is keyed on a location. A conformant ORDERS, ORDCHG, ORDRSP or IFTSTA of Kapitel 4 carries no LOC at all and correlates by a Belegnummer, under the Zuordnungsschlüssel the BDEW Anwendungsübersicht der Prüfidentifikatoren 4.0 publishes per PID:

esa::korrelation is that table; the renderer and the ingest dispatcher both read it, so the qualifier they emit and the one they look for cannot drift. Note that the same AGI qualifier sits in a different segment group per message — SG15 on the IFTSTA, SG1 on the MSCONS — which is why the lookup searches by qualifier rather than by position. EZ-03 continues past it to ZO-T20 (Gerätenummer) and ZO-T21 (OBIS-Kennzahl); those two assign the values to a Zählwerk and belong to edmd.

Answers are Antwortcodes, not booleans

SG2 AJT is Muss on all four answer PIDs (ORDRSP AHB 1.1b §4.15) and carries the Prüfschritt code in DE 4465 with its EBD in DE 1082. Conditions [17]/[18] require the code to sit in that tree's Zustimmungs- resp. Ablehnungs-Cluster, so the cluster selects the answer PID. The MSB commands therefore take an antwort_code resolved against mako_pruefung::esa::wertebestellung, never an accept flag alongside it.

And it is the whole content of a refusal on the receiving side too. Those four use cases publish no free-text segment at all: the only FTX a conformant 19011 may carry is SG27 FTX+Z27 — the MSB's IP address, Muss when the confirmed order named a Kapitel-4.6.2 SMGW product (FTX+Z28 for a range), and the source the ESA has to admit before the iMS can reach it.

The ESA side therefore records esa::Antwort, the typed (Antwortcode, EBD) pair, rather than prose — that is what tells A08 (Einwilligung abgelaufen: renew and re-order) from A10 (Lokationsbündel: split the request) from A09 (Gerätetechnik: nothing to retry). Antwort::widerspricht_pid flags a code whose Cluster contradicts the PID that carried it; such an answer is recorded as a conflict and resolved by the PID, since resolving it by the code would silently turn a confirmation into a refusal.

Every inbound step notifies

The MSB-side workflow emits a ProcessInitiated outbox entry on each of 35003/17007/39002/17008. That notification is the entire input to processd's ESA module — the four mako-pruefung walks, the operator queue and its Fristen — and its payload is a contract: every field is a Prüfschritt input, so an omitted one does not fail, it escalates a decision that could have been answered. In particular abo_beginn (the confirmed DTM+203 of the Bestellung) is what E_0254 Prüfschritt 2 compares a requested end against.

What a subscription remembers

Both aggregates keep lieferung_begonnen in their process data, not inside the state variant that happens to be current. It is a fact about the subscription: it has to survive a Storno or Abbestellung round trip, and a first delivery landing while a 39002 is in flight is exactly the case E_0257 A02 exists for. The MSB side additionally remembers its own Bindungsfrist (E_0256 Prüfschritt 1 asks about it one state later), the Abo start, the reach of its latest delivery and any date it already ended on — the three inputs E_0254 Prüfschritte 2–4 need.

An Angebot whose Bindungsfrist lapses is terminal on the ESA side: UC 4.1 Nr. 3 admits no Bestellung after it, so the process releases its (Meldepunkt, Messprodukt) business key rather than blocking every replacement order.

19011/19012 answer both the Bestellung and the Beendigung; the IMD+7081 on the answer is what says which tree its code came from.

Stornierung and Abbestellung are not interchangeable

UC 4.1 Nr. 5 admits a Stornierung only while the einmalige Übermittlung has not happened or the turnusmäßige has not begun; UC 4.3's Vorbedingung then states "Eine Stornierung der Bestellung ist nicht mehr möglich". MarkLieferungBegonnen flips the state that enforces this. On the MSB side the two trees make the boundary explicit: E_0254 A01 refuses a Beendigung of a one-shot order, and E_0257 refuses a Stornierung of a started delivery with different codes per Abo mode (A02 Abo, A03 einmalig).

Regulatory references

• BDEW WiM Wechselprozesse im Messwesen
• MsbG — Messstellenbetriebsgesetz
• BNetzA BK6-24-174 Anlagen 2a/2b (WiM Strom Teil 1 und Teil 2)
• BDEW/VKU/GEODE/FNBGas AWH WiM Gas 2.0 (gültig ab 01.10.2026)
• EDI@Energy UTILMD Strom AHB 2.2 (MIG release S2.2, FV2026-10-01)
• 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

Related crates

The format layer and the domain packs meet in makod: a workflow crate knows the Pruefidentifikator and its own domain types, never an EDIFACT message type.

Part of mako, an open-source Rust platform for German energy market communication (Marktkommunikation). Full documentation: https://hupe1980.github.io/mako/