SAP-TabelleObjektACDOCAModulFI_FICO

Tabelle ACDOCA — Einzelposten des Universal Journals

ACDOCA ist die S/4HANA-Tabelle des Universal Journals, die eine Zeile pro Buchhaltungsposten pro Ledger enthält und das zusammenführt, was früher auf BSEG, den Summensalden der neuen Hauptbuchhaltung, CO-Einzelposten und Material-Ledger-Daten verteilt war. Sie enthält FI-, CO- und Profit-Center-Attribute in derselben Zeile, auf der Granularitätsebene von Ledger, Buchungskreis, Geschäftsjahr, Beleg und Belegposition.

Diese Seite behandelt, was eine Zeile in ACDOCA tatsächlich darstellt, die abfragebaren Felder, die Joins, die Berater verwenden, um von einer Journalzeile zu Stammdaten und Quelldokumenten zu gelangen, und die spezifischen Fehlinterpretationen, die zu falschen Summen führen, wenn man sie wie BSEG mit zusätzlichen Spalten behandelt. Es wird auch erklärt, wo die Tabelle im Verhältnis zu den klassischen FI/CO-Tabellen steht, die sie absorbiert hat.

Veröffentlicht am 15. Sept. 2026· 1.162 Wörter

Was sie speichert

Eine Zeile in ACDOCA ist ein einzelner Buchhaltungsposten, der in einem bestimmten Ledger gebucht wurde. Da S/4HANA FI, CO (einschließlich Kostenstellen- und Innenauftragsbuchungen), Profit-Center-Rechnung und Material-Ledger-Bewertung in einer physischen Tabelle speichert, kann derselbe zugrunde liegende Geschäftsvorfall mehrere ACDOCA-Zeilen erzeugen: eine pro parallelem Ledger, für das er relevant ist, und zusätzliche Zeilen, die durch die Belegaufteilung entstehen, wenn ein Beleg nach Profit Center oder Segment ausgeglichen werden muss. Eine Zeile ist daher nicht immer dasselbe wie ein BSEG-Einzelposten; sie ist die ledgerspezifische, aufteilungs-konforme Darstellung dieser Zeile. Echtzeit-CO-Buchungen (z. B. Kostenstellenumbuchungen von Kostenstelle zu Kostenstelle), die das klassische FI nie berühren, landen ebenfalls hier als eigene Zeilen, gekennzeichnet durch das Referenzvorgangsfeld.

Schlüsselfelder

Die Felder, die Berater tatsächlich für Selektionen und Joins verwenden:

RCLNT - Mandant
RLDNR - Ledger, unterscheidet führendes Ledger von parallelen Ledgern, muss vor jeder Aggregation eingeschränkt werden
RBUKRS - Buchungskreis
GJAHR - Geschäftsjahr
BELNR - Buchhaltungsbelegnummer
DOCLN - Universal-Journal-Zeilennummer; dies ist nicht dasselbe Nummerierungsschema wie BSEG-BUZEI
RACCT - Sachkontonummer
KOKRS - Kostenrechnungskreis
KOSTL - Kostenstelle
PRCTR - Profit Center
SEGMENT - Segment, das für die Segmentberichterstattung verwendet wird
WERKS - Werk
KUNNR - Kundennummer, wenn die Zeile kundenbezogen ist
LIFNR - Lieferantennummer, wenn die Zeile lieferantenbezogen ist
MATNR - Materialnummer auf materialbezogenen Zeilen
BUDAT - Buchungsdatum
BLDAT - Belegdatum
DRCRK - Soll-/Haben-Kennzeichen
HSL - Betrag in Buchungskreis- (Haus-)währung
KSL - Betrag im Währungstyp, der für Konzern- oder Kostenrechnungskreisberichterstattung verwendet wird
TSL - Betrag in Transaktions- (Beleg-)währung
AWTYP - Referenzvorgang, der die Zeile erzeugt hat, gibt an, ob sie als FI-Beleg, CO-Beleg oder aus einer anderen Quelle stammt
AWKEY - Referenzschlüssel, der auf das ursprüngliche Quellobjekt zurückverweist

Wie sie das Datenmodell verknüpft

Joins, die Berater täglich schreiben:

ACDOCA-RBUKRS = BKPF-BUKRS und ACDOCA-BELNR = BKPF-BELNR und ACDOCA-GJAHR = BKPF-GJAHR, um Kopfdaten wie Stornostatus und Benutzer zu erhalten; beachten Sie, dass BKPF keine Ledger-Dimension hat
ACDOCA-RACCT = SKA1-SAKNR, eingeschränkt durch den dem Buchungskreis zugeordneten Kontenplan, um die Klassifizierung des Kontos zu erhalten
ACDOCA-RACCT = SKB1-SAKNR und ACDOCA-RBUKRS = SKB1-BUKRS, für buchungskreisspezifische Kontensteuerung wie die Offene-Posten-Verwaltung
ACDOCA-KOSTL = CSKS-KOSTL und ACDOCA-KOKRS = CSKS-KOKRS, für Kostenstellen-Stammdaten unter Beachtung des Gültigkeitszeitraums in CSKS
ACDOCA-RBUKRS = T001-BUKRS, für Buchungskreiswährung und Kontenplanzuordnung

Wie man sie sicher liest

ACDOCA ist mandantenabhängig und in einer produktiven Landschaft eine der größten Tabellen im System. Selektieren Sie niemals ohne mindestens die Einschränkung auf Buchungskreis und Geschäftsjahr; fügen Sie Ledger (RLDNR) hinzu, wann immer die Abfrage eine bestimmte Sicht auf die Buchhaltung darstellen soll, da sonst das führende Ledger und die parallelen Ledger zusammengezählt werden und Summen stillschweigend überhöht werden. Für alles, was über die Suche nach einem einzelnen Beleg hinausgeht, sollte ein Buchungsdatums- oder Geschäftsperiodenbereich hinzugefügt werden. Der Referenzvorgang und der Referenzschlüssel sind der schnellste Weg, um von einem Geschäftsbeleg (Kundenauftrag, Bestellung, Anlage) direkt zu dessen Finanzbuchungen zu springen, ohne zuerst BKPF durchlaufen zu müssen.

Wie man es in den Daten beweist

Symptom: Ein Kostenstellenbericht zeigt einen Betrag, der nicht mit dem übereinstimmt, was FI für dasselbe Konto und dieselbe Periode anzeigt. Selektieren Sie ACDOCA nach KOKRS, KOSTL, RACCT, GJAHR und der relevanten Buchungsperiode, gruppieren Sie dann nach RLDNR. Wenn die beiden Ledger unterschiedliche Summen anzeigen, ist die Diskrepanz eine Bewertungsdifferenz der parallelen Ledger und kein Datenfehler; wenn die Summe eines einzelnen Ledgers vom FI-Bericht abweicht, prüfen Sie, ob der FI-Bericht AWTYP filtert, um reine CO-Buchungen auszuschließen, die ebenfalls die Kostenstelle tragen.

ECC vs. S/4HANA

ACDOCA existiert nur in S/4HANA; es gibt kein Äquivalent in ECC. In ECC waren dieselben Informationen auf BSEG, die Summensalden der neuen Hauptbuchhaltung (FAGLFLEXA und FAGLFLEXT), CO-Einzelposten (COEP) und Material-Ledger-Tabellen verteilt. S/4HANA fasst all dies in ACDOCA als einziger Quelle für Buchungen zusammen, und die klassischen Tabellen werden als Kompatibilitätsstrukturen beibehalten, damit bestehende Berichte und Schnittstellen weiterhin funktionieren, aber die maßgeblichen Daten für die Finanz- und Ergebnisberichterstattung leben in ACDOCA.

Häufige Fallstricke

Die wiederkehrenden falschen Schlussfolgerungen aus dieser Tabelle:

Annahme, dass ACDOCA ein Eins-zu-Eins-Ersatz für BSEG ist. Das ist es nicht: Eine BSEG-äquivalente Geschäftstransaktion kann mehrere ACDOCA-Zeilen durch Ledgermultiplikation und Belegaufteilung erzeugen, sodass Zeilenzählungen und sogar Beträge auf Zeilenebene nicht mit einem naiven BSEG-Vergleich übereinstimmen werden.
Summieren von Betragsfeldern über alle Zeilen hinweg, ohne RLDNR zu filtern. Dies zählt dasselbe wirtschaftliche Ereignis pro parallelem Ledger doppelt oder dreifach und erzeugt Salden, die falsch aussehen, aber tatsächlich die Summe der führenden plus nicht-führenden Ledgersichten sind.
Verknüpfen von ACDOCA-DOCLN mit BSEG-BUZEI in der Erwartung einer Eins-zu-Eins-Übereinstimmung. Die beiden sind unterschiedliche Nummerierungsschemata; der Join liefert irreführende Teiltreffer statt eines offensichtlichen Fehlers, was schlimmer ist als ein harter Fehlschlag.
Lesen von HSL oder KSL ohne zu prüfen, welchen Währungstyp jedes Feld in der gegebenen Mandantenkonfiguration darstellt. Die Zuordnung von Währungsfeldern zu Währungstypen ist konfigurierbar und nicht fest, sodass ein Betragsfeld, das in einem System Konzernwährung bedeutet, in einem anderen anders konfiguriert sein kann.
Jede Zeile als FI-Belegposition behandeln. Reine CO-Buchungen in Echtzeit (Kostenstellenumbuchungen, Innenauftragsabrechnung) erscheinen in ACDOCA mit einem anderen Referenzvorgang und waren im klassischen BSEG überhaupt nie vorhanden; das Ausschließen oder Einschließen ändert die Summen, je nachdem, was die Abstimmung beweisen soll.
Ignorieren von Saldenvortrag und technischen Jahresabschlussbuchungen bei der Zählung des Transaktionsvolumens für eine Periode, was die Aktivität überbewertet, wenn diese Zeilen nicht herausgefiltert werden.

Wessen Problem das ist

Eine Diskrepanz zwischen ACDOCA und einem nachfolgenden Bericht ist eine gemeinsame FI- und CO-Designfrage, die normalerweise von demjenigen verantwortet wird, der die Belegaufteilung und das Ledger-Setup konfiguriert hat, da die meisten Diskrepanzen auf Aufteilungsregeln oder die Ledger-Zuordnung eines Buchungskreises zurückzuführen sind. Reine Performance-Probleme bei großen Selektionen gegen ACDOCA gehören zu Basis und dem HANA/DB-Team.