Obligos geben die Kosten von Materialien und Services an, die Sie angefordert oder bestellt haben. Sie binden Mittel, die zu einem späteren Zeitpunkt zu Kosten werden.
Die Obligoverwaltung bildet dementsprechend die Kostenseite der Beschaffungsprozesse im MM-Einkauf auf die Kontierungsobjekte ab. Die angefallenen Kosten werden Business-Objekten wie Aufträgen, Kostenstellen oder Projekten zugeordnet.
Verpflichtungen führen zum Kauf durch:
- Bestellanforderungen (Banf-Obligos oder Banf-Obligos)
Bestellanforderungen legen die internen Bedarfe für ein Material oder eine Dienstleistung fest. Bestellanforderungen haben eine Steuerungsfunktion und können jederzeit geändert werden.
- Bestellungen (Bestellobligos)
Bestellungen sind die vertragliche Aufforderung an einen Lieferanten, bestimmte Waren oder Dienstleistungen unter den angegebenen Bedingungen bereitzustellen. Kurzfristige, einseitige Änderungen sind hier nicht mehr möglich.
- Mittelbindungen (Mittelbindung)
Mit Mittelbindungen reservieren Sie Mittel für relativ sichere Kosten, die Sie noch keinem bestimmten Geschäftsvorgang wie einer Bestellung oder Bestellanforderung zuordnen können.
Die Obligoverwaltung unterscheidet je nach Kontierungsobjekt drei Arten von Obligos:
- Auftragsobligos:
Das Obligo wird einem Auftrag vorbelegt.
- Kostenstellenobligo:
Das Obligo ist einer Kostenstelle vorbelegt.
- Projektobligo:
Das Obligo ist einem Projekt oder einem Projektstrukturplanelement vorbelegt.
Die obige Abbildung gibt einen Überblick über die Modellierungsansätze, die in der Obligoverwaltung verwendet werden.
Die klassische Obligoverwaltung auf Kostenstellen unterscheidet sich nicht von der auf Innenaufträgen.
Klassische Obligoverwaltung:
- Erhöhung des Obligos
Beispielsweise werden bestimmte Waren für einen Auftrag, eine Kostenstelle oder ein Projekt bestellt. In diesem Fall entsteht ein Auftragsobligo in Höhe des Auftragswerts. Das System zeigt Obligos immer mit dem Wert und ggf. der Menge für die Kostenart, das Geschäftsjahr und die Periode des erwarteten Kostenvorfalls an.
- Währungen von Obligos
Das System führt jedes Obligo in der Währung des auslösenden Vorgangs aus (z.B. in der Bestellwährung) und rechnet den Betrag in Kostenrechnungskreis, Buchungskreis und Objektwährung um. Umrechnungen basieren auf der Bestellrate.
- Abbau von Obligos
Geschäftsvorfälle wie Wareneingänge bauen Obligos ab; Istkosten fallen auf dem entsprechenden Kontierungsobjekt an. Dies geschieht, bis z.B. der Geschäftsvorgang "Auftrag" abgeschlossen und das Auftragsobligo vollständig abgebaut wurde.
- Obligovortrag zum Geschäftsjahresende
Um den Geschäftsjahresabschluss zu unterstützen, können Sie die offenen Obligowerte aus Bestellanforderungen, Bestellungen und Mittelbindungen in die erste Periode des nächsten Geschäftsjahres vortragen. Sie können nach Kontierungsobjekten (Auftrag, Kostenstelle oder Projekt) selektieren. Bei Bedarf können Sie auch einzelne Belege bearbeiten.
Der Obligovortrag wird pro Kostenrechnungskreis durchgeführt.
- Neue Lösung für die Obligoverwaltung
Das Anlegen eines Erweiterungsledgers für Obligos aktiviert die neue Obligoverwaltung basierend auf Buchungsbelegen im Journal.
Buchungsbelege für Obligos werden in dieses Erweiterungsledger gebucht, sodass sie von Istbuchungen unterschieden werden können.
Auch wenn diese neue Art des Obligos aktiviert ist, werden die alten Obligotabellen weiterhin parallel gebucht, sodass die alten Obligoberichte und das Haushaltsmanagement weiterhin funktionieren. Für das Reporting gilt:
- Die alten Obligoberichte zeigen keine Obligos basierend auf Buchungsbelegen im Erweiterungsledger an; diese werden nur in den SAP-Fiori-Apps Obligo nach Kostenstelle und Projektkostenbericht/Budgetbericht angezeigt.
Die vorstehende Abbildung beschreibt die wichtigsten funktionalen Einschränkungen der neuen Obligoverwaltung.
Im Folgenden finden Sie eine vollständige Liste aller Einschränkungen:
- Als Kontierungsarten werden nur Projekte (PSP-Elemente) und Kostenstellen unterstützt.
- Manuelle Obligos werden nicht unterstützt.
- Es wird kein Obligovortrag unterstützt.
- Es werden nur Bestellungen und Bestellanforderungen unterstützt.
- Für Release S/4HANA 1809 müssen die Bestellungen und Bestellanforderungen für ein Material mit Materialstamm sein. Seit SAP S/4HANA 1909 werden auch Bestellungen und Bestellanforderungen ohne Materialstamm unterstützt.
- Für Frachtkosten sind keine separaten Obligos möglich.
- Geplantes Obligo kann - wie in der alten Obligolösung - nicht gemeldet werden. Es kann nur das "aktuelle" Obligo gemeldet werden.
- Ein WE/RE-Konto muss konfiguriert werden.
- Eine Bestellung oder Bestellanforderung mit Kontierung Sachkonto des Kostenartentyps 90 wird nicht unterstützt. Die Sachkontoart lautet "Bestandskonto". Daher wird ein Kontierungs-PSP-Element in Kombination mit Anlage nicht unterstützt.
- Die Buchung (und der Abbau) von Obligo-Einzelposten wird mit der entsprechenden Transaktionswährung ausgelöst. Alle Werte in anderen Währungen werden bei jeder Buchung gemäß den aktuellen Währungsumrechnungsregeln berechnet, die in den Ledger-Einstellungen konfiguriert sind. Das bedeutet, dass nach der Lebensdauer einer Bestellung oder Bestellanforderung ein Saldo von 0 nur für die Transaktionswährung erwartet werden kann. Alle anderen Währungen können aufgrund von Rundungsdifferenzen oder anderen Währungsumrechnungsregeln von 0 abweichen.
- Obligos aus Anzahlungen werden nicht unterstützt.
- Eine einzelne Bestellung darf nicht mehr als 499 Kontierungen enthalten. Wenn Sie eine Bestellanforderung als Referenz zum Anlegen einer Bestellung verwenden, beträgt die maximale Anzahl unterstützter Kontierungen der entsprechenden Bestellanforderung 249. Siehe SAP-Hinweis 2991264.
- Der Korrekturreport RKANBU01, der zur Korrektur des klassischen Obligos (Tabelle COOI) verwendet wird, kann nicht verwendet werden, um das neue Obligo (Tabelle ACDOCA) zu korrigieren. Es gibt keinen Report, der das neue Obligo in ACDOCA automatisch anpasst oder korrigiert.
- Die Obligo-Zuschlagsberechnung wird nicht unterstützt.
- Das Konzept zusätzlicher statistischer Objekte in derselben Buchungsbelegposition wie das echte Objekt wird nicht unterstützt. Wenn ein statistisches Objekt (PSP-Element) in der Bestellanforderung/Bestellposition parallel zu einem echten Objekt (Kostenstelle) verwendet wird, wird das statistische PSP-Element als separate Vorschaubelegposition gebucht. Dies unterscheidet sich von der tatsächlichen Wareneingangs-/Rechnungseingangsbuchung.
Durch die Verwendung eines parallelen Ledgers zum umfassenden Journal können alle Buchungen, die sich auf die Zukunft beziehen oder die möglicherweise nicht in der gesetzlichen Buchhaltung vorkommen, als Nebenbuch geführt werden, d.h. neben den echten Finanzbuchungen.
Die Einrichtung und Verwendung von Erweiterungsledgern in verschiedenen Szenarios und in Kombination mit echten Ledgern (ACDOCA) wird auch als Predictive Accounting bezeichnet.
Predictive Accounting basiert auf zwei Säulen, die zusammen zukünftige Trends und Ergebnisse zeigen:
- Datenstruktur von ACDOCA mit allen Bilanz- und GuV-Informationen sowie historischen Daten
- Erweiterungsledger mit Daten, die erwartete Berechnungen und Simulationsergebnisse enthalten.
Konzept des Erweiterungsledgers (sogenanntes Prognose-Ledger):
Hierbei handelt es sich um ein spezielles Nebenbuch, in dem die Prognoseergebnisse strukturell genau wie die historischen Istdaten abgelegt werden. Das bedeutet, dass alle Finanzprozesse nicht nur mit Echtdaten, sondern auch mit zukünftigen Daten basierend auf aktuellen Finanzdaten ausgeführt werden können. Auf diese Weise können Sie vorhersagen, wie sich die Finanzergebnisse am Ende der aktuellen Bilanzperiode oder des laufenden Quartals entwickeln werden, und die Gründe dafür verstehen.
Die Buchhaltung hat sich traditionell auf faktenbasiertes, aktuelles und historisches Reporting konzentriert, d.h. was letzte Woche, Monat, letztes Jahr geschehen ist, wie unterscheiden sich die Zahlen zwischen dem Vorjahr und diesem Geschäftsjahr. Diese pastenorientierte Perspektive bietet den Mehrwert für das Verständnis der aktuellen Situation, trägt aber nicht dazu bei, die Zukunft besser vorherzusagen oder zu planen. Predictive Accounting bietet hierfür eine zentrale Lösung, die die Sichten von Buchhaltern und Controllern kombiniert.
Eine Bestellung oder eine Bestellanforderung ist z.B. im Bereich des internen Einkaufs die Grundlage für die Vorhersage zukünftiger Materialkosten, eines Wareneingangs und eines Rechnungseingangs.
Beim Wareneingang werden die tatsächlichen Materialkosten sowie Wareneingang und Rechnungseingang gebucht.
Sowohl Prognose- als auch Istwerte werden in der Tabelle ACDOCA gesichert. Sie sind jedoch unterschiedlichen Ledgern zugeordnet. Prognostizierte Werte sind dem Erweiterungsledger zugeordnet, Istwerte werden dem führenden Ledger und ggf. einem nicht-führenden Ledger zugeordnet, wenn eine Ledgerlösung für die parallele Rechnungslegung verwendet wird.
Die Tabelle ACDOCA ist also die zentrale Datenquelle für Ist- und Prognosewerte.
Prognose im Einkauf: Material wird für Kostenstellen bestellt, und es wird erwartet, dass ein Obligo auf diese Kostenstellen gebucht wird.
In SAP S/4HANA sind Obligos prognostizierte Aufwände, die in ACDOCA im Erweiterungsledger gesichert werden.
Voraussetzung:
- Die Obligoverwaltung für das Controlling muss aktiviert sein.
- Zuordnung von Auftragspositionen zu einer Kostenstelle oder einem PSP-Element.
Wenn die Bestellung gesichert wird, wird ein Predictive-Accounting-Beleg angelegt, der den prognostizierten Materialverbrauch für eine Kostenstelle sowie die erwartete Änderung im WE/RE-Konto enthält, d.h. die Ergebnisse der Simulation werden als Buchungsbelege im Prediction-Ledger gespeichert.
Wenn der Ist-Wareneingang zur Bestellung gebucht wird, werden die prognostizierten Materialeinkaufskosten/die simulierten Buchungen im Erweiterungsledger storniert, und die Istbelege für den Wareneingang/die Materialkosten werden im führenden Ledger gebucht. Der Wert auf dem WE/RE-Konto im Erweiterungsledger wird ebenfalls storniert.
