Projektbericht und technische Architektur

Projektbericht

Kabelhersteller: Materialdisposition

Ausgangssituation

11,9 Mio. € waren im Material gebunden. Die Reichweite betrug 51 Tage, trotzdem wiesen 4,8 % der Bedarfspositionen Fehlteile auf. Wiederbeschaffungszeiten von teilweise neun Wochen erschwerten einen kurzfristigen Bestandsabbau.

Zielsetzung

Wir wollten Kapital aus dem Materialbestand freisetzen und gleichzeitig die Versorgung verbessern. Im Projektverlauf haben wir KI eingebracht, um diese Themen umzusetzen.

Ergebnis

Nach zwölf Wochen hatten wir den Bestand auf 8,2 Mio. € reduziert und 3,7 Mio. € Liquidität freigesetzt. Die Reichweite sank auf 35 Tage, die Fehlteilquote auf 1,9 %. Die langen Wiederbeschaffungszeiten prägten den Zeitraum bis zum Ergebnis.

3,7 Mio. € freigesetzte Liquidität

11,9 Mio. € Ausgangsbestand minus 8,2 Mio. € Endbestand ergeben 3,7 Mio. € weniger Kapitalbindung. Das entspricht 31,1 %, gerundet 31 %. Projektzeitraum: zwölf Wochen. Die Kapitalfreisetzung ist ein einmaliger Effekt, keine jährliche Kosteneinsparung.

Bestätigter Projektverlauf

1. Ausgangslage: 11,9 Mio. € Materialbestand. Hohe Kapitalbindung bei 51 Tagen Reichweite und einer Fehlteilquote von 4,8 %.
2. Rahmenbedingung: Bis zu 9 Wochen Wiederbeschaffung. Die langen Beschaffungszyklen bestimmten den Zeitraum bis zur Bestandswirkung.
3. Umsetzung: KI im Projekt eingesetzt. Ausgangspunkt war das wirtschaftliche Ergebnis. KI wurde im Verlauf zur Umsetzung der Themen eingebracht.
4. Nach 12 Wochen: 3,7 Mio. € Kapital freigesetzt. Der Bestand lag bei 8,2 Mio. €, die Reichweite bei 35 Tagen und die Fehlteilquote bei 1,9 %.

Technische Einordnung

Das nachfolgend ausgearbeitete technische Muster verbindet SAP MM / MRP über einen Java-Dienst mit SAP JCo mit Python, PostgreSQL und Dash. SAP bleibt führend; Vorschläge werden kontrolliert freigegeben. Die konkreten Produktversionen, Schnittstellen und Modellbausteine des realisierten Projekts sind in dieser Vorschau noch nicht als Ist-Installation dokumentiert.

Datenfluss der Referenzarchitektur: SAP MM / MRP → PostgreSQL → Python → Dash → SAP BANF

Ausnahmen: Technisches Muster: Geänderte Bedarfe und bereits gedeckte Mengen werden vor der Übergabe erneut geprüft. Die konkrete Systemkonfiguration des realisierten Projekts ist separat zu dokumentieren.

Prüfkriterien

• Bestandswerte für denselben Material- und Bewertungsumfang vergleichen.
• Reichweite auf gleicher Verbrauchsbasis betrachten.
• Versorgungsqualität parallel zum Bestandsabbau über die Fehlteilquote bewerten.

Messung und Einordnung

Bestandsreduzierung = (11,9 − 8,2) / 11,9 = 31,1 %. Die Reichweite sank von 51 auf 35 Tage. Bei rund 233.333 € Tagesverbrauch entsprechen 11,9 Mio. € 51 Tagen und 8,2 Mio. € rund 35 Tagen. Die Fehlteilquote sank um 2,9 Prozentpunkte.

Die Werte und der Zeitraum wurden von Kenneth Hytrek als erreichte Projektergebnisse bestätigt. KI wurde im Projektverlauf eingesetzt. Eine isolierte Aufteilung des Ergebnisses in KI- und sonstige Maßnahmenwirkungen liegt nicht vor. Die Grafik zeigt ausschließlich die bestätigten Gesamtbestände; das Branchenbild ist KI-generiert.

Lösungsbeispiel

Metallverarbeitung: Auftragserfassung

Ausgangssituation

1.000 Bestellungen im Monat kommen per E-Mail. Der Innendienst überträgt Positionen in SAP, sucht Artikelnummern und klärt Preisabweichungen. Im Schnitt bindet jeder Auftrag acht Minuten.

Zielsetzung

Die aktive Bearbeitung auf 2,5 Minuten senken und Aufträge innerhalb von vier Service-Stunden bestätigen. Unklare Positionen sollen gezielt zur Prüfung gelangen.

Lösungsansatz im Szenario

Ein n8n-Workflow übernimmt das Postfach. Document AI liest die Bestellung; Python prüft Artikel, Mengen und Konditionen. Freigegebene Entwürfe werden über SAP JCo als Auftrag angelegt.

53.900 € Kapazitätswert / Jahr

1.100 Stunden brutto abzüglich 120 Stunden jährlicher Pflege, bewertet mit 55 €/h. Plattform- und Supportkosten kommen hinzu. Freie Zeit wird erst durch ihre Nutzung zum Ergebnis.

Vorgeschlagener Umsetzungsplan

1. Woche 1: Aufträge und Regeln erfassen. Repräsentative PDFs sammeln. Artikelzuordnung, Pflichtfelder, Dubletten und Freigabegrenzen definieren.
2. Woche 2–3: Dokumente strukturieren. Microsoft Graph und n8n verbinden. Document AI liest Text und Layout; optional strukturiert Gemini die Positionen.
3. Woche 4–5: SAP-Aufträge vorbereiten. Validierung und Korrekturansicht entwickeln. BAPI-Anlage, Konditionsprüfung und Rücklesen der Einteilungen im Testsystem nachweisen.
4. Woche 6: Unter Tagesbedingungen prüfen. Zunächst alle Aufträge freigeben lassen. Fehler, aktive Arbeitszeit und Wartezeit messen; erst danach Standardfälle zur Automatik freigeben.

Technische Implementierung

Outlook → Graph-Delta-Abfrage → n8n → Dokumentenprüfung / OCR → strukturiertes JSON → Stammdatenvalidierung → Dash-Freigabe → JCo / BAPI_SALESORDER_CREATEFROMDAT2 → SAP-Ergebnis. ¹ Gemini ist optional; Modellversion, Verarbeitungsort und Datenaufbewahrung werden gesondert geprüft.

Datenfluss der Referenzarchitektur: Outlook / Graph → n8n → Document AI → Python + Dash → SAP SD

Ausnahmen: Artikel unbekannt oder Preis abweichend? Der Vorgang wartet in der Dash-Prüfansicht. Erst nach Korrektur und Freigabe geht er zurück in den Workflow. ¹ Gemini kann optional die Strukturierung ergänzen.

Prüfkriterien

• Unbekannte Artikel und Preisabweichungen erreichen zuverlässig den Innendienst.
• Gleiche Bestellung und Änderungsbestellung werden unterschieden.
• Ein Timeout erzeugt nach Wiederaufnahme keinen zweiten SAP-Auftrag.

Messung und Einordnung

Aktive Bearbeitungszeit separat von Liegezeit messen. Eingang und bestätigten Ausgang über eine Vorgangs-ID verbinden. Bestätigungszeit bei gleichen Servicezeiten und Fallklassen vergleichen; zusätzlich den 90. Perzentilwert ausweisen. Kritische Feldfehler und Korrekturquote begleiten die Zeitmessung.

700 Standardfälle × 1 Minute + 300 Ausnahmen × 6 Minuten = 2.500 Minuten. Vorher 1.000 × 8 = 8.000 Minuten. Differenz 91,7 Stunden / 160 = 0,57 FTE. 10 Stunden Pflege pro Monat werden im Jahreswert abgezogen. Sämtliche Werte sind Beispielannahmen.

Lösungsbeispiel

Automobilzulieferer: Prognose & S&OP

Ausgangssituation

500 Serienartikel werden in Excel geplant. Vertrieb, Disposition und Fertigung arbeiten mit unterschiedlichen Mengenständen. Der Prognosefehler liegt im Szenario bei 28 % WAPE.

Zielsetzung

Den Fehler auf 18 % WAPE senken und die monatliche Planung von 40 auf 16 Stunden verkürzen. Ein abgestimmter Bedarf soll die gemeinsame Grundlage für SAP PP bilden.

Lösungsansatz im Szenario

Python vergleicht Prognosemodelle mit einer einfachen Basis. Im Dash-Cockpit ergänzt die Planung Marktinformationen, dokumentiert Korrekturen und gibt den Bedarf für SAP frei.

15.840 € Kapazitätswert / Jahr

24 Stunden × 12 Monate × 55 €/h. Eine verfügbare Kapazität von 0,15 FTE bei 160 Stunden pro Monat; keine automatisch realisierte Personalkostensenkung.

Vorgeschlagener Umsetzungsplan

1. Woche 1–2: SAP-Daten erschließen. Absatzdefinition, Artikel und Einheiten abstimmen. CSV-Export oder lesenden RFC über SAP JCo aufbauen.
2. Woche 3–4: Modelle vergleichen. Zeitreihen bereinigen. StatsForecast gegen eine einfache Basis testen. Rücktests nach Artikelgruppe und Horizont auswerten.
3. Woche 5–6: Planung bedienbar machen. Dash-Cockpit mit Prognose, Korrekturgrund und Freigabe entwickeln. Offene Aufträge ohne doppelte Bedarfszählung berücksichtigen.
4. Woche 7–8: SAP-Übergabe nachweisen. Freigegebene Bedarfe im Testsystem übergeben, Fehlerfälle prüfen und den abgegrenzten Parallelbetrieb starten.

Technische Implementierung

SAP ECC → freigegebener ABAP-Extraktor → Java / SAP JCo → Flask-API → PostgreSQL → Python-Rechenjob → Dash-Freigabe → SAP PP. BAPI_REQUIREMENTS_CREATE ist ein releaseabhängig zu prüfender Kandidat. Die Anwendung schreibt keine SAP-Tabellen direkt.

Datenfluss der Referenzarchitektur: SAP ECC → PostgreSQL → StatsForecast → Dash → SAP PP

Ausnahmen: Ein Artikel hat zu wenig Historie oder einen Strukturbruch? Die Prognose wird markiert und fachlich geprüft. Offene Aufträge werden gemäß SAP-Planungsstrategie verrechnet.

Prüfkriterien

• Historie und Stornos stimmen mit dem vereinbarten SAP-Report überein.
• Rücktests nutzen nur zum jeweiligen Stichtag bekannte Daten.
• Kundenaufträge und Vorplanbedarfe werden gemäß SAP-Strategie verrechnet.

Messung und Einordnung

WAPE = Σ|Prognose − Ist| / ΣIst. Bias = Σ(Prognose − Ist) / ΣIst. Vergleich auf identischen Testfenstern und Prognosehorizonten; keine Vermischung inkompatibler Mengeneinheiten. Planungszeit einschließlich Korrekturen und Ausnahmen erfassen.

Die Grafik zeigt zwölf synthetische Wochen und die Beispielprognose. Der relative Rückgang von 28 % auf 18 % WAPE beträgt 35,7 % und wird im Titel auf 36 % gerundet. Ausgangs- und Zielwerte sind konstruierte Szenarien. 55 €/h und 160 h/FTE pro Monat sind Rechenannahmen. Laufender Betrieb und Einführung sind im Kapazitätswert nicht abgezogen.

Lösungsbeispiel

Kunststoffverarbeitung: Produktionsplanung

Ausgangssituation

Sechs Spritzgussmaschinen teilen sich Werkzeuge und Personal. Eilaufträge verändern die Reihenfolge; häufige Wechsel kosten 120 Rüststunden pro Monat. Die Planung reagiert täglich neu.

Zielsetzung

Rüstzeiten auf 90 Stunden im Monat reduzieren und 94 % der Aufträge zum eingefrorenen Solltermin fertigstellen. Der Plan muss Material, Werkzeuge und Schichten respektieren.

Lösungsansatz im Szenario

OR-Tools berechnet zulässige Reihenfolgen. Die Planung vergleicht Terminfolgen im Dash-Cockpit und gibt die Variante an das MES. Rückmeldungen machen neue Engpässe sichtbar.

360 Maschinenstunden / Jahr

Weniger Rüstaufwand schafft zusätzliche Kapazität am Engpass. Ein Deckungsbeitrag entsteht erst, wenn Nachfrage, Personal und Material diese Kapazität tatsächlich nutzbar machen.

Vorgeschlagener Umsetzungsplan

1. Woche 1–3: Restriktionen erfassen. Arbeitspläne, Werkzeuge, Schichten und Materialtermine prüfen. Rüstmatrix und eingefrorenen Planungsbereich definieren.
2. Woche 4–6: Planungsmodell entwickeln. CP-SAT-Modell in OR-Tools aufbauen. Ressourcen, Arbeitsgangfolgen und gesperrte Aufträge als harte Bedingungen abbilden.
3. Woche 7–9: Szenarien integrieren. Dash-Cockpit und MES-Rückmeldungen verbinden. Eilaufträge, Maschinenausfall und Planänderungen nachvollziehbar darstellen.
4. Woche 10–12: Planung im Betrieb validieren. Ergebnisse mit unabhängigem Regelprüfer und Planervergleich prüfen. Dispatch-Übergabe und Rückfall in den bisherigen Plan abnehmen.

Technische Implementierung

SAP PP / MES → Integrationsadapter → PostgreSQL → OR-Tools CP-SAT → Dash-Freigabe → MES-Dispatch. SAP-Terminänderungen benötigen einen separat geprüften PP-Adapter. Die Kernrechnung ist mathematische Optimierung. Maschinensteuerung ist nicht Teil dieses Umfangs.

Datenfluss der Referenzarchitektur: SAP PP → MES → OR-Tools → Dash → MES-Dispatch

Ausnahmen: Keine zulässige Lösung oder Maschinenstillstand? Der letzte freigegebene Plan bleibt erhalten. Die Planung bewertet Alternativen; eine automatische Maschinensteuerung ist nicht vorgesehen.

Prüfkriterien

• Kein Maschinen-, Werkzeug- oder Personalbedarf verletzt die modellierten Kapazitätsgrenzen.
• Fertigung beginnt nur bei bestätigter Material- und Qualitätsfreigabe.
• Bei fehlender zulässiger Lösung oder veralteten Daten bleibt der gültige Plan erhalten.

Messung und Einordnung

Termintreue = bis zum eingefrorenen Solltermin fertiggestellte Aufträge / alle fälligen Aufträge. Rüstzeiten aus MES oder standardisierter Rückmeldung ermitteln. Produktmix, Schichten und Auslastung im Vorher-Nachher-Vergleich berücksichtigen. Zusätzliche Maschinenzeit ist keine FTE-Einsparung.

Die Balken zeigen einen illustrativen Reihenfolgeplan, keinen ausgeführten Optimierungslauf. 120 − 90 = 30 Stunden monatlich beziehungsweise 360 Stunden jährlich. Ein Geldwert wird ohne belegten Engpassbeitrag bewusst nicht angesetzt.

Lösungsbeispiel

Maschinenbau: Versandplanung

Ausgangssituation

Fertigstellung, Qualitätsfreigabe und Abfahrt werden separat abgestimmt. Für wiederkehrende Baugruppen entstehen kurzfristige Transporte. Sonderfrachten kosten im Szenario 12.000 € monatlich.

Zielsetzung

Sonderfrachtkosten auf 7.000 € im Monat begrenzen und 96 % der Aufträge pünktlich und vollständig liefern. Nur tatsächlich freigegebene Ware soll verbindlich gebucht werden.

Lösungsansatz im Szenario

Python verbindet Lieferungen mit Fertigmeldungen und Transportfenstern. Das Cockpit zeigt bündelbare Sendungen. Nach Freigabe bucht n8n beim Dienstleister und liest den Status zurück.

60.000 € geringere Sonderfracht / Jahr

5.000 € × 12 Monate bei vergleichbarem Versandvolumen und Tarifniveau. Dieser Kostenbeitrag ist separat vom Kapazitätsgewinn zu bewerten; Projekt- und Betriebskosten sind noch abzuziehen.

Vorgeschlagener Umsetzungsplan

1. Woche 1: Lieferfähigkeit klären. Fertigmeldung, Qualitätsstatus, Maße, Verpackung und Lieferfenster als verbindliche Eingaben festlegen.
2. Woche 2–3: Versandvorschläge berechnen. Python-Regeln für Bündelungen und Abfahrten entwickeln. Dienstleisterkonditionen und zusätzliche Kosten einbeziehen.
3. Woche 4–5: Transportbuchung anbinden. Freigabe im Cockpit und Aufruf der Dienstleister-API über n8n umsetzen. Buchungsreferenz und Status dauerhaft speichern.
4. Woche 6: Ausnahmen und Wirkung prüfen. Buchungsablehnung, Storno und unbekannten Status testen. Sonderfahrten und OTIF mit dem Versand auswerten.

Technische Implementierung

SAP SD / MES → Datenadapter → Python-Planung → Dash-Freigabe → n8n → vertraglich verfügbare Dienstleister-API. Buchungsstatus wird zurückgelesen. SAP-Warenausgang und Faktura bleiben eigenständige Prozesse. Zoll und Gefahrgut sind separat abzugrenzen.

Datenfluss der Referenzarchitektur: SAP SD + MES → Python → Dash → n8n → Speditions-API

Ausnahmen: Die Buchungsantwort fehlt? Zuerst die gespeicherte Referenz beim Dienstleister prüfen. Eine erneute Anfrage darf keine Doppelbuchung erzeugen.

Prüfkriterien

• Ware ohne Qualitätsfreigabe wird nicht verbindlich disponiert.
• Timeouts führen zum Statusabgleich statt zur erneuten Blindbuchung.
• Transportkapazität, Verpackung und Kundenfenster sind überprüfbare Bedingungen.

Messung und Einordnung

Sonderfrachtkosten anhand tatsächlich gebuchter Zuschläge, nach Versandvolumen und Tarifänderungen normalisiert. OTIF = vollständig und innerhalb des vereinbarten Fensters gelieferte Aufträge / alle fälligen Aufträge. Nachträgliches Verschieben des Solltermins verbessert den KPI nicht.

Ausgang und Ziel sind illustrative Annahmen. OTIF wird auch durch Fertigung, Kundenfenster und Transport beeinflusst; Verbesserungen werden nicht allein der Versandsoftware zugerechnet. Wiederkehrende Baugruppen, keine vollständige Einzelfertigung eines Großprojekts.

Durchgängige Referenzarchitektur

Auftrag bis Zahlung

Der Ablauf beschreibt das systemübergreifende Zielbild. Er ist kein gesonderter Nachweis einer durchgängig realisierten Kundeninstallation.

01 Bestellung empfangen

Tools: Outlook · Microsoft Graph · n8n

Eingabe: E-Mail, PDF oder ein separat angebundener strukturierter Kundenauftrag.

Microsoft Graph übernimmt neue Nachrichten. n8n registriert IDs, Anhang und Prüfsumme. Ein Prüfdienst kontrolliert Dateityp und Schadsoftware.

Übergabe: Ein eindeutig zugeordneter Vorgang mit Originaldokument und Eingangszeit.

Ausnahme: Verdächtige oder unlesbare Anhänge gehen in die manuelle Klärung.

02 Inhalte verstehen

Tools: Document AI · optional Gemini

Eingabe: Geprüftes Dokument mit Kundenreferenz, Positionen, Mengen und Wunschdatum.

OCR erkennt Text und Layout. Ein optionales Sprachmodell strukturiert die Angaben. Pydantic prüft Datentypen und Pflichtfelder; Fundstellen bleiben erhalten.

Übergabe: JSON mit Kundenreferenz, Artikel, Menge, Einheit, Preis und Datum.

Ausnahme: Fehlende Angaben werden sichtbar markiert. Dokumentinhalt darf keine Systemaktionen anweisen.

03 Auftrag prüfen

Tools: SAP SD · Python · Dash

Eingabe: Bestellpositionen, Kundenstammdaten, Artikelzuordnung und ERP-Konditionen.

Python gleicht Kunde, Artikel, Einheit und Preise mit SAP ab. Der Innendienst sieht Abweichungen und entscheidet in Dash. Dubletten werden anhand der Kundenreferenz geprüft.

Übergabe: Freigegebener Auftragsentwurf mit begründeten Korrekturen und unveränderlichem Planstand.

Ausnahme: Preisabweichung, Kredit- oder Auftragssperre und Änderungsbestellung brauchen eine definierte Bearbeitung.

04 In SAP anlegen

Tools: Java / SAP JCo · SAP SD BAPI

Eingabe: Geprüfter Entwurf mit Vertriebsbereich, Partnerrollen und Einteilungen.

Ein JCo-Adapter legt den Auftrag über einen im Release geprüften BAPI an. Er wertet SAP-Rückgaben aus und steuert Commit oder Rollback in derselben Sitzung.

Übergabe: SAP-Auftrag mit Belegnummer, Status und eindeutig zugeordnetem Übergabeauftrag.

Ausnahme: Ein Timeout nach möglicher Buchung führt zum Statusabgleich. Es wird nicht blind neu angelegt.

05 Termin zusagen

Tools: SAP ATP · Kapazitätsprüfung · Dash

Eingabe: SAP-Auftrag, Materialverfügbarkeit, bestätigte Zugänge und freigegebene Kapazität.

SAP prüft die konfigurierte Verfügbarkeit. Eine zusätzliche Kapazitätsprüfung bewertet Engpässe; klassische ATP allein garantiert keine endliche Maschinenkapazität. Der Vertrieb gibt Ausnahmen frei.

Übergabe: Dokumentierte Lieferzusage. Eine freigegebene Bestätigung kann über Outlook / Graph versendet werden.

Ausnahme: Teilmenge oder unhaltbarer Wunschtermin wird mit dem Kunden geklärt.

06 Material disponieren

Tools: SAP MM / MRP · Python · Dash

Eingabe: SAP-Bedarfe, verwendbare Bestände, offene Beschaffung und Liefertermine.

MRP bleibt in SAP. Python priorisiert drohende Fehlteile und bewertet Lieferzeitrisiken. Eine freigegebene Ergänzung wird nach erneutem Belegabgleich übergeben.

Übergabe: Nachvollziehbare Beschaffung oder Terminmaßnahme mit Belegbezug.

Ausnahme: Fehlteil, Lieferantenwechsel und hoher Bestellwert bleiben freigabepflichtig.

07 Fertigung einplanen

Tools: SAP PP · OR-Tools · Dash

Eingabe: Arbeitsgänge, Materialtermine, Schichten, Werkzeuge und Ressourcen.

OR-Tools CP-SAT berechnet Reihenfolgen innerhalb der vereinbarten Bedingungen. Das Cockpit zeigt Terminfolgen. Die Planung gibt die gewählte Variante an MES oder Dispatch weiter.

Übergabe: Ein versionierter Fertigungsplan mit fixierten kurzfristigen Arbeitsgängen.

Ausnahme: Keine zulässige Lösung oder veraltete Daten stoppen eine automatische Planfreigabe.

08 Fertigen und prüfen

Tools: MES · SAP PP / QM · Mitarbeitende

Eingabe: Freigegebener Arbeitsplan und Fertigungsauftrag.

Mitarbeitende und MES melden Mengen, Zeiten und Ausschuss. SAP QM oder der vorhandene Qualitätsprozess erteilt die Freigabe. Statusänderungen fließen zurück in die Planung.

Übergabe: Verlässliche Fertigmeldung und explizite Qualitätsfreigabe für den Versand.

Ausnahme: Ausfall, Ausschuss oder Qualitätssperre lösen eine Terminbewertung aus. Keine direkte SPS-Steuerung.

09 Versand koordinieren

Tools: SAP SD · Python · n8n · Speditions-API

Eingabe: Freigegebene Ware, offene Lieferungen, Verpackung und Kundenfenster.

Python bildet zulässige Versandoptionen. Nach Freigabe bucht n8n über einen konkreten Dienstleisteradapter. Referenz und Status werden zurückgelesen.

Übergabe: Abgestimmte Lieferung mit bestätigter Transportbuchung.

Ausnahme: Unklare Buchung, fehlende Qualitätsfreigabe oder Sonderfahrt wird gezielt geklärt.

10 Lieferung abschließen

Tools: SAP Logistik · Lager / WMS · Carrier

Eingabe: Kommissionierte Ware, Versandauftrag und Transportreferenz.

Lager oder WMS bestätigt den physischen Versand. SAP bucht den Warenausgang im bestehenden freigegebenen Prozess. Carrier-Status und gegebenenfalls Zustellnachweis werden abgeglichen.

Übergabe: Gebuchter Warenausgang und ein nachvollziehbarer Lieferstatus.

Ausnahme: Fehlmenge, Transportschaden oder fehlender Nachweis wird einer verantwortlichen Person zugeordnet.

11 Rechnung erstellen

Tools: SAP SD / FI · bestehender Rechnungskanal

Eingabe: Abrechenbarer Liefer- oder Auftragsstatus gemäß vereinbartem Fakturaverfahren.

SAP erzeugt die Faktura aus dem fachlich freigegebenen Fakturavorrat. Steuer-, Preis- und Buchungslogik bleiben in SAP. Der bestehende gültige Rechnungskanal übernimmt den Versand.

Übergabe: Rechnungsbeleg mit FI-Forderung und Versandstatus.

Ausnahme: Fakturasperre, strittiger Preis oder fehlende Rechnungsdaten verhindert den unkontrollierten Versand.

12 Zahlung abgleichen

Tools: SAP FI · elektronischer Kontoauszug

Eingabe: FI-Forderung, vertragliches Zahlungsziel und vorhandener Bankimport.

SAP FI ordnet Zahlungen über den bestehenden Kontoauszugsprozess zu. Offene oder unklare Posten werden zur Klärung priorisiert. Das Verfahren setzt keine KI voraus.

Übergabe: Ausgeglichene Forderung oder ein zugewiesener Klärfall. Erst jetzt ist der Zahlungseingang realisiert.

Ausnahme: Teilzahlung, Abzug oder Überfälligkeit wird geprüft. Schnellere Faktura verkürzt kein vertragliches Zahlungsziel automatisch.