# Processes by market role

The processes are under two tabs of the header bar: [Electricity
processes](/en/prozesse/strom) and [Gas processes](/en/prozesse/gas). 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.
<Kennzahl was="prozesseOhneKernrolle" /> 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`](https://dokumentation.macoapp.de/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
<Kennzahl was="prozesse" /> 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 **<Kennzahl was="gegenprobenOhneAbweichung" /> of
<Kennzahl was="gegenproben" />** cross-checks. That proves the method, not the individual line.