Muss, Kann und Bedingung im AHB

Kurzantwort

Ein Muss verlangt die Angabe im gewählten Anwendungsfall. Ein Kann erlaubt eine Angabe, macht sie aber nicht automatisch fachlich passend. Eine Bedingung entscheidet, ob ein Feld, eine Segmentgruppe oder ein bestimmter Wert überhaupt relevant wird. Lies deshalb die Kennzeichnung immer zusammen mit der Bedingung, der Beschreibung, dem Prüfidentifikator und der gültigen Version des AHB.

Die sichere Übersetzung lautet: Vorgang bestimmen, Bedingung aus den Geschäftsdaten auswerten, danach die zugelassenen Felder und Codes befüllen. Ein fehlendes Mussfeld und ein unnötig gesendetes bedingtes Feld erzeugen unterschiedliche Fehler. Beide entstehen, wenn die Tabelle wie eine einfache Wunschliste gelesen wird.

Einordnung: Wo steht die Regel?

Das Anwendungshandbuch (AHB) beschreibt die fachliche Belegung einer Nachricht für einen konkreten Anwendungsfall. Der Nachrichtentyp allein reicht nicht. UTILTS, PRICAT oder ein anderer EDIFACT-Nachrichtentyp kann mehrere fachliche Situationen abbilden.

Das AHB arbeitet dabei mit Tabellen. Typische Spalten enthalten Segment- und Datenelementposition, Belegung, Bedingung, Beschreibung, Format und Wertebereich. Die Belegung beantwortet die erste Frage. Die Bedingung erklärt, wann diese Antwort gilt.

Die AHBs verweisen für die Tabellennotation auf die Allgemeinen Festlegungen. In den veröffentlichten Anwendungshandbüchern finden sich deshalb neben Muss, Soll und Kann auch Kennzeichnungen wie X, O oder U. Ihre genaue Bedeutung gehört zur jeweils gültigen Dokumentversion. Übertrage keine Abkürzung aus einem alten AHB in ein neues, ohne die dort verlinkte Definition zu prüfen.

Modell: Aus einer Zeile wird eine Entscheidung

Die drei Begriffe liegen auf verschiedenen Ebenen. Muss und Kann beschreiben die zulässige oder erforderliche Belegung im Anwendungsfall. Die Bedingung beschreibt den fachlichen Auslöser. Ein Kann-Feld kann deshalb zusätzlich eine Bedingung haben. Dann bedeutet Kann „bei erfüllter Bedingung zulässig oder vorgesehen“.

Muss

Bei einem Mussfeld muss der Absender eine fachlich passende Angabe liefern, sobald der Anwendungsfall die Zeile einschließt. Das Feld darf nicht mit einem beliebigen Platzhalter gefüllt werden. Ein leerer Text, ein Fantasiewert oder ein Code aus einer anderen Codeliste erfüllt die Pflicht nicht.

Prüfe drei Dinge:

1. Existiert die Information im Geschäftsvorfall?
2. Passt sie zur beschriebenen Rolle, Lokation und zeitlichen Gültigkeit?
3. Entspricht sie Format und Wertebereich des AHB beziehungsweise der referenzierten Codeliste?

Fehlt die Information, hältst du den Vorgang im Klärfall an oder wählst einen fachlich passenden Fehler- beziehungsweise Rückmeldeprozess. Du erfindest keinen Wert, damit die Nachricht technisch vollständig aussieht.

Kann

Ein Kannfeld darf der Absender belegen, wenn die fachliche Situation die Angabe trägt. Das Feld erweitert die Nachricht. Es ändert den Geschäftsvorfall nicht eigenständig.

Ein Kannfeld kann beispielsweise eine zusätzliche Referenz oder eine ergänzende Beschreibung aufnehmen. Die Beschreibung im AHB legt fest, welche Information dort hingehört. Ein vorhandener Wert aus dem Quellsystem genügt nicht als Begründung. Frage zuerst, ob der Wert für diesen Anwendungsfall vorgesehen ist und ob seine Übermittlung eine weitere Bedingung auslöst.

„Kann“ bedeutet außerdem nicht, dass der Empfänger jeden beliebigen Wert akzeptieren muss. Auch optionale Werte müssen formal gültig sein. Bei einer Codeliste bildet der Code die fachliche Aussage. Ein Freitext mit derselben Bedeutung ist kein Ersatz.

Bedingung

Eine Bedingung verknüpft die Belegung mit einer fachlichen Tatsache. Der Auslöser kann in einem anderen Feld, im Anwendungsfall, in einer Konfiguration oder in den Stammdaten liegen. Beispiele sind eine bestimmte Messart, eine vorhandene Preisangabe, eine Änderung mit Wirksamkeitsdatum oder eine besondere Marktrolle.

Lies die Bedingung als Prüfregel:

1. Benenne die Tatsache in Klartext.
2. Ermittle sie aus den fachlichen Eingangsdaten.
3. Entscheide, ob sie wahr, falsch oder ungeklärt ist.
4. Bei wahr: abhängige Angaben und ihre Wertebereiche prüfen.
5. Bei falsch: die bedingte Angabe weglassen, sofern die Tabelle nichts anderes festlegt.
6. Bei ungeklärt: den Vorgang klären, statt einen Standardfall anzunehmen.

Die letzte Regel schützt vor einer häufigen Übersetzungsfehlerquelle: Ein System setzt „unbekannt“ stillschweigend mit „nein“ gleich. Das kann ein Mussfeld unterschlagen oder eine fachlich falsche Nachricht erzeugen.

Ablauf in der Praxis

Beginne mit einem Satz: „Welche Marktrolle teilt welcher anderen Rolle welchen Sachverhalt mit?“ Notiere anschließend Nachrichtentyp, AHB-Version, Anwendungsfall und Prüfidentifikator. Diese Auswahl bildet den Rahmen für jede einzelne Tabellenzeile.

Lies die Tabelle danach von links nach rechts. Markiere Mussfelder in der Arbeitsliste. Übertrage die Bedingungen als ausführbare Prüfungen. Für jedes Kannfeld dokumentierst du, welches Quellsystem oder welcher fachliche Anlass die Belegung liefert.

Danach prüfst du Segmentgruppen und Wiederholungen. Ein Kannfeld innerhalb einer Muss-Segmentgruppe bleibt nicht automatisch optional auf Gruppenebene. Umgekehrt kann eine Kann-Segmentgruppe ein enthaltenes Mussfeld haben: Sobald du die Gruppe verwendest, musst du ihr Mussfeld befüllen.

Zum Schluss folgt die technische Prüfung. Kontrolliere Datumsformat, Dezimaldarstellung, Code, Länge, Reihenfolge, Wiederholbarkeit und die erlaubten Sonderzeichen nach MIG und Codeliste. Eine syntaktisch korrekte Nachricht ist erst nach der fachlichen Prüfung versandbereit.

Vereinfachtes Beispiel: bedingte Preisangabe

Angenommen, ein AHB beschreibt einen Anwendungsfall für eine Preisnachricht. Die folgende Mini-Tabelle ist ein vereinfachtes Lernmodell. Sie stellt keine konkrete AHB-Zeile und keine produktive Codeliste dar.

Der Eingangsvorgang enthält eine gültige Lokations-ID und einen preisbezogenen Vorgang. Das System löst die Bedingung aus. Es sendet die Lokations-ID, das Preiskennzeichen, den Preis und die Preisbasis. Die Preisbasis wird zum Muss, weil die optionale Preisgruppe verwendet wird und das AHB sie innerhalb dieser Gruppe fordert.

Fehlt der Preis, darf das System die Gruppe nicht einfach mit „0,00“ retten. Es muss klären, ob der Vorgang tatsächlich preisbezogen ist oder ob die Bedingung falsch ausgelöst wurde. Ein Nullwert wäre eine fachliche Aussage und kein leerer Ersatz.

Enthält der Vorgang keinen Preis, bleibt die Preisgruppe im Lernmodell weg. Das System sendet trotzdem die beiden allgemeinen Mussangaben. Genau diese Trennung verhindert, dass optionale Inhalte versehentlich zum Standard werden.

Folgen und Fehlerfälle

Mussfeld fehlt: Der Empfänger kann die Nachricht syntaktisch oder fachlich ablehnen. Die Ursache liegt oft schon vor dem EDIFACT-Parser: Das Quellsystem hat einen erforderlichen Geschäftswert nicht geliefert.

Bedingung falsch ausgewertet: Das System sendet eine unpassende Segmentgruppe oder lässt eine erforderliche Gruppe weg. Der Empfänger kann daraus einen anderen Sachverhalt lesen, als der Absender beabsichtigt.

Kannfeld pauschal befüllt: Zusätzliche Angaben können eine weitere Bedingung aktivieren oder widersprüchliche Stammdaten transportieren. „Alles mitsenden“ erhöht die fachliche Angriffsfläche.

Gruppe und Feld verwechselt: Eine optionale Gruppe kann Pflichtfelder enthalten. Wer nur die Kennzeichnung des inneren Felds betrachtet, erzeugt unvollständige Nachrichten.

Version verwechselt: Ein neues AHB kann Bedingungen, Codes oder Positionen ändern. Prüfe den Umsetzungstermin und die von der Bundesnetzagentur beziehungsweise EDI@Energy veröffentlichte Version, bevor du Regeln in Software oder Mappingtabellen festschreibst.

Typische Missverständnisse

„Kann“ heißt „immer erlaubt“

Ein Kannfeld bleibt an den Anwendungsfall und seine Bedingungen gebunden. Es erlaubt keine Information, die dort fachlich keinen Platz hat.

„Muss“ gilt für jede Nachricht dieses Typs

Die Pflicht gilt für die ausgewählte Belegung. Ein Nachrichtentyp umfasst oft mehrere Anwendungsfälle. Wechsle der Prüfidentifikator, kann sich die Tabellenbelegung ändern.

Eine technische Pflicht ersetzt die fachliche Regel

Ein Parser kann ein Format prüfen. Er erkennt dadurch nicht zuverlässig, ob eine Lokations-ID zum Vorgang, zur Rolle und zum Gültigkeitsdatum passt. AHB, MIG und Codeliste beantworten verschiedene Fragen.

Ein leeres Feld ist dasselbe wie „nicht belegt“

Ein leeres Datenelement kann die Struktur oder die Validierung verletzen. Wenn eine Angabe nicht vorgesehen ist, lässt du das Feld beziehungsweise die Gruppe nach den AHB-Regeln weg.

Ungeklärt darf wie „nein“ behandelt werden

Eine unbekannte Eingangsinformation braucht einen Klärfall oder eine definierte Prozessentscheidung. Das System darf die Bedingung nicht stillschweigend in eine negative Entscheidung umwandeln.

Quellen und Pflegehinweis

Dieser Artikel stützt die Tabellennotation und die Beispiele auf die veröffentlichten EDI@Energy-Anwendungshandbücher der Bundesnetzagentur. Die UTILTS-Version 1.0b und die UTILTS-Version 1.0a zeigen, dass die Definition der Tabellennotation auf die Allgemeinen Festlegungen verweist. Das PRICAT AHB 2.0f und das HKNR AHB 2.0a dienen als weitere Primärquellen für die AHB-Lesart.

Geprüft am 10. September 2026. Vor einer produktiven Umsetzung prüfst du erneut die gültige AHB-Version, die Allgemeinen Festlegungen, die Codelisten und den Umsetzungstermin. Besonders versionsabhängig sind Kennzeichnungen, Bedingungen, Codes und die zulässige Wiederholung von Segmentgruppen.