Copy page

Processes by market role

The processes are under two tabs of the header bar: Electricity processes and Gas processes. Below them on the left, choose your market role: LF, NB, MSB and, under electricity, the further market roles ÜNB, BIKO, BKV and ESA. Within a role the processes are ordered by rulebook (GPKE Part 2, GPKE Part 3, … MaBiS), and within that alphabetically. Choose the format version at the top right.

LF, NB and MSB are the market roles the MACO APP serves as a product. 21 processes concern none of the three; all of them are MaBiS.

A process has a view of its own for each party involved. As the losing supplier you read the contract termination differently from the gaining one: the page title names the party involved (“Contract termination — view LFA”), and at the foot of every page Other views of the process lists the other views, those of your market role first. The address names the party involved as well: /prozessdoku/<fv>/LF--LFA/<prozess>. If a role has only one party involved in a process, it reads /prozessdoku/<fv>/LF/<prozess>.

Role and party involved also appear in the front matter of every page (rolle, beteiligter and, where the source carries a meaning, beteiligter_bedeutung). The machine-readable version at /llms.txt is structured by them.

The structure of a page

At the top: when the process concerns you and what it leaves behind; below: what your backend system sends and receives.

Section	What it contains	For whom first
(no heading)	The header with the badges — participant, regulatory determination with chapter, division, number of steps — and the jumps to the sections. Below it the description of the process as a box, in the wording of the reading version and only where it lists one; otherwise a sentence that the source lists no use-case sheet for this process	Domain page
Process flow from the perspective of the …	The system diagram in three lanes — Backend, MACO APP, Market partner: the triggers, the read accesses, the checks, the messages, the creating or updating of the process data and the follow-up processes that the MACO APP starts itself. Above every arrow to the backend stands API, above every arrow to the market partner the transmission channel and below it the check identifier; a read access points to the backend because the MACO APP calls it	both
Process steps	Per step one card and one sub-entry in On this page: the number from the source, the title and a small box that names the own view on the left (filled) and shows the direction of the message with the arrow. Inside, a sketch in the same three lanes — interfaces with their business name, the message with number and use case —, the check identifiers with plain names and transmission channel in a grey box, and the Flow as a numbered sequence. When sending: where applicable the incoming message after which the MACO APP sends the message itself (Triggered by incoming message), the process trigger with a link into the playground, read accesses, message, writing the process data. When receiving: message, read accesses, APERAK check, writing the process data, further read accesses, the decision tree that the own MACO APP executes, and finally, where applicable, the follow-up process it starts afterwards (Trigger follow-up process). At the message it says in grey according to which decision tree its sender responds (Response per decision tree) — a note, not a check by the MACO APP. Every interface listed in the catalogue carries a link to it and a button to try it out. A step running between other market partners is collapsed; expanded, it says that it is not relevant for this view and names its check identifiers	Implementation
Process information	Preconditions, Results, Error case, Further requirements, Trigger, First message, Objective — as a numbered sequence, each item a sub-entry in On this page, quoted	Domain page
Other views of the process	The same process from the perspective of the other participants	both

Sections that would have nothing to say are left out: where a process has only this one view, there is no negation at the foot, and an item the reading version does not list gets no empty entry.

Every section has its own anchor and therefore its own URL, as does every item of the process information — #fehlerfall jumps to the error case — and every step card: #schritt-3 jumps to the step with number 3 in the source; the card's heading additionally carries the anchor that On this page uses. A step between other market partners is collapsed, not omitted: the search finds its content, and the browser finds text in a collapsed block too.

Where the domain information comes from

Goal, occasion, precondition and result are not summarised but quoted from the use case profile of the BNetzA consolidated version — the sheet that precedes every sequence diagram. The reference with chapter and page number is the first sentence under Process information. Not every one of the 274 processes has this sheet; where it is missing, the page says so.

Curated means: taken from the BNetzA consolidated versions for BK6-24-174, via bnetza-festlegung/. Derived means: reconstructed from the flat BDEW check identifier table, grouped by the name from the sequence diagram. For the six rulebooks available in both sources, the derivation matches the curated view exactly in 200 of 200 cross-checks. That proves the method, not the individual line.