SAP S/4HANA Buchungstag, Dokumentendatum und Diagnose von Buchungszeitraum-Ablehnungen
Eine Ablehnung beim Buchungsvorgang ist in der Regel ein Problem des Periodenabgleichs und kein Fehler bei der Datumsangabe. Das Dokumentendatum ist das Ausstellungsdatum des Originaldokuments, während das Buchungstag den Buchungszeitraum bestimmt, den das System prüft. Die Buchungszeitraum-Variante und nicht die Finanzjahresvariante öffnet und schließt Perioden für die Kopfzeile und für jeden Kontotyp.
Auf dieser Seite
Die kurze Antwort
Eine Ablehnung beim Buchungsvorgang ist in der Regel ein Problem des Periodenabgleichs und kein Fehler bei der Datumsangabe. Das Buchungstag ist das Ausstellungsdatum des Originaldokuments, während das Buchungstag-Feld bestimmt, welcher Buchungszeitraum vom System geprüft wird. Die Buchungszeitraum-Variante und nicht die Finanzjahresvariante entscheidet, ob dieser Zeitraum für die Dokumentenkopfzeile und für jeden Kontotyp in den Positionen geöffnet ist. Eine Buchung kann fehlschlagen, auch wenn das Buchungstag im richtigen Kalendermonat liegt, wenn der betreffende Zeitraum geschlossen ist, ein bestimmter Kontotyp geschlossen ist oder der Benutzer keine Berechtigung für ein Anpassungsintervall besitzt. Finanzjahresvarianten definieren lediglich, wie viele Perioden existieren und wo sie beginnen und enden; sie öffnen oder schließen keine Perioden. Bei der Diagnose ohne Konfigurationsänderungen sollte die Ablehnungsmeldung gelesen, festgestellt werden, ob die Kopfzeile oder ein Kontotyp in den Positionen fehlgeschlagen ist, und entschieden werden, ob das Buchungstag, das Dokumentendatum oder die Kontozuordnung das eigentliche Problem ist. Man sollte nicht davon ausgehen, dass ein geschlossener Zeitraum wieder geöffnet werden muss. Stattdessen sollte der beabsichtigte Zeitraum, die Variantenzuordnung und die Berechtigung des Benutzers überprüft werden, und dann eine legitime Maßnahme gewählt werden, wie etwa die Korrektur des Datums, die Verwendung eines anderen Kontotyps oder die Eskalation an die Person, die die Perioden verwaltet.
Unterscheiden Sie die beiden Daten
Die Dokumentenkopfzeile enthält sowohl ein Buchungstag als auch ein Dokumentendatum, und sie sind nicht austauschbar. Das Dokumentendatum ist das Ausstellungsdatum des Originaldokuments. Das Buchungstag ist typischerweise das Datum, das bei der Eingabe in der Finanzbuchhaltung verwendet wird, und es ist das Feld, das die Buchungszeitraum-Prüfung steuert. Der Buchungszeitraum selbst wird aus dem Buchungstag abgeleitet, und dieser Zeitraum ist derjenige, den die Berichterstellung verwendet, um die Dokumentenwerte im richtigen Berichtszeitraum zu platzieren. Mit anderen Worten: Das Dokumentendatum sagt Ihnen, wann das Geschäftsdokument erstellt wurde, während das Buchungstag dem System mitteilt, wo die Buchung für den Periodenabgleich und die Berichterstellung eingereiht werden soll.
Diese Unterscheidung ist wichtig, weil ein Benutzer ein Dokumentendatum eingeben kann, das plausibel erscheint, und dennoch abgelehnt werden, wenn das Buchungstag in einem geschlossenen Zeitraum liegt. Die Periodenprüfung des Systems ist an das Buchungstag gebunden, nicht nur an das Dokumentendatum. Wenn die beiden Daten unterschiedlich sind, sollten Sie nicht davon ausgehen, dass das Dokumentendatum der steuernde Wert ist. Behandeln Sie das Buchungstag als den primären Wert für die Periodenakzeptanz und das Dokumentendatum als die Ausstellungsreferenz des Dokuments.
Für eine konkrete Veranschaulichung stellen Sie sich eine Rechnung vor, die am 28. September datiert ist und ein Buchungstag vom 30. September hat. In einer kalendarbasierten Finanzjahresvariante fallen beide Daten in September, sodass das Dokumentendatum und das Buchungstag auf denselben Monat verweisen. Dennoch garantiert diese Übereinstimmung keine Akzeptanz, weil die Akzeptanz davon abhängt, ob der September-Buchungszeitraum für die betreffenden Kontotypen geöffnet ist. Das Beispiel ist hypothetisch und dient nur dazu, die Bedeutung der beiden Daten von der separaten Frage zu trennen, ob der Zeitraum geöffnet ist.
Beziehen Sie das Buchungstag auf den Finanzkalender
Das Buchungstag wird über die dem Geschäftsbereich zugewiesene Finanzjahresvariante auf eine Finanzperiode abgebildet. Diese Variante definiert, wie viele Perioden existieren und wo jede Periode beginnt und endet. Sie entscheidet nicht an sich, ob ein Zeitraum geöffnet oder geschlossen ist. Diese Trennung ist wichtig: Die Kalenderlogik sagt dem System, zu welcher Finanzperiode ein Datum gehört, aber die Entscheidung über geöffnet/geschlossen wird anderswo getroffen.
In einem einfachen kalendarbasierten Finanzjahr wird ein Buchungstag vom 30. September auf September abgebildet. In einem nicht-kalendarbasierten Finanzjahr kann dasselbe Kalendertag in einer anderen Finanzperiode liegen oder eine Finanzperiode kann Teile von zwei Kalendermonaten umfassen. Deshalb kann eine naive Regel wie 'September entspricht Periode 9' in einem bestimmten System falsch sein. Die Finanzjahresvariante ist der Grund, warum die Abbildung existiert, aber sie ist nicht die Steuerung, die die Buchung akzeptiert oder ablehnt.
Da die Finanzjahresvariante nur die Periodenstruktur definiert, sollten Sie sie verwenden, um die Datum-zu-Periode-Abbildung zu interpretieren, nicht um zu schließen, dass ein Zeitraum geöffnet sein muss. Wenn die Abbildung selbst unklar ist, kann das Problem die Periodengrenzen der Variante und nicht die Eingabe des Buchungstags sein. Im September-Beispiel ist die Kalenderabbildung nur deshalb geradlinig, weil die angenommene Variante explizit kalendarbasiert ist; diese Annahme sollte nicht auf jedes System übertragen werden.
Prüfen Sie die Buchungszeitraum-Variante
Die Buchungszeitraum-Variante ist das Objekt, das steuert, welche Finanzperioden geöffnet oder geschlossen sind. Sie hat eine ID und eine Beschreibung und wird einem oder mehreren Geschäftsbereichen zugewiesen, sodass Geschäftsbereiche, die dieselbe Variante teilen, ihre Perioden gemeinsam verwaltet werden können. Nach der Erstellung der Variante wird sie in den globalen Geschäftsbereichseinstellungen zugewiesen und für das führende Hauptbuch verwendet, wobei zusätzliche Hauptbücher von dieser Zuordnung standardmäßig übernommen werden, es sei denn, für ein nicht-führendes Hauptbuch ist eine andere Variante definiert.
Die Variante wird gegen das Buchungstag geprüft. Die erste Prüfung ist die Gesamt- oder Kopfzeile, die den Dokumenteninsgesamt betrifft und bei jeder Buchung zuerst geprüft wird. Diese Kopfzeile muss für mindestens dieselben Perioden geöffnet sein wie jeder Kontotyp, denn wenn die Kopfzeile geschlossen ist, kann die Buchung gar nicht durchkommen. Wenn alle Kontotypen gleich behandelt werden, kann die Kopfzeile die einzige benötigte Zeile sein. Wenn Kontotypen unterschiedlich behandelt werden müssen, kann die Variante separate Intervalle für jeden Kontotyp definieren.
Die Kontotyp-Detailgenauigkeit ist wichtig, weil das Periodenabschluss-Staging gestaffelt sein kann. Beispielsweise können Kunden- oder Lieferantenbuchungen vor Buchungen auf G/L-Konten geschlossen werden. Zu den Kontotypen gehören Kunde, Lieferant, Vermögenswerte, G/L-Konten, Material und Vertragskonten. Eine Buchung kann daher die Kopfzeilenprüfung bestehen und dennoch an einer Position fehlschlagen, wenn der Kontotyp für diese Position für die Finanzperiode geschlossen ist. Im September-Beispiel könnte das Buchungstag für die Kopfzeile gültig sein, während ein Lieferantenkonto geschlossen ist, und das System würde melden, dass das Hauptbuch für dieses Lieferantenkonto in dieser Finanzperiode nicht geöffnet ist.
Verfolgen Sie ein konkretes Datumsbeispiel
Verwenden Sie die hypothetische Rechnung vom 28. September mit Buchungstag 30. September, ist der erste Schritt, das System die Abbildung des Buchungstags auf eine Finanzperiode unter der zugewiesenen Finanzjahresvariante durchführen zu lassen. Unter einer explizit angenommenen kalendarbasierten Finanzjahresvariante verweist diese Abbildung auf September. Das ist nur der Abbildungsschritt; es sagt noch nicht, ob September geöffnet ist.
Der nächste Schritt ist die Prüfung der Buchungszeitraum-Variante. Das System prüft zuerst die Kopfzeile gegen das Buchungstag. Wenn der September-Zeitraum im Kopfzeilen-Intervall geöffnet ist, besteht die Kopfzeilenprüfung. Wenn die Kopfzeile geschlossen ist, wird die Buchung an dieser Stelle abgelehnt, unabhängig von den Positionen. Wenn die Kopfzeile besteht, prüft das System dann den Kontotyp jeder Position gegen die Variante. Ein Buchungstag im September kann dennoch fehlschlagen, wenn der betreffende Kontotyp für September geschlossen ist.
So kann eine Buchung abgelehnt werden, auch wenn das Dokumentendatum und das Buchungstag beide zu derselben Monat zu gehören scheinen. Das Beispiel ist kein beobachteter Systemtest; es ist eine Möglichkeit, drei Fragen zu trennen: auf welche Periode das Buchungstag abgebildet wird, ob dieser Zeitraum in der Kopfzeile geöffnet ist und ob der spezifische Kontotyp in der Position geöffnet ist. Diese drei Fragen können in einem einzigen Dokument unterschiedliche Antworten liefern.
Lesen Sie die Ablehnung, bevor Sie etwas ändern
Wenn eine Buchung abgelehnt wird, ist der erste Diagnoseschritt, die Ablehnungsmeldung sorgfältig zu lesen, statt sofort die Konfiguration zu ändern. Die Periodenprüfung des Systems liefert unterschiedliche Fehler, je nachdem, wo das Problem auftritt. Wenn das Buchungstag in einer Finanzperiode liegt, die geschlossen ist, antwortet das System, dass eine Buchung in der Periode nicht möglich ist. Wenn das Buchungstag gültig ist, aber ein Kontotyp in der Position geschlossen ist, kann das System eine Meldung zurückgeben, dass das Hauptbuch für diese Finanzperiode und diesen Kontotyp nicht geöffnet ist.
Dieser Unterschied ist der Schlüssel-Diagnosehinweis. Eine Ablehnung auf Kopfzeilenebene weist auf das Buchungstag und die Gesamt-Einstellung der Buchungszeitraum-Variante hin. Eine Ablehnung auf Positionsebene weist auf den Kontotyp, das spezifische Konto oder das Intervall hin, das diesen Kontotyp steuert. Behandeln Sie beide Fehler nicht als dasselbe Problem. Der Ablehnungstext sagt Ihnen, ob das System bei der Kopfzeilenprüfung oder später bei einer Positionenprüfung gestoppt hat.
Im September-Beispiel würde eine Kopfzeilen-Ablehnung bedeuten, dass der September-Buchungszeitraum im Kopfzeilen-Intervall für das Buchungstag nicht geöffnet ist. Eine Positionen-Ablehnung könnte bedeuten, dass das Buchungstag akzeptabel ist, aber das Lieferanten-, Kunden-, Vermögenswert-, G/L-, Material- oder Vertragskonto-Intervall für diese Periode geschlossen ist. Das präzise Lesen der Meldung hindert Sie daran, das Falsche zu ändern, etwa das Dokumentendatum anzupassen, wenn das eigentliche Problem ein geschlossener Buchungszeitraum oder ein geschlossenes Kontotyp-Intervall ist.
Prüfen Sie Umfang und Berechtigungen
Die Buchungszeitraum-Variante enthält separate Intervalle, und das beteiligte Intervall verändert den Umfang der Prüfung. Intervall 1, manchmal Anpassungsintervall genannt, wird verwendet, um Perioden außerhalb der normalen Geschäftsabwicklung zu öffnen, und kann eine Berechtigungsgruppe tragen. Diese Berechtigungsgruppe schränkt ein, wer über das relevante Berechtigungsobjekt in das Sicherheitsprofil des Benutzers in diesen Zeitraum buchen kann. Intervall 2, manchmal Normalintervall genannt, öffnet die aktuelle Periode für Geschäftsvorgänge und gilt für jeden Benutzer; es kann nicht auf die gleiche Weise eingeschränkt werden. Intervall 3 wird für Buchungen aus der Managementbuchhaltung in die Finanzbuchhaltung verwendet, und wenn es nicht ausgefüllt ist, gelten auch die Einstellungen der Intervalle 1 und 2 für diese Buchungen.
Das bedeutet, dass eine Ablehnung aus mehr als einer Quelle kommen kann. Ein Benutzer versucht möglicherweise, in ein Anpassungsintervall zu buchen, ohne die erforderliche Berechtigung zu haben, auch wenn der Zeitraum technisch geöffnet ist. Oder das Normalintervall deckt das Buchungstag einfach nicht ab. Oder die CO-relevante Buchung benötigt einen geöffneten FI-Buchungszeitraum und kann zusätzlich von der CO-Periodensperre betroffen sein. Die Diagnosefrage ist nicht nur 'Ist der Zeitraum geöffnet?', sondern auch 'Welches Intervall gilt, und hat der Benutzer Zugriff auf dieses Intervall?'
Für das September-Beispiel: Wenn das Buchungstag in einer Periode liegt, die nur in Intervall 1 geöffnet ist und der Benutzer nicht die erforderliche Berechtigungsgruppe besitzt, kann die Buchung abgelehnt werden, obwohl der Zeitraum für andere geöffnet ist. Das ist eine andere Situation als ein Zeitraum, der für alle geschlossen ist. Das Unterscheiden dieser Fälle ist wichtig, weil der legitime nächste Schritt davon abhängt, ob das Problem die Berechtigung, die Intervallabdeckung oder ein geschlossener Zeitraum ist.
Wählen Sie eine legitime nächste Maßnahme
Sobald die Ablehnung verstanden ist, sollte die nächste Maßnahme der diagnostizierten Ursache entsprechen und nicht davon ausgehen, dass das Wiederöffnen eines Zeitraums die richtige Lösung ist. Wenn das Buchungstag einfach in einem geschlossenen Zeitraum liegt und die Geschäftsabsicht ist, in einer anderen Periode zu buchen, kann die geeignete Maßnahme die Korrektur des Buchungstags auf einen Zeitraum sein, der für die beabsichtigten Kontotypen geöffnet ist. Wenn das Dokumentendatum und das Buchungstag verwechselt werden, sollte geklärt werden, welches Datum der Geschäftsprozess tatsächlich erfordert, und das Buchungstag entsprechend eingetragen werden.
Wenn die Kopfzeile besteht, aber ein Kontotyp in der Position fehlschlägt, kann das Problem die Kontozuordnung oder den Periodenstatus für diesen Kontotyp sein. In diesem Fall ist die legitime Maßnahme zu überprüfen, ob der Kontotyp für die beabsichtigte Periode geöffnet sein sollte oder ob die Buchung anders weitergeleitet werden sollte. Wenn der Fehler mit einem Anpassungsintervall verbunden ist und der Benutzer keine Berechtigung hat, ist die Maßnahme, einen Benutzer zu verwenden, der die erforderliche Berechtigung besitzt, oder die Buchung über den geeigneten Prozess weiterzuleiten, nicht die Zugriffsberechtigungen informell zu erweitern.
Wenn die Buchung CO-relevant ist, beachten Sie, dass FI- und CO-Periodensteuerungen unterschiedlich sein können. Eine Buchung aus der Managementbuchhaltung in die Finanzbuchhaltung kann einen geöffneten FI-Buchungszeitraum erfordern und kann zusätzlich von der CO-Periodensperre beeinflusst werden. Der legitime nächste Schritt kann sein, beide Steuerungen zu bestätigen, statt nur eine Seite zu ändern. In allen Fällen ist das Ziel, das spezifische Steuerungsversagen zu lösen, das durch die Ablehnung identifiziert wurde, und nicht die Konfiguration als Standardantwort zu ändern.
Halten Sie Editions- und Konfigurationsgrenzen
Die Konzepte in den Einheiten sind allgemein, aber die konkreten Felder, App-Namen, Berechtigungsobjekte und verfügbaren Steuerungen können je nach Produktkonfiguration und Edition variieren. Die Einheiten stellen fest, dass Finanzjahresvarianten die Anzahl der Perioden und deren Start- und Enddaten definieren und dass Buchungszeitraum-Varianten das Öffnen und Schließen steuern. Sie stellen auch fest, dass die Kopfzeile zuerst geprüft wird und dass Kontotypen unterschiedlich behandelt werden können. Das sind die Grenzen, in denen Sie arbeiten sollten: verwenden Sie die Finanzjahresvariante, um die Periodenstruktur zu verstehen, und verwenden Sie die Buchungszeitraum-Variante, um die Steuerung geöffnet/geschlossen zu verstehen.
Verallgemeinern Sie nicht aus einem einzigen System. Ein kalendarbasiertes Finanzjahr kann das September-Beispiel einfach aussehen lassen, aber eine nicht-kalendarbasierte Variante oder Sonderperioden können die Abbildung und die Akzeptanzlogik verändern. Nicht-führende Hauptbücher können unterschiedliche Buchungszeitraum-Varianten verwenden, sodass der führenden-Hauptbuch-Standard nicht immer die ganze Geschichte ist. Die Einheiten stellen außerdem fest, dass Intervall 3 leer gelassen werden kann, in dem Fall gelten Intervalle 1 und 2 auch für CO-relevante Buchungen, was eine weitere konfigurationsabhängige Detail ist.
Halten Sie die Diagnose-logik an das gebunden, was das System tatsächlich prüft: das Buchungstag gegen die Buchungszeitraum-Variante, zuerst auf Kopfzeilenebene und dann auf Kontotyp-Ebene, mit Intervall- und Berechtigungseffekten, wo sie gelten. Verwenden Sie das September-Beispiel nur als Möglichkeit, Datum-Bedeutung, Finanzabbildung und Periodensteuerung zu trennen. Behandeln Sie es nicht als Beweis dafür, wie ein bestimmtes System sich verhalten wird, und stellen Sie es nicht als beobachtetes Testergebnis dar.
Was Sie prüfen sollten
- Prüfen Sie, ob sich die Ablehnung auf den Zeitraum der Dokumentenkopfzeile oder auf einen bestimmten Kontotyp in den Positionen bezieht.
- Verifizieren Sie das Buchungstag und nicht nur das Dokumentendatum, da das Buchungstag die Periodenprüfung steuert.
- Identifizieren Sie die Finanzjahresvariante nur, um zu verstehen, wie viele Perioden existieren; behandeln Sie sie nicht als Steuerung für geöffnet/geschlossen.
- Identifizieren Sie die Buchungszeitraum-Variante, die dem Geschäftsbereich und dem führenden Hauptbuch zugewiesen ist, bevor Sie davon ausgehen, dass ein Zeitraum geöffnet ist.
- Prüfen Sie, ob der fehlgeschlagene Zeitraum in Intervall 1, Intervall 2 oder Intervall 3 liegt, da Berechtigung und Umfang unterschiedlich sind.
- Stellen Sie fest, ob der Benutzer die erforderliche Berechtigungsgruppe für eine Buchung in einem Anpassungsintervall besitzt, falls dieses Intervall beteiligt ist.
- Unterscheiden Sie ein Problem mit einem geschlossenen Zeitraum von einer falschen Buchungsart oder falschen Kontozuordnung, was ebenfalls die Berichterstellung verzerren kann.
- Vermeiden Sie Konfigurationsänderungen als ersten Schritt; verwenden Sie den Ablehnungstext und die Dokumentenfelder, um die Ursache einzugrenzen.
Geltungsbereich
Diese Anleitung basiert auf den bereitgestellten SAP-Lerneinheiten und ist deskriptiv, keine Konfigurationsanleitung. Dokumentenfeldnamen, App-Namen, Berechtigungsobjekte und verfügbare Steuerungen können je nach Produktversion, Edition und Geschäftsbereichskonfiguration variieren. Die Einheiten erklären, dass die Finanzjahresvariante die Anzahl der Perioden und deren Start- und Enddaten definiert, während die Buchungszeitraum-Variante das Öffnen und Schließen steuert. Sie liefern keine universelle Felderliste oder einen garantierten Meldungstext für jedes System. Sonderperioden, nicht-kalendarbasierte Finanzjahre und nicht-führende Hauptbücher mit unterschiedlichen Buchungszeitraum-Varianten können eine einfache Monat-zu-Periode-Annahme ungültig machen. Das illustrative September-Beispiel ist hypothetisch und kein ausgeführtes Systemtest oder beobachtetes Abrufergebnis. Verwenden Sie dies nicht als Ersatz für die tatsächliche Systemmeldung, die spezifische Variantenkonfiguration oder das Berechtigungsdesign in Ihrer Umgebung.