ORDERS und IFTSTA einordnen

Kurzantwort

ORDERS und IFTSTA sind Nachrichtentypen im EDIFACT-Format der Marktkommunikation. ORDERS transportiert Aufträge oder Anforderungen – etwa Anforderungen von Stammdaten oder Messwerten – und wird in WiM- und MaBiS-Prozessen verwendet. IFTSTA meldet den Status oder Transportfortschritt eines Geschäftsvorgangs und hilft damit, den Bearbeitungsstand nachzuverfolgend zu überwachen.

Zusammen mit den Datennachrichten (UTILMD, MSCONS) und den Rückmeldungen (CONTRL, APERAK) bilden ORDERS und IFTSTA die Schicht der prozesssteuernden Nachrichten. Der entscheidende Unterschied: ORDERS ist eine Anforderung, IFTSTA ist eine Statusmitteilung zu einem bereits laufenden Prozess – keine Rückmeldung zur Nachrichtenebene, sondern ein Geschäftsfortschritt im Prozess.

Wann und warum ORDERS gesendet wird

ORDERS ist eine Anforderungsnachricht. Ein Marktpartner sendet sie, wenn er Daten oder Informationen von einem anderen Marktpartner benötigt, aber diese nicht automatisch oder regelmäßig übermittelt werden. Das ist der Kernunterschied zu UTILMD oder MSCONS, die Daten enthalten: ORDERS fordert an.

Typische Anlässe sind:

• Anforderung von Messwerten: Ein Lieferant fordert vom Messstellenbetreiber die Zählerstände oder Lastgänge einer Messlokation an, etwa für die Abrechnung oder Abgrenzung.
• Anforderung von Stammdaten: Ein Netzbetreiber fordert vom Messstellenbetreiber Informationen zu einer Messlokation an, etwa zur Verarbeitung eines Zählerwechsels.
• Anforderung von Konfigurationsinformationen: Bei Messkonfigurationen oder Schaltgeräten können Anforderungen die Einstellung oder den aktuellen Status erbitten.

Im Gegensatz zu einer regelmäßigen MSCONS-Lieferung (Messwerte) ist ORDERS eine punktuelle Anforderung, die eine konkrete Antwort erwartet. Die Antwort wird in der dafür vorgesehenen Nachricht gegeben – etwa MSCONS für Werte oder UTILMD für Stammdaten. Der Prozess ist damit nicht linear (Anforderung → Antwort), sondern verzweigt sich je nach Inhalt der Anforderung.

Aufbau und Handhabung von ORDERS

Eine ORDERS-Nachricht enthält die klassischen Felder einer Anforderung: Wer fordert an, von wem, was wird angefordert, für welchen Zeitraum oder Kontext? Dazu kommt der Bezug zur Marktlokation oder Messlokation und gegebenenfalls weitere Qualifikationen.

Der Prüfidentifikator in der ORDERS-Nachricht legt fest, welche Art von Anforderung gemeint ist. Unterschiedliche Anforderungen nutzen unterschiedliche Codes, und der Empfänger muss diese Differenzierung korrekt interpretieren. Eine Anforderung von Zählerstellen beispielsweise nutzt einen anderen Code als eine Anforderung von Lastgängen.

Das Anwendungshandbuch beschreibt für jeden Anforderungstyp:

• Welche Felder erforderlich sind.
• Welche Wertebereiche gelten.
• Welche Folgeaktion der Empfänger durchführt.
• Innerhalb welcher Frist eine Antwort erwartet wird.

Wer eine ORDERS verarbeitet, muss also prüfen, ob die erforderlichen Felder vorhanden sind und ob die Anforderung zu diesem Zeitpunkt zulässig ist. Etwa kann eine Anforderung von Werten nach einem Lieferantenwechsel zu früh kommen, wenn die Messlokation noch keinem neuen Messstellenbetreiber zugeordnet ist.

IFTSTA: Statusmeldungen für laufende Prozesse

IFTSTA ist eine Nachricht für Statusmitteilungen. Im Gegensatz zu ORDERS ist IFTSTA kein Auftrag, sondern eine Information über den aktuellen Stand eines laufenden Prozesses. Ihr Name „Instructions for a Consignment” deutet ursprünglich auf Versand und Verfolgung hin; in der deutschen Marktkommunikation nutzt man sie für den Status von energiewirtschaftlichen Geschäftsvorgängen.

IFTSTA wird verwendet, um:

• Den Bearbeitungsstand eines Vorgangs mitzuteilen (z. B. „Anforderung empfangen”, „Verarbeitung läuft”, „fertiggestellt”).
• Zwischenergebnisse oder Wartetage zu signalisieren.
• Fehlschläge oder Verzögerungen nachvollziehbar zu dokumentieren.

Ein vereinfachtes Beispiel: Ein Messstellenbetreiber hat einen Auftrag zur Änderung der Messkonfiguration empfangen. Er sendet eine IFTSTA, um dem Auftraggeber zu melden: „Wir haben die Anforderung erhalten und beginnen die Umsetzung.” Später sendet er erneut IFTSTA: „Die Änderung ist abgeschlossen.” Diese Sequenz ermöglicht dem Auftraggeber, den Fortschritt zu überwachen, ohne selbst regelmäßig nachfragen zu müssen.

Die kritische Unterscheidung liegt darin: IFTSTA ist nicht eine Rückmeldung zur Nachricht (wie CONTRL oder APERAK), sondern eine Geschäftsmitteilung, die den Prozessfortschritt beschreibt. Sie gehört zum Fachprozess, nicht zur Übertragungsebene.

Abgrenzung zu UTILMD, MSCONS, CONTRL und APERAK

Die Marktkommunikation nutzt verschiedene Nachrichtentypen, die sich klar voneinander unterscheiden:

Diese Tabelle zeigt ein häufiges Missverständnis: ORDERS und IFTSTA sind wie UTILMD und MSCONS Geschäftsnachrichten – sie transportieren geschäftliche Informationen. Im Gegensatz dazu sind CONTRL und APERAK Rückmeldungen auf der Ebene der Nachrichtenübertragung.

Konkret heißt das: Ein Netzbetreiber sendet eine ORDERS-Anforderung an einen Messstellenbetreiber. Dieser quittiert mit CONTRL (Datei angekommen, Syntax ok) und APERAK (Nachricht fachlich angenommen). Dann beginnt der Messstellenbetreiber die Verarbeitung und sendet IFTSTA-Statusmeldungen. Schließlich sendet er die angeforderten Daten in MSCONS oder UTILMD. Dies ist die vollständige Kette: Anforderung → Technik-Quittung → Anwendungs-Anerkennung → Statusmeldung → Datennachricht.

ORDERS und IFTSTA in WiM und MaBiS

WiM Strom (Wechselprozesse im Messwesen) nutzt ORDERS regelmäßig. Zum Beispiel fordert ein Lieferant nach einem Wechsel des Messstellenbetreibers die Messwerte der bisherigen Periode an. Der neue Messstellenbetreiber empfängt die ORDERS und bestätigt mit IFTSTA, dass die Anforderung bearbeitet wird. Danach übermittelt er die Werte per MSCONS.

MaBiS (Marktregeln für die Bilanzkreisabrechnung) nutzt IFTSTA zur Verfolgung von Abrechnungsprozessen. Ein Bilanzkreisverantwortlicher kann den Status einer Abrechnung oder einer Korrekturaktion nachverfolgend überwachen. Dies ist besonders in längeren Abläufen hilfreich, wenn mehrere Tage zwischen Anforderung und Lieferung vergehen.

Für beide Regelwerke gilt: ORDERS und IFTSTA sind keine eigenständigen Prozesse, sondern Bausteine innerhalb von GPKE-, WiM- oder MaBiS-Prozessen. Ein Messstellenbetreiber verarbeitet eine ORDERS nicht isoliert – er ordnet sie immer einem Prozesskontext zu. Das Anwendungshandbuch zeigt, welche ORDERS-Typen in welchem Kontext zulässig sind.

Typische Fehler in der Verarbeitung

Ein häufiger Fehler liegt darin, ORDERS wie UTILMD zu behandeln – als ob sie Daten transportieren würden. Stattdessen brauchen eingehende ORDERS besondere Behandlung:

• Prüfung auf Zulässigkeit: Ist die Anforderung zum aktuellen Zeitpunkt erlaubt? (Beispiel: Kann man Messwerte anfordern, bevor der Messstellenbetreiber zugeordnet ist?)
• Zuweisung an den richtigen Prozess: Welcher Geschäftsvorfall ist gemeint? Das Anwendungshandbuch zeigt die Codes.
• Fristgerechte Antwort: ORDERS unterliegen Bearbeitungsfristen. Eine verspätete Antwort ist eine Verarbeitungsstörung.

Ein weiterer Fehler betrifft IFTSTA: Sie als Rückmeldung auf Nachrichtenebene zu missinterpretieren. IFTSTA ersetzt weder CONTRL noch APERAK. Ein Sender kann nicht davon ausgehen, dass IFTSTA die technische Annahme bestätigt. CONTRL und APERAK gehören zur Übergabe, IFTSTA zum Geschäftsprozess.

Ferner: IFTSTA ist kein Abschluss. Eine Statusmeldung „fertiggestellt” ist noch keine finale Bestätigung oder Geschäftsantwort. Der Prozess kann danach noch weitere Schritte haben – etwa die Lieferung der angeforderten Daten oder eine endgültige Bestätigung. IFTSTA zeigt nur: „Wir sind bei Schritt X, alles läuft nach Plan” oder „Es gibt ein Problem.”

SAP-IS-U-Sicht: Anforderungen und Statusverfolgung

In SAP-IS-U-Systemen kommen ORDERS und IFTSTA über Schnittstellen zur Marktkommunikation an. Das System muss sie unterschiedlich verarbeiten:

ORDERS verarbeiten:

• Eingehende ORDERS müssen der richtigen Marktlokation oder Messlokation zugeordnet werden.
• Der Prüfidentifikator entscheidet, welcher Prozess in IS-U ausgelöst wird (Werteanforderung → Messwertlese-Prozess, Stammdatenanforderung → Stammdaten-Änderungsmanagement).
• Das System muss prüfen, ob die Anforderung zu den aktuellen Stammdaten passt (z. B. existiert die angeforderte Messlokation, ist sie dem Messstellenbetreiber zugeordnet?).
• Innerhalb der definierten Frist muss eine Antwort erzeugt werden – entweder die angeforderten Daten oder eine Ablehnung mit Begründung.

IFTSTA verarbeiten:

• Eingehende IFTSTA sollten einem ausgehenden Vorgang zugeordnet werden (z. B. einer ORDERS, die das eigene System versandt hat).
• Der Status wird dokumentiert und kann für Monitoring und Nachverfolgung verwendet werden.
• Fehlerstatus oder Verzögerungsmeldungen müssen an den Betrieb eskaliert werden.
• Das System führt ein Audit-Trail: Wann kam welcher Status an?

Ohne klare Zuordnung und Statusverfolgung entstehen Lücken. Etwa kann eine Anforderung versandt sein, aber die Statusmeldung nicht bei der richtigen Stelle ankommen. Gutes Monitoring verbindet beide: „Wir haben diese ORDERS am 09.09. versandt, am 10.09. kam IFTSTA mit Status ‚verarbeitet’, aber bis heute keine MSCONS mit den Werten.” So wird ein Überwachungsfall sichtbar, bevor ein Fehler zum Datenproblem wird.

Typische Missverständnisse

„ORDERS ist dasselbe wie UTILMD.“
Nein. UTILMD transportiert Daten selbst. ORDERS fordert Daten an. ORDERS löst eine Aktion aus, UTILMD liefert das Ergebnis einer Aktion.

„IFTSTA ist eine Rückmeldung wie CONTRL oder APERAK.“
Nein. IFTSTA ist eine Geschäftsmitteilung zum Prozessfortschritt. CONTRL und APERAK sind Rückmeldungen auf der Übertragungsebene.

„Eine positive IFTSTA beendet den Prozess.“
Nein. IFTSTA zeigt nur: Der aktuelle Schritt läuft oder ist abgeschlossen. Der Gesamtprozess kann danach noch weitere Stufen haben.

„ORDERS muss innerhalb der gleichen Datei wie UTILMD versendet werden.“
Nicht zwingend. ORDERS und UTILMD sind getrennte Nachrichtentypen und können in getrennten Übertragungen versandt werden.

„IFTSTA wird automatisch versendet.“
Nein. IFTSTA wird wie ORDERS durch einen Geschäftsvorfall ausgelöst. Ein Messstellenbetreiber muss aktiv entscheiden, wann er eine IFTSTA sendet.

Quellen und Pflegehinweis

ORDERS und IFTSTA sind in den aktuellen Mitteilungen der Bundesnetzagentur zu den Datenformaten dokumentiert. Die Versionen ändern sich mit den Umsetzungsterminen. Im September 2026 sind folgende Versionen relevant:

• ORDERS: Version 1.1 (Stand 03.02.2025, Konsultation abgelaufen, Umsetzung geplant Oktober 2025)
• IFTSTA: Version 2.0g/2.0h und 2.1 (Stand 2026, aktuell in Umsetzung)

Die genauen Anwendungshandbücher und Nachrichtenbeschreibungen werden von der Bundesnetzagentur über EDI@Energy veröffentlicht. Wer ORDERS oder IFTSTA implementiert, muss die zum Umsetzungstermin gültige Fassung prüfen, insbesondere nach Mitteilungen der Bundesnetzagentur zu den Datenformaten. Die oben genannten Links führen zu den relevanten Mitteilungen und Dokumenten.

• Bundesnetzagentur: Mitteilung Nr. 48
• Bundesnetzagentur: Mitteilung Nr. 40
• Bundesnetzagentur: Allgemeine Festlegungen zu den EDIFACT-Nachrichten
• EDI@Energy: Datenformate für die Marktkommunikation
• Bundesnetzagentur: GPKE Teil 2 (Lesefassung)

Abrufdatum aller Quellen: 9. September 2026.