FD32 in SAP: Tutorial zum Kreditkontrollbereich

⚡ Intelligente Zusammenfassung

Kreditkontrolle in SAP Das Risiko von Forderungsausfällen wird begrenzt, indem jedem Kunden innerhalb eines Kreditkontrollbereichs ein Kreditlimit zugewiesen wird. Die Transaktion FD32 ist der klassische Bildschirm, auf dem dieses Limit verwaltet wird.

  • 🔘 Umfang: Ein Kreditkontrollbereich kann für jeden Firmencode zuständig sein, oder jeder Firmencode kann seinen eigenen Bereich haben.
  • ☑️ Transaktion: FD32 öffnet den Kundenkreditstammsatz, in dem zuerst der Kunde, der Kreditkontrollbereich und die Datenabschnitte ausgewählt werden.
  • Zentrale Daten: Der Gesamtbetrag begrenzt das Kreditvolumen über alle Bereiche hinweg, während das individuelle Limit das Kreditvolumen innerhalb eines einzelnen Bereichs begrenzt.
  • 🧪 Statusdaten: Die automatische Bonitätsprüfung wird durch das Kreditlimit, die Risikokategorie und die Überprüfungstermine auf dem Statusbildschirm gesteuert.
  • Konfiguration: OB45, OB38, OVFL, OB01 und OVA8 erstellen den Kreditkontrollbereich und die Schecks, die ihn verwenden.
  • 📈 S/4HANA: FD32 ist nicht verfügbar in SAP S/4HANA, wo die Geschäftspartnerrolle UKM000 den klassischen Kreditstammsatz ersetzt.

Aufrechterhaltung eines Kundenkreditlimits mit FD32 in SAP

Mehrere offene Forderungen oder Forderungsausfälle können die Geschäftsentwicklung eines Unternehmens erheblich beeinträchtigen. Durch ein effektives Kreditmanagement wird dieses Risiko reduziert, indem für jeden Kunden ein Kreditlimit festgelegt und jede neue Bestellung anhand dieses Limits geprüft wird.

Was ist ein Kreditkontrollbereich in SAP?

In SAPDas Kredit- und Risikomanagement findet im Bereich Kreditkontrolle statt. Bei zentralisierter Kreditverwaltung kann ein Kreditkontrollbereich für alle Buchungskreise definiert werden. Erfordert die Kreditrichtlinie eine dezentrale Verwaltung, kann ein Kreditkontrollbereich für jeden Buchungskreis oder für jede Gruppe von Buchungskreisen definiert werden.

Der Bereich Kreditmanagement ist somit die Organisationseinheit, die Kundenkreditlimits definiert und kontrolliert. Er verfügt über eine eigene Währung, und jede in diesem Bereich verbuchte Forderung wird in dieser Währung erfasst. Forderungen erhöht das damit verbundene Kreditrisiko.

Der Bereich Kreditkontrolle regelt insbesondere drei Dinge.

  • Grenze: Der maximale Forderungswert, den ein Kunde jederzeit innerhalb dieses Bereichs halten darf.
  • Ausdruck: Die laufende Summe der offenen Posten, offenen Aufträge, offenen Lieferungen und offenen Rechnungsbelege.
  • Reaktion: Ob eine Bestellung, die das Limit überschreitet, verwarnt, blockiert oder zugelassen wird.

Die Stammdaten des Kreditkontrollbereichs werden pro Kunde gepflegt, und die folgende Schritt-für-Schritt-Anleitung zeigt, wie das funktioniert.

Wie man Kundenkreditlimits in FD32 verwaltet (Schritt für Schritt)

Schritt 1) Geben Sie den Transaktionscode FD32 in das Feld ein. SAP Befehlsfeld.

Das Befehlsfeld befindet sich oben links auf dem SAP GUI Bildschirm, wie unten dargestellt.

SAP Befehlsfeld mit Transaktionscode FD32 eingegeben

Schritt 2) Geben Sie im nächsten Bildschirm Folgendes ein.

  1. Geben Sie die Kunden-ID des Kunden ein, dessen Kreditlimits beibehalten werden sollen.
  2. Betreten Sie den Bereich Kreditkontrolle.
  3. Aktivieren Sie im Datenauswahlblock das Kontrollkästchen „Zentrale Daten“.

Der Eingangsbildschirm, auf dem alle drei Einträge vorgenommen wurden, sieht aus wie im folgenden Screenshot.

FD32-Startbildschirm mit ausgewählten Kunden-, Kreditkontroll- und Zentraldaten.

Schritt 3) Im nächsten Bildschirm pflegen Sie die Kreditverwaltungsdaten für den Kunden.

Auf dem zentralen Datenbildschirm werden der Gesamtbetrag und das individuelle Limit angezeigt, wie der Screenshot zeigt.

FD32-Zentralbildschirm mit Anzeige des Gesamtbetrags und der einzelnen Limitfelder

Schritt 4) Drücken Sie die Schaltfläche „Speichern“ auf dem SAP Standard-Symbolleiste zum Speichern der an den Kreditlimits vorgenommenen Änderungen.

Die Schaltfläche „Speichern“ ist das Diskettensymbol links in der Symbolleiste, das unten hervorgehoben ist.

Schaltfläche „Speichern“ auf dem SAP Standard-Symbolleiste

Eine Meldung in der Statusleiste bestätigt die vorgenommenen Änderungen. Das neue Limit gilt ab der nächsten Bonitätsprüfung; bereits gesperrte Bestellungen müssen daher separat freigegeben werden.

Konfiguration des Kreditkontrollbereichs und zugehörige SAP T-Codes

FD32 verwaltet ausschließlich Stammdaten. Der Kreditkontrollbereich selbst sowie die darauf basierenden Prüfungen werden im Customizing konfiguriert. Daher deutet ein Limit, das scheinbar keine Auswirkung hat, in der Regel eher auf eine Konfigurationslücke als auf einen Stammdatenfehler hin.

T-Code Zweck
OB45 Definieren Sie den Kreditkontrollbereich, seine Währung und seine Aktualisierungsgruppe.
OB38 Weisen Sie einem Kreditkontrollbereich einen Firmencode zu.
OVFL Ordnen Sie einem Kreditkontrollbereich einen Vertriebsbereich zu.
OB01 Definieren Sie die im Kreditkontrollbereich verfügbaren Risikokategorien.
OVA8 Konfigurieren Sie die automatische Kreditkontrolle für einen Kreditkontrollbereich, eine Risikokategorie und eine Kreditgruppe.
FD32 / FD33 Kundenkreditstammdaten ändern und anzeigen
F.31 / F.35 Kreditübersicht und Kreditstammdatenberichterstattung
VKM1 / VKM4 Verkaufsbelege, die aufgrund der Bonitätsprüfung gesperrt sind, auflisten und freigeben.

Bevor FD32 geöffnet wird, sollten zwei Voraussetzungen geprüft werden: Der Kunde muss bereits im Buchungskreis vorhanden sein, und der Buchungskreis muss dem eingegebenen Kreditkontrollbereich zugeordnet sein. Falls der angezeigte Betrag anstelle des Limits falsch erscheint, ist die SD-Seite der Konfiguration in der Dokumentation beschrieben. SAP SD-Kreditmanagement -Guide.

Wichtige Felder auf den FD32-Kreditmanagement-Bildschirmen

FD32 ist eine Transaktion mit mehreren Bildschirmen. Der Datenauswahlblock auf dem Eingabebildschirm bestimmt, welche Bildschirme geöffnet werden. Die wichtigsten Felder sind unten aufgeführt.

Bildschirm Feld Bedeutung
Zentrale Daten Gesamtmenge Gesamtkredit, den der Kunde in allen Kreditkontrollbereichen erhalten kann.
Zentrale Daten Individuelle Beschränkung Maximaler Kreditbetrag, den ein Kunde innerhalb eines einzelnen Kreditkontrollbereichs erhalten kann.
Zentrale Daten Währung Währung, in der die zentralen Grenzwerte gehalten werden
Status Kreditlimit Das im Kreditkontrollbereich gewährte Limit wurde auf dem ersten Bildschirm eingegeben.
Status Risikokategorie Schlüssel, der entscheidet, welche automatische Bonitätsprüfung von OVA8 angewendet wird
Status Kreditvertretergruppe Gruppe von Mitarbeitern, die für die Überwachung des Kontos zuständig sind
Status Letzte und nächste interne Überprüfung Daten, an denen die Grenze zuletzt überprüft wurde und an denen die nächste Überprüfung ansteht
Zahlungshistorie Zahlungsdaten Beglichene Posten, durchschnittliche Zahlungsrückstände und der höchste ausstehende Betrag

Der Gesamtbetrag und das individuelle Limit wirken zusammen: Das individuelle Limit begrenzt den Betrag eines einzelnen Bereichs, während der Gesamtbetrag die Summe aller Bereiche begrenzt. Ein individuelles Limit, das über dem Gesamtbetrag liegt, ist zwar zulässig, hat aber keine praktische Auswirkung. RevDie Datumsangaben fließen in die Arbeitsliste für die Kreditprüfung ein. Wenn man diese Felder leer lässt, wird das Konto automatisch aus dieser Liste entfernt.

Kreditmanagement in SAP S/4HANA: Was ersetzt FD32?

Klassisches SD-Kreditmanagement ist nicht verfügbar in SAP S/4HANA. Es wird ersetzt durch SAP Das Kreditmanagement ist Teil des Finanzlieferkettenmanagements, und die Transaktionscodes ändern sich entsprechend.

  • Stammdaten: Die Kreditdaten werden dem Geschäftspartner in der Rolle UKM000 zugewiesen und mit der Transaktion BP oder UKM_BP anstelle von FD32 verwaltet.
  • Segmente: Der Kreditkontrollbereich wird durch ein Kreditsegment ersetzt, und die Limits werden pro Segment anstatt pro Bereich festgelegt.
  • Gesperrte Dokumente: Die dokumentierten Kreditentscheidungen in UKM_MY_DCDS ersetzen die klassischen Freigabelisten.
  • Tabellen: Die klassischen Kreditstammdatentabellen KNKA und KNKK werden durch die Tabellen UKMBP_CMS ersetzt, und auch die Expositionsstrukturen S066 und S067 werden ausgetauscht.
  • Conversion: Die bestehenden Kreditstammdaten werden bei einer Systemumstellung migriert, sodass die Limits nicht erneut eingegeben werden müssen.

Gibt es hier noch jemanden, der rennt? SAP Die ERP-Zentralkomponente behält FD32 exakt wie oben beschrieben bei, und die Konzepte lassen sich nahtlos übertragen: Auf beiden Seiten existieren ein Limit, eine Risikokategorie und eine Expositionskennzahl. Eine detaillierte Beschreibung der Rolle des Geschäftspartners ist in diesem Dokument veröffentlicht. SAP Community-Artikel über SAP KreditmanagementIm weiteren Verlauf treiben dieselben Kundenkonten die Kundenkonten an. Mahnwesen und die in Zurücksetzen der gelöschten Elemente.

Häufig gestellte Fragen

Die automatische Bonitätsprüfung reagiert je nach Einstellung der Risikokategorie mit einer Warnung, einem Fehler oder einer Liefersperre. Gesperrte Verkaufsbelege verbleiben in einer Freigabeliste, bis ein Kreditsachbearbeiter sie genehmigt oder ablehnt.

Eine statische Prüfung vergleicht das Limit mit der Summe offener Posten, Aufträge, Lieferungen und Rechnungsbelege. Eine dynamische Prüfung fügt einen Kredithorizont hinzu, sodass Aufträge, die außerhalb dieses Horizonts geplant sind, ignoriert werden. Beide Prüfungen werden pro Risikokategorie konfiguriert.

Die Risikopositionen werden in zusammenfassenden Strukturen gehalten, die nach einem Aktualisierungsfehler abweichen können. Der Reorganisationsbericht RVKRED77 stellt die Kreditwerte für die betroffenen Kunden und Kreditkontrollbereiche wieder her, sodass die Zahlen anschließend wieder mit den offenen Posten übereinstimmen.

Klassische Kreditdaten werden in eigenen Tabellen gespeichert und nicht in den allgemeinen Kundenstammdaten: KNKA enthält die zentralen Daten, KNKK einen Datensatz pro Kreditkontrollbereich. Daher erfolgt die Datenpflege über FD32 und nicht über die Kundenanlagemasken.

Maschinelle Lernmodelle bewerten Zahlungsverhalten, Zahlungsrückstände und externe Bonitätseinstufungen, um ein Limit oder eine Risikokategorie vorzuschlagen, und ordnen Inkassofälle nach Zahlungswahrscheinlichkeit. Der Vorschlag muss jedoch noch von einem Mitarbeiter genehmigt werden, bevor er an die Kreditabteilung weitergeleitet wird.

Ja. Assistenten wie zum Beispiel GitHub-Copilot Entwerfen Sie den ABAP-, Batch-Input- oder Skriptcode für die Massenkreditlimitberechnung und die Abfragen für einen Expositionsbericht. Testen Sie jedes generierte Programm zunächst in einem Sandbox-Client.

Das Limit wird in der Währung des Kreditkontrollbereichs geführt, die bei dessen Definition festgelegt wird. Belege, die in anderen Währungen gebucht werden, werden vor dem Vergleich des Risikos mit dem Limit in die jeweilige Währung umgerechnet.

Jede Änderung im Kreditstamm wird protokolliert, und die Änderungsbelege können für einen Kunden und einen Kreditkontrollbereich aufgelistet werden. Das Protokoll enthält den alten Wert, den neuen Wert, den Benutzer und das Datum – genau die Informationen, die bei einer Prüfung von Kreditentscheidungen üblicherweise benötigt werden.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: