Die Offene-Posten-Verwaltung (OP-Verwaltung) gehört zu den zentralsten Features im SAP Financials (FI). Bei Sachkonten, wie etwa Verrechnungskonten oder Bank-Unterkonten, erlaubt die OP-Verwaltung ein direktes “Ausgleichen” von zusammengehörigen Buchungen (z.B. Rechnung und Zahlung).

Mit der Einführung von SAP S/4HANA und dem Universal Journal (Tabelle ACDOCA) haben sich Datenmodellierung und der technische Umgang mit diesen Posten jedoch drastisch gewandelt. In diesem Beitrag gehe ich darauf ein, wie du auf Tabellen-Ebene mit OPs umgehst und welche Fallstricke existieren.

Das Datenmodell in ACDOCA

In klassischen ERP-Systemen waren offene und ausgeglichene Posten der Debitoren/Kreditoren physisch auf Tabellen wie BSIK/BSAK oder Sachkonten-OPs auf BSIS/BSAS aufgeteilt. In S/4HANA fliessen alle Einzelposten zentral in die Tabelle ACDOCA.

Die alten BS*-Tabellen existieren noch, fungieren nun aber als Core Data Services (CDS) / DDL SQL-Views (Stichwort: Compatibility Views), welche die Daten on-the-fly aus ACDOCA und BKPF projizieren, damit alter ABAP-Code weiterhin läuft.

Um auf Datenbankebene offene von ausgeglichenen Posten direkt in ACDOCA zu trennen, fokussieren wir uns auf folgende zwei Schlüsselfelder:

  • AUGDT (Ausgleichsdatum)
  • AUGBL (Ausgleichsbelegnummer)

Ein simpler Open-Item SQL Select:

SELECT rbukrs, racct, belnr, drcrk, hsl
  FROM acdoca
  WHERE rclnt = @sy-mandt
    AND rbukrs = '1000'
    AND racct  = '0000113100' " Bank-Verrechnungskonto
    AND augdt  IS INITIAL     " Leer = Noch völlig offen!
  INTO TABLE @DATA(lt_open_items).

Das Konzept in S/4HANA baut voll auf In-Memory-Performance. Du musst in CDS-Views oder ABAP-SQL keine aggregierten Salden mehr aus alten Summentabellen (GLT0, FAGLFLEXT) berechnen; Du liest einfach die ACDOCA mit der Restriktion auf AUGDT IS INITIAL on-the-fly zusammen.

Das Problem der nachträglichen OP-Aktivierung

Ein klassisches Szenario in fast jedem Corporate IT SAP-Migrationsprojekt: Ein Konto wurde versehentlich ohne OP-Verwaltung angelegt und bereits bebucht. Im Nachhinein stellt die Buchhaltung fest: “Wir müssen hier OPs ausgleichen!”

Früher benötigte dies langwierige Saldenumschichtungen oder Custom-Reports. Unter S/4HANA nutzen wir den offiziellen Schalter. Die wichtigste Transaktion hierfür lautet: Transaktion: FAGL_ACTIVATE_OP (bzw. Programm FAGL_ACTIVATE_OP)

Voraussetzungen für den reibungslosen Ablauf:

  1. Der Saldo des Kontos darf nicht null sein (oder muss explizit auf null sein, falls Fehler auftauchen – je nach Ledger-Ansatz).
  2. Das Konto ist in den Stammdaten für das Buchungskreissegment (Reiter Steuerungsdaten) entsperrt.
  3. Du führst das Programm zunächst im Testlauf aus.

Der Report verändert im Hintergrund den Stammdatensatz (Tabelle SKB1, XOPVW = 'X') und stempelt die bestehenden Posten in der ACDOCA so um, dass sie nun den Status “offen” haben. Zuvor eingebuchte Beträge erscheinen danach als ein oder mehrere OP-Blöcke und das Datum des OP-Startes wird dokumentiert.

Automatisierter Ausgleich im System

Wenn du OP-geführte Konten im S/4HANA System optimal automatisieren möchtest, nutzt du in Fiori die App “Sachkonten maschinell ausgleichen” (früher F.13).

Technisch gesehen wendet die Maschinerie hierbei die Regeln aus dem Customizing (OB74) an. Die Felder (wie ZUONR / Zuordnungsnummer oder Referenz XBLNR), die du dort hinterlegst, dienen dem Algorithmus als Matching-Pattern. Sind Beträge und Matching-Kriterien der Debit- und Kreditbuchung identisch, generiert das Programm sofort einen reinen Ausgleichsbeleg (AUGBL wird befüllt) - ganz ohne manuelle Dialogeingaben in der FB05.

Fazit

OP-geführte Konten sorgen für Disziplin bei Verrechnungs-, Steuer- und Lohnkonten. In S/4HANA hat uns SAP durch die Konsolidierung in die ACDOCA und hoch optimierte Fiori-Apps extrem starke Tools in die Hand gegeben. Wer ABAP oder CDS Views für das Reporting aufbaut, sollte sich der neuen Datenstrukturen via AUGDT aber in jedem Fall bewusst sein!