Diese Rubrik beginnt mit einer einzigen Strecke, weil an ihr alles hängt: Ein Hersteller ruft produktionssynchron ab, der Zulieferer fertigt, lagert aus, verlädt und liefert — und abgerechnet wird nicht vom Zulieferer, sondern vom Hersteller. Acht Stationen, jede mit eigenen Belegen und eigenen Bruchstellen. Wer eine davon kennt, aber die Nachbarstation nicht, sucht Fehler an der falschen Stelle.
Die SAP-Angaben sind im System nachgesehen — Tabelle, Feld, Baustein, Nachrichtenart, geprüft in einem ECC 6.0 und einem S/4HANA, beides eigene Systeme, beides streng lesend. Wo etwas aus der SAP-Dokumentation statt aus dem System stammt, steht es dabei. Keine Angabe stammt aus einem Kundenprojekt.
Die Kette in acht Stationen
1. Der Hersteller ruft ab — produktionssynchron
Der Takt kommt nicht aus der Disposition, sondern aus der Fertigung des Herstellers: je Fahrzeug eine Abrufmenge, in der Reihenfolge, in der gebaut wird, mit Verbauort und Sequenznummer. Der Abruf ersetzt den Lieferplan nicht, er legt sich als eigener Belegstrang daneben — kaufmännisch trägt weiter der Lieferplan.
2. Der Abruf läuft im JIT-Strang auf
JIT hat einen eigenen Eingang, getrennt vom Lieferabruf. Zwei Nachrichtenarten sitzen auf denselben Basistypen SEQJIT01 bis SEQJIT03: SEQJIT für den sequenzierten, PAB_ORDERS für den Mengenabruf aus KANBAN. Beide verarbeitet derselbe Baustein IDOC_INPUT_SEQJIT, Anwendungsobjekt BUS2150. Die Datenspur läuft über JITHD (Abrufumfang), JITIT (Teilegruppe) und JITCO (Abrufkomponenten).
Zwei Begriffe werden dabei regelmäßig verdreht. Der produktionssynchrone Abruf ist der Sequenzabruf, das sind nicht zwei Dinge; und der Mengenabruf ist keine Vorstufe davon, sondern eine gleichrangige zweite Abrufart. Die Domäne JIT_ABTYP führt drei gleichrangige Festwerte: S produktionssynchroner Abruf, D Mengenabruf, I interner Abruf. Der Wert steht je Abruf in JITHD-ABTYP und kommt vom Kunden im Kopfsegment E1KSJCL, nicht aus dem JIT-Kundenstamm. Ausführlich in JIT und JIS.
3. Daraus entsteht die Lieferfälligkeit
Der JIT-Abruf allein macht noch keine Lieferung. Die Brücke ist JITH, „Abgleich JIT-Abrufe mit LAB/FAB“, Programm RJITLAB001: der Lauf gleicht die Abrufe gegen Liefer- und Feinabruf ab und erzeugt Feinabrufe im Lieferplan — begrenzt auf den Feinabrufhorizont VBLB-ABHOR zur Abrufart 2, wahlweise per Batch-Input oder über ein erzeugtes IDoc. Eingreifen lässt sich über den BAdI JIT_JITH.
Ein so erzeugter Feinabruf sieht aus wie einer aus dem EDI-Eingang, hat aber kein IDoc hinter sich. Wer ihn im Eingangsmonitor sucht, findet nichts.
4. Die Lieferung wird angelegt und geht ins Lager
Aus der Lieferfälligkeit entsteht die Auslieferung. Den Rückbezug trägt die Teilegruppe: JITIT führt VBELN_VL und POSNR_VL — darauf beruht, dass der Abruf weiß, welche Lieferung ihn erledigt. Im S/4HANA mit eingebettetem Transportmanagement kommt eine Klammer dazu: TM_CTRL_KEY am Lieferkopf entscheidet, ob der Beleg an TM übergeben wird, und TM_WHSE_EXEC hält ihn auf Wert 1 „für Lagerausführung gesperrt“, bis TM auf 2 freigibt. Geplant wird also vor der Ausführung, nicht danach.
5. EWM lagert aus
Im EWM entsteht kein Abbild der SD-Lieferung, sondern ein eigener Beleg: der Auslieferungsauftrag, Belegkategorie PDO, Tabelle /SCDL/DB_PROCH_O. Aus ihm werden Lageraufgaben abgeleitet (/SCWM/ORDIM_O), gesteuert über die Lagerprozessart (/SCWM/T333) — das Pendant zur Bewegungsart im klassischen Lager. Gearbeitet wird im Lagerauftrag: /SCWM/WHO bündelt die Aufgaben je Aktivitätsbereich. Mit der Quittierung wandern sie nach /SCWM/ORDIM_C, der Lieferkopf erreicht Wert 4 „bereit für Versand“.
Im ECC ohne EWM sitzt an derselben Stelle der Transportauftrag zur Lieferung (LT03, LTAK und LTAP). Er setzt direkt am Lieferbeleg an — ein Transportbedarf entsteht dabei nicht, der gehört zur MM- und PP-Seite.
6. ASR: ein Ladeschritt statt zwei
Der erweiterte Warenannahme- und Versandprozess ist keine Klammer um EWM und TM, sondern ein eigener Prozess im S/4HANA: Frachtauftrag und Lagerausführung teilen sich einen Lade- beziehungsweise Entladeschritt, statt ihn zweimal zu führen. Ausgeführt wird er in /SCMTMS/ASR, „Frachtaufträge laden oder entladen“.
Ob eine Lieferung dazugehört, entscheidet ein einziges Zeichen am Lieferkopf: LIKP-TM_ADV_SHIP_RECV, Datenelement /SCMTMS/ADV_SHP_RECV_RLV, zwei Festwerte — leer „Nicht relevant“, 1 „Für erweiterten Warenannahme- und Versandprozess relevant“. In meinem S/4HANA ist der Prozess an zwei Lokationen aktiv, die Relevanz steht auf acht Lieferungen der Arten LF und EL; in der Belegartentabelle der Frachtaufträge ist die ASR-Einstellung dagegen durchgängig leer. Sie kommt hier also über die Lokation, nicht über die Belegart — die erste Stelle, an der ich nachsehe, wenn der gemeinsame Ladeschritt fehlt.
7. Warenausgang, Papiere, Versand
Der Warenausgang beendet die Lagerseite: der Bestand verlässt Versandzone und Lagerort, im ECC über die WM-Bewegungsart 601 „WA Lieferschein“, sichtbar am Gesamt-Warenbewegungsstatus des Lieferbelegs. Gleichzeitig laufen die Ausgangsnachrichten: das Lieferavis an den Kunden, dazu Etiketten und Papiere an den Packstücken. Die Transportseite trägt der Frachtauftrag; aus ihm entsteht später der Frachtabrechnungsbeleg.
8. Der Hersteller rechnet ab
Im Gutschriftsverfahren stellt der Kunde das Abrechnungsdokument aus und schickt es. Beim Zulieferer kommt es im Eingang an, auf den Basistypen GSVERF01 bis GSVERF03 — in drei Ausprägungen mit je eigener Nachrichtenart und eigenem Baustein: GSVERF klassisch, SBWAP mit automatischen Buchungen und dem Eingangsmonitor VSB1N, SBINV mit Rechnungserstellung. Wer nur nach IDOC_INPUT_GSVERF sucht, findet zwei Drittel des Verfahrens nicht.
Zugeordnet wird über die Lieferscheinnummer und den Belegfluss. Findet die Verarbeitung die Lieferung nicht, bleibt der Beleg stehen — das häufigste Fehlerbild dieser Station. Und die Rechnung geht nicht mehr als eigene Ausgangsnachricht hinaus: im Gutschriftsverfahren rechnet der Kunde ab. Ob im System des Zulieferers trotzdem ein Fakturabeleg entsteht, hängt an der Variante — die klassische Verarbeitung gleicht gegen die eigenen Fakturen ab, die Variante mit Rechnungserstellung legt die Faktura aus dem Eingang an.
Was davon gilt wo
| Stufe | ECC 6.0 | S/4HANA |
|---|---|---|
| JIT-Eingang | SEQJIT / PAB_ORDERS auf SEQJIT01–03 | unverändert |
| Feinabruf aus JIT | JITH, Programm RJITLAB001 | unverändert |
| Auslagerung | Transportauftrag zur Lieferung | EWM: Auslieferungsauftrag, Lageraufgabe, Lagerauftrag |
| Transport | LE-TRA | eingebettetes TM, LE-TRA daneben |
| Gemeinsamer Ladeschritt | – | ASR (/SCMTMS/ASR) |
| Selbstabrechnung im Eingang | GSVERF01–03 | unverändert |
Und wo bleibt die elektronische Rechnung?
Die Frage ist nicht akademisch. Wer im Gutschriftsverfahren fährt, verschickt auf der Ausgangsseite keine eigene Rechnung — der Beleg, aus dem ein elektronisches Dokument werden müsste, entsteht beim Kunden. Das Rahmenwerk setzt zwingend an einem Quellbeleg an: Der Katalog der zulässigen Quellenarten führt unter anderem Debitorenrechnung, SD-Faktura, Bestellung, Auslieferung und Rechnungsprüfung, scharf gestellt wird je Buchungskreis und Quellenart.
Der Rechnungsbeleg liegt hier beim Kunden, in seiner Rechnungsprüfung — und genau dort setzt SAP an. Die Dokumentation zu einer Landeslösung beschreibt zwei getrennte Prozesse, einen je Seite: Der Käufer stellt die Rechnung im Namen seines Lieferanten aus, Quellenarten Rechnungsprüfung und Buchhaltungsbeleg, erzeugt aus der automatischen Wareneingangsabrechnung. Der Lieferant nutzt den Gegenprozess, um genau diese Selbstabrechnung zu empfangen. Für den Zulieferer heißt das: kein elektronisches Ausgangsdokument aus der Abrechnung, sein Thema ist der Eingang. Auch dafür steht für Deutschland ein eigener Prozess mit eigener Belegart bereit.
Was meine Quellen nicht hergeben, behaupte ich nicht: ob eine Selbstabrechnung im jeweiligen Land als Rechnung im Sinne der Formatvorgabe gilt, in welchem Format sie auszustellen ist und wer sie einreicht. Das steht in der nationalen Regel und in der Vereinbarung zwischen den Parteien, nicht im Customizing. Die Frage gehört an den Anfang eines Projekts: Wer stellt das Dokument aus — und schuldet damit auch seine Form?
Wo etwas zu bauen ist, deckt meine Kette den Weg vollständig ab: Rechnungsbeleg, Erzeugung des elektronischen Dokuments, Validierung gegen die formalen Vorgaben, Statusverwaltung, Fehlerbehandlung. Es endet an der letzten Meile, der Zustellung über die zugelassene Plattform — dieser Schritt ist zulassungsgebunden.
Zwei Unterrubriken
Prozesse & Knowhow
Die Stationen einzeln, mit Tabelle, Feld und Baustein — getrennt danach, was für ECC 6.0 nachgesehen und was im S/4HANA geprüft ist. In drei Gruppen:
Fehlerbilder
Diagnosen nach einem festen Raster: Symptom, Ursache, Vorgehen, Ergebnis. Genau die Störungen aus der Kette oben — der Abruf, der keinen Lieferplan findet; der JIT-Abruf, der steht, obwohl die Teile längst gefahren sind; die Selbstabrechnung, die ihre Lieferung nicht findet. Zur Übersicht
Wenn Sie an einer Station dieser Kette nicht weiterkommen: Nennen Sie mir Nachrichtenart, IDoc-Status, Meldungsnummer und Belegart. Damit lässt sich im Telefonat einordnen, wo es hängt. Erreichbar per Telefon, per E-Mail oder über das Kontaktformular.