Ansicht
Dokumentation

RFLQ_ASSIGN_FI - Liquiditätsrechnung: Zuord. Liquiditätsposition auf Basis FI-Belege

PERFORM Short Reference   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Titel

Verwendung

Dieses Programm läuft über Ist-Belege in der Liquiditätsrechnung, die zu FI-Belegen gehören (also alle bis auf die manuellen Umbuchungen).Es versucht, aus Information in der Buchhaltung die Liquiditätsposition des Belegs abzuleiten.

Integration

Den Bereich der zu bearbeitenden Ist-Belege legen Sie auf dem Selektionsbild fest.

Funktionsumfang

Die Logik zur Ableitung der Liquiditätsposition (mit Abfragefolge und User-Exit) ist analog der des Programms, das die Information in den Kontoauszügen auswertet. Hier kommt aber noch ein erster Schritt dazu, nämlich die Suche nach den FI-Belegzeilen, die ausgewertet werden sollen:

Eine Ist-Zeile in der Liquiditätsrechnung referenziert ja eindeutig auf eine Ist-Zeile (d.h. das Hauptbuchkonto der Zeile ist ein Bankkonto oder anderes Ist-Konto) in der Buchhaltung. Im Allgemeinen enthält diese Belegzeile aber wenig Information, die das Auswerten lohnt.

Daher liest der Mechanismus den kompletten Beleg ein, typischerweise also:

Zeile: Bankkonto (Ist)
Zeile: Bankverrechnungskonto

Die Zeile auf dem Bankverrechnungskonto enthält meist ebenfalls keine verwertbare Information. Falls diese Zeile in der Buchhaltung bereits ausgeglichen wurde, so geht die Suche deshalb weiter: Es wird im FI nachgelesen, welche anderen Belege noch am Ausgleich beteiligt waren. Diese werden eingelesen. Im einfachsten Fall bekommt man also noch einen Zahlungsbeleg dazu:

Zeile: Bankverrechnungskonto
Zeile: Kreditor (Info)

Die Zeile, in der Information zur Liquiditätsposition gesucht wird, ist hier die Kreditor-Zeile! Der Mechanismus endet auch an dieser Zeile; es ist unerheblich, ob sie ausgeglichen oder noch offen ist.

Allgemein entscheidet die Kontoart und ggf. das Sachkonto, ob eine Zeile wie in diesem Beispiel ein 'Endpunkt' ist, in dem das Programm nach Information zur Ableitung einer Liquiditätsposition sucht. Diese 'Informations-Zeilen' sind:

• Alle Debitor und Kreditor-Zeilen.

• Alle weiteren Zeilen, deren Hauptbuchkonto im Customizing als 'Informationsträger' deklariert wurde. (naheliegende Kandidaten sind z.B. die Abstimmkonten für Treasury-Geschäfte, für Lohn- und Gehaltszahlungen,...).
  

Mit dieser Methode wird man zu einer Ist-Zeile i.a. mehrere solche potentielle 'Informations-Zeilen' finden. Jede einzelne davon wird wie folgt ausgewertet: Die Zeile (Feldwerte der Strukturen BKPF, BSEG und ggf. KNA1, LFA1) wird gegen die erste Abfrage der im Report hinterlegten Folge geprüft. Wenn alle Bedingungen dieser Abfrage zutreffen, so wird die hinterlegte Liquiditätsposition gemerkt. Wenn nicht, so wird gegen die nächste Abfrage geprüft, etc. Außerdem hat man auch wieder die Möglichkeit, in einer User-Exit Funktion (Schnittstelle gemäß 'FLQ_SAMPLE_ASSIGN_FI') eine eigene Ableitungslogik zu programmieren. Diese ist ggf. 'stärker' als die Ableitung aus den Abfragen.

Die aus den 'erfolgreichen' Informations-Zeilen abgeleiteten Liquiditätspositionen werden mit Beträgen gesammelt. Der Gesamtbetrag wird mit dem Betrag der Ist-Zeile verglichen.

Falls die Ist-Zeile nicht abgedeckt ist (d.h. der Info-Gesamtbetrag ist kleiner als der Ist-Betrag), so kann ihr der Mechanismus keine neue Liquiditätsposition zuweisen und sie wird nicht geändert.

Falls die Ist-Zeile abgedeckt ist, so bekommt sie die neuen Liquiditätspositionen zugeordnet; die Aufteilung des Betrags ist proportional zu der Aufteilung der Info-Beträge.

Im Detailprotokoll wird jeweils die neue Liquiditätsposition und die Abfrage, die dafür verantwortlich war, angezeigt. Falls ein Ist-Beleg nicht umgesetzt werden konnte, so wird im Protokoll ein Fehlercode ausgegeben.

Ein Fehler, der auftreten kann, ist prinzipieller Natur und soll deshalb hier separat diskutiert werden: Nämlich, wenn der Mechanismus wie oben beschrieben mit einer Ist-Zeile startet und dann das durch Ausgleich verbundene Beleg-Cluster zusammenliest, so kann es auch vorkommen, daß weitere Ist-Belege dabei sind. Im Cluster hat man dann insgesamt N Ist-Zeilen und M Info-Zeilen. Bei dieser Konstellation ist die sinnvolle Zuordnung von Information zur aktuellen Ist-Zeile nur in Ausnahmefällen möglich, daher weist das Programm hier oft einen Fehler aus. (N:M Beziehung)

Der 'wichtigeste' Ausgleich in diesem Kontext ist typischerweise der auf den Bank-Verrechnungskonten. Deshalb der Rat: Achten Sie darauf, daß auf den Bank-Verrechnungskonten strikt vorgangsbezogen immer nur wenige Belege miteinander ausgeglichen werden (normalerweise erreicht man dies durch den Einsatz des Programms SAPF124 für automatischen Ausgleich). Erlauben Sie keine 'Keulenschläge' mit mehreren hundert Belegen.

Aktivitäten

Bei ungenügendem Zuordnungsergebnis sollten Sie erst einmal mit Hilfe des Programms RFLQ_ITCHAIN die gefundenen Informations- und anderen Zeilen zu einer Ist-Zeile anzeigen. Danach können Sie daran gehen, die auf diese Zeilen wirkende Abfragefolge und ggf. den User-Exit zu überarbeiten.

Beispiel

Angenommen, wir haben es mit der einfachen Belegkette wie oben zu tun:

Zeile: Bankkonto (Ist) Betrag 100-
Zeile: Bankverrechnungskonto

mit Ausgleich von zwei Belegen auf dem Bankverrechnungskonto:

Zeile: Bankverrechnungskonto Betrag 60-
Zeile: Kreditor extern

Zeile: Bankverrechnungskonto Betrag 40-
Zeile: Kreditor intern

Falls Sie bereits das Bank- oder das Bankverrechnungskonto als Informationsträger deklariert haben, so sieht der Mechanismus nur den ersten Beleg und wertet die entsprechende Zeile aus. Das ist aber vermutlich eher die Ausnahme.

Andernfalls geht der Mechanismus in die beiden anderen Belege und nimmt eine Auswertung der beiden Zeilen vor:

Zeile: Kreditor extern Betrag 60

Zeile: Kreditor intern Betrag 40

Hier gibt es dann folgende Möglichkeiten: Falls aus keiner oder nur einer dieser Zeilen eine Liquiditätsposition abgeleitet werden kann, so wird die Ist-Zeile nicht umgesetzt. Der Grund ist die fehlende 'Deckung' des Ist-Betrags.

Falls auf beiden Zeilen dieselbe Position abgeleitet wird, so wird die Ist-Zeile komplett darauf aufgewiesen. Bei unterschiedlichen Positionen wird im Verhältnis 60/40 aufgespalten.

rdisp/max_wprun_time - Maximum work process run time   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7109 Date: 20240520 Time: 131336     sap01-206 ( 144 ms )