Business Central: Kreditorenfreigaben mit dem Vier-Au…

Warum Kreditoren eine Freigabe brauchen

Wenn Stammdaten und Bankinformationen geändert werden, sollten Erstellung, Prüfung und Zahlungsfreigabe getrennt sein. Ein Vier-Augen-Prinzip reduziert Risiken und macht Entscheidungen nachvollziehbar.

So würde ich den Workflow aufbauen

Zuerst prüfe ich die vorhandenen Standard-Workflows und Genehmigungseinträge in Business Central. Danach werden die fachlichen Regeln definiert: Pflichtfelder, Bearbeitergruppen, Status, Kommentare, erneute Prüfung bei Bankdatenänderungen und eine Zahlungssperre bis zur Freigabe.

Worauf es technisch ankommt

Wichtig sind konsistente Berechtigungen und eindeutige Statusübergänge. Ablehnungen und Genehmigungskommentare müssen nachvollziehbar bleiben. Bei Änderungen sollte nicht bloß ein Statusfeld gesetzt werden: Die nachgelagerten Buchungs- und Zahlungsprozesse brauchen denselben Sicherheitszustand.

Fazit

Ein guter Genehmigungsprozess verbindet Benutzerführung, Datenqualität und technische Durchsetzung. Für ähnliche Business-Central-Anforderungen kannst du mich kontaktieren.

1. Ziel: Stammdatenprüfung und Zahlungsfreigabe trennen

Das Vier-Augen-Prinzip bedeutet, dass die Person, die einen Kreditor oder kritische Bankdaten erfasst, nicht zugleich die alleinige Freigabe verantwortet. Definiere die Geschäftsregel zuerst schriftlich: Wer darf anlegen, wer darf genehmigen und welcher Zustand verhindert Zahlungen? Eine Freigabe darf nicht lediglich eine farbige Kachel im Rollencenter verändern, sondern muss in nachgelagerten Prozessen wirksam sein.

2. Zustandsmodell entwerfen

Ein mögliches fachliches Modell besteht aus Entwurf → Zur Freigabe eingereicht → Genehmigt / Abgelehnt → Erneute Prüfung erforderlich. Außerdem kann ein Kreditor ohne bestätigten Banknachweis zwar für bestimmte operative Prozesse nutzbar sein, aber für den Zahlungslauf gesperrt bleiben. Diese Zustände solltest du nicht mit einem einzelnen Ja/Nein-Feld vermischen. „Freigegeben“ und „Bankverbindung für Zahlungen bestätigt“ können verschiedene Aussagen sein.

3. Standard-Business-Central-Workflows zuerst prüfen

Untersuche Workflow-Benutzergruppen, Genehmigungsbenutzereinrichtung, Genehmigungsposten sowie Ereignis- und Reaktionsdefinitionen deiner konkreten BC-Version. Verfügbare Standardereignisse können je nach Version variieren. Implementiere ergänzende AL-Events nur dort, wo die fachliche Regel durch den vorhandenen Workflow nicht bereits sauber abgebildet wird.

4. Zuständigkeiten und Vier-Augen-Prüfung

Beispielsweise darf der Einkauf Stammdaten erfassen, während die Finanzbuchhaltung die Bankdaten prüft. Die Freigabe benötigt eine festgelegte Zuordnung zwischen Antragsteller und Genehmiger; eine Selbstgenehmigung muss ausgeschlossen werden, sofern die Richtlinie dies verlangt. Achte bei Benutzergruppen und delegierten Genehmigungen darauf, dass der organisatorische Kontrollgedanke weiterhin gilt.

5. Pflichtfelder vor der Einreichung validieren

Validiere je nach Geschäftsmodell mindestens Name, Anschrift, Ländercode, relevante Zahlungsbedingungen, Zahlungsart und bei zahlungsfähigen Kreditoren die Bankdaten. Ein ungültiger Platzhalter wie N/A sollte für verpflichtende Ländercodes ausdrücklich abgewiesen werden. Nicht alle Felder müssen zwingend schon bei der Erstanlage gefüllt sein: Definiere, welcher Schritt welchen Datenstand benötigt, und gib präzise Fehlermeldungen aus.

6. AL-Erweiterung: einen Status bewusst prüfen

Für eine projektspezifische Lösung kann ein separates Freigabestatusfeld sinnvoll sein. Dieses vereinfachte Beispiel zeigt nur, wie eine fachliche Prüfung gekapselt wird; es implementiert weder eine vollständige Zahlungssperre noch den Genehmigungsworkflow.

enum 50150 "Vendor Review Status"
{
    Extensible = false;
    value(0; Draft) { Caption = 'Draft'; }
    value(1; Pending) { Caption = 'Pending'; }
    value(2; Approved) { Caption = 'Approved'; }
    value(3; Rejected) { Caption = 'Rejected'; }
}
codeunit 50151 "Vendor Review Rules"
{
    procedure RequireApproval(Vendor: Record Vendor)
    begin
        if Vendor.Blocked = Vendor.Blocked::All then
            Error('Vendor %1 is fully blocked.', Vendor."No.");
        // Produktiv: zusätzlich Freigabestatus und Bankstatus
        // in eigenen Tabellen bzw. Feldern prüfen.
    end;
}

Der Code veranschaulicht nicht die komplette Vier-Augen-Kontrolle; die eigentliche Sperrlogik muss auch im Zahlungslauf greifen. Beachte, dass der Standardwert Vendor.Blocked verschiedene fachliche Bedeutungen hat und nicht automatisch alle projektspezifischen Zahlungsregeln abdeckt.

7. Änderungen an IBAN oder Bankkonto erneut freigeben

Wenn IBAN, Bankkontoinhaber oder das für Zahlungen hinterlegte Konto geändert wird, darf eine historische Genehmigung nicht stillschweigend weitergelten. Erfasse den alten und neuen Prüfstand, setze den Zahlungsstatus wieder auf „Prüfung erforderlich“ und dokumentiere den erneuten Antrag. Ein Ereignis auf der Kreditorenkarte allein reicht möglicherweise nicht, da Daten auch über APIs, Konfigurationstabellen oder Importprozesse verändert werden können. Prüfe alle erlaubten Änderungswege.

8. Historie, Ablehnung und Bemerkungen

Speichere Ersteller, Einreichungszeit, Genehmiger, Entscheidungszeit, Entscheidung und nachvollziehbare Bemerkung. Ablehnungen sollen nicht einfach den Datensatz löschen; sie führen zur Korrektur und gegebenenfalls erneuten Einreichung. Für belastbare Prüfpfade dürfen Protokolle nicht durch normale Anwender ohne Nachweis verändert werden.

9. Technische Durchsetzung am Zahlungslauf

Eine Genehmigung, die nur auf einer Page Extension angezeigt wird, ist nicht ausreichend. Definiere den zentralen Prüfpunkt, an dem Zahlungsjournale, Zahlungsdatei-Exports und automatisierte Prozesse denselben Bankfreigabestatus kontrollieren. Prüfe ausdrücklich, ob Buchungen zulässig bleiben, Zahlungen aber blockiert werden sollen. Das ist eine andere Regel als eine vollständige Kreditorensperre.

10. Tests, die den Workflow absichern

Kreditor durch Einkauf anlegen und Freigabe durch dieselbe Person versuchen.
Pflichtfeld fehlt oder Land enthält ungültigen Platzhalter.
Kreditor genehmigen und danach IBAN ändern.
Ohne bestätigten Banknachweis buchen, aber Zahlung versuchen.
Ablehnung mit Bemerkung und anschließende Korrektur durchführen.
Bankdaten über API ändern und prüfen, ob erneute Freigabe erzwungen wird.
Mehrere Genehmigungsanfragen und parallele Entscheidungen testen.

Fazit: Entscheidend ist die gemeinsame Sicherheitsregel aus Workflow, Stammdatenhistorie und technisch erzwungener Zahlungsprüfung. Die konkrete Erweiterung muss immer auf die Business-Central-Version und den Zahlungsprozess abgestimmt werden.

Business Central: Kreditorenfreigaben mit dem Vier-Augen-Prinzip