Codeunit / Bericht ausführen

Mit diesem Schritt rufst du eine beliebige AL-Codeunit oder einen processing-only Bericht aus einem Flow heraus auf – deinen vorhandenen Buchungswrapper, den Einstiegspunkt einer Partner-App, einen Batch-Bericht – alles, was bereits als AL-Objekt existiert und das du nicht als eigenständigen AutoFlow-Schritt nachbauen willst.

Typische Anwendungsfälle:

• Eigene Buchungswrapper. Rufe deinen vorhandenen Sales-Post (Yes/No)-Wrapper auf, nachdem ein Flow das Dokument vorbereitet hat.
• Partner-App-Integrationen. Eine Drittanbieter-App stellt eine Codeunit als Einstiegspunkt bereit – steuere sie aus einem Flow ohne Klebcode.
• Batch-Verarbeitungs-Berichte. Lasse einen processing-only Bericht (z.B. Plan berechnen, Lieferantenzahlungen vorschlagen) jede Nacht mit gespeicherten Anfragepage-Filtern laufen.

Schritt konfigurieren

Öffne den Flow-Editor, füge Codeunit / Bericht ausführen ein und befülle die Konfig-Karte.

Beschreibung

Aussagekräftige Beschreibung des Schritts. Wird im Editor und in der Ausführungs-Historie angezeigt. Benenne die Operation, nicht das Objekt – Verkaufsauftrag buchen liest sich besser als Codeunit 80 ausführen.

Objekttyp

Wählt zwischen Codeunit und Bericht. Default ist Codeunit. Ein Typ-Wechsel leert die Objekt-Auswahl, damit der Picker-Filter zum neuen Typ passt.

Objekt

Die aufzurufende AL-Codeunit oder der aufzurufende Bericht. Der Picker respektiert den Objekttyp. Bei Codeunits werden nur Subtype = Normal gelistet; eine kleine Sperrliste lehnt Codeunits ab, deren Aufruf aus einem Flow den System-Zustand zerstört (siehe Sperrliste unten). Berichte aller Art werden gelistet, der Schritt funktioniert aber am besten mit processing-only Berichten – Ausgabe von Layout-Berichten wird verworfen.

Quellen-Datensatz-Referenz

Optional. Übergibt einen Datensatz an den OnRun-Trigger der Codeunit bzw. als Datensatz des Berichts. Pflicht, wenn die Codeunit eine TableNo deklariert oder wenn der äußerste DataItem des Berichts auf einen einzelnen Datensatz gefiltert sein soll.

Geklammerter SmartField-Platzhalter, z.B. {{customer}}. Alt+S öffnet den SmartField-Picker. Die empfangende Codeunit oder der Bericht sieht einen normalen typisierten Datensatz – keine generische Datensatz-Referenz.

Berichtsparameter

Nur sichtbar, wenn Objekttyp = Bericht. Über Assist-Edit öffnet sich die Anfragepage des Berichts; nach OK wird die Konfiguration gespeichert. Leer heißt „Bericht-Defaults".

Lässt sich der Bericht aus AutoFlows App-Abhängigkeiten nicht erreichen (typischerweise Berichte aus Lokalisierungen oder Branchen-Add-ons, von denen AutoFlow nicht abhängt), wirft das Assist-Edit einen klaren Fehler mit Bericht-Nennung – einen anderen Bericht wählen oder die Abhängigkeit zu AutoFlow ergänzen.

XML bearbeiten

Sobald Parameter konfiguriert sind, öffnet die Aktion XML bearbeiten einen separaten Editor, in dem du die rohen Anfragepage-Parameter als XML anpasst. Hilfreich, wenn du SmartField-Platzhalter in die Parameter einfügen willst, damit der Bericht zur Laufzeit mit Werten aus dem Flow läuft.

Platzhalter verwenden dieselbe {{slug.output}}-Syntax wie der restliche Flow-Editor. Alt+S im Editor öffnet den SmartField-Picker; der gewählte Platzhalter wird in die Zwischenablage kopiert, sodass du ihn an der Cursorposition einfügen kannst.

Wechselseitiger Ausschluss mit der Anfragepage. Sind SmartField-Platzhalter erst einmal im XML gespeichert, kann die Anfragepage diese Parameter nicht mehr öffnen – sie würde die Platzhalter als typisierte XML-Werte parsen wollen und scheitern. Weiter über XML bearbeiten anpassen oder mit Berichtsparameter zurücksetzen von der Anfragepage neu beginnen.

Typisierte Felder. Ersetzungswerte werden unverändert in das XML übernommen. Text-Felder sind nachsichtig; typisierte Felder (Datum, Decimal, Boolean, Integer …) verlangen das Format, das BCs Anfragepage erwartet – sonst scheitert der Bericht mit einem NavType-Parse-Fehler. Ein SmartField-Format-Suffix ({{name;<format>}}) bringt den Wert in die Form, die der Parser erwartet – ;9 ist BCs XML-Format und genau das, was die Anfragepage erwartet:

<Field name="StartDate">{{trigger.postingDate;9}}</Field>

Das ergibt 2026-05-26 für ein Datum, 1234.56 für eine Decimal, true/false für einen Boolean – Formate, die der Parser in jeder Locale akzeptiert. Derselbe ;9-Suffix funktioniert für alle typisierten Werte.

Kann ein Ersetzungswert &, < oder > enthalten, escape ihn selbst (&, <, >).

Verhalten

Der Schritt ruft die Codeunit bzw. den Bericht auf und übergibt den aufgelösten Datensatz, falls einer konfiguriert ist. Der Boolesche success-Output wird gesetzt, wenn der Aufruf sauber zurückkehrt. Wirft das Zielobjekt einen Fehler, schlägt der Schritt mit der echten Fehlermeldung fehl (Codeunit 80 failed: Buchungsdatum X liegt außerhalb des erlaubten Bereichs o.ä.) und der Flow folgt deinem normalen Fehler-Pfad.

Das Zielobjekt läuft in einer eigenen Transaktion, unabhängig vom Flow. Alles, was es schreibt – ein gebuchtes Dokument, ein modifizierter Datensatz, ein Posten – wird unabhängig von späteren Flow-Schritten committet. Der Flow kann die Arbeit des Ziels nicht durch späteren Misserfolg zurückrollen. Plane den Flow so, dass ein erfolgreicher Aufruf eine sinnvolle Commit-Grenze ist.

Outputs

Output	Typ	Beschreibung
success	Wert (Boolean)	Nach erfolgreichem Aufruf auf true gesetzt. Fehler stoppen den Schritt per Error – es gibt also keinen false-Wert, auf den man verzweigen müsste.

Sperrliste

Eine kleine Menge an Standard-BC-Codeunits wird abgelehnt, sowohl zur Konfig- als auch zur Laufzeit. Berichte werden nicht gesperrt.

Codeunit	Begründung
1 – ApplicationManagement	Legacy-System-Bootstrap-Hook; ein erneuter Aufruf korrumpiert den Startup-Zustand.
2 – Company-Initialize	Schreibt sämtliche Standard-Konfig-Tabellen zurück; ein Lauf reicht, um einen produktiven Mandanten in einen inkonsistenten Setup-Zustand zu bringen.
40 – LogInManagement	Steuert die Login-Pipeline; Aufruf außerhalb des Login-Kontexts korrumpiert Session-Zustand.
357 – DateComprRegister	Datums-Komprimierung – unumkehrbare Datenzerstörung.
358 – DateComprMgt	Datums-Komprimierung – unumkehrbare Datenzerstörung.

Codeunits mit Subtype = Test, Install oder Upgrade werden ebenfalls abgelehnt – ihre Lifecycles sind auf einen einzigen, vom Framework gesteuerten Aufruf ausgelegt.

Best Practices

• Processing-only Berichte für Batch-Arbeit bevorzugen. Berichte mit Layout (PDF / Word / Excel) erzeugen Output, den dieser Schritt verwirft. Wenn du eine Datei willst, nutze den Schritt PDF-Dokument erstellen.
• Schwere Objekte nicht in engen Schleifen. Manche legitimen Codeunits/Berichte – Adjust Cost - Item Entries, Datums-Komprimierung, Plan berechnen – machen viel I/O und halten lange Tabellen-Locks. Nicht aus einem For Each Loop über Tausende Zeilen aufrufen; vorher batchen.
• Daten-Zerstörung nicht als Flow-Logik tarnen. Wenn ein Schritt „lösche viele Zeilen" bedeutet, lieber den typisierten Records löschen-Schritt verwenden (der Audit-Einträge ins Execution-Log schreibt) statt eine eigene Lösch-Codeunit per Run auszuführen.