Prozesse und Knowhow

Lieferabruf, Feinabruf, JIT- und JIS-Abruf, Fortschrittszahl, Lieferung, Packstück mit NVE, Lieferavis, Etikett, Abrechnung, Zahlungsavis — das ist die Kette, über die ein Automobilzulieferer seine OEM-Kunden beliefert und abrechnet: als EDIFACT-Nachricht nach VDA-Empfehlung beim Kunden, als IDoc im SAP. SD-Customizing und EDI-Seite in einer Hand, auf ECC 6.0 und auf S/4HANA.

Diese Rubrik geht die Kette Station für Station durch und nennt Tabellen, Felder, Bausteine und Meldungsnummern zum Nachsehen. Die SAP-Angaben sind vor der Veröffentlichung im System nachgesehen, nicht aus dem Gedächtnis geschrieben; wo eine Aussage aus der SAP-Dokumentation statt aus dem System stammt, steht es dabei. Die VDA-Nummern stammen aus der Empfehlungsliste des Verbands — dafür gibt es im SAP kein Objekt. Was sich nicht belegen ließ, steht eine Ebene abstrakter da oder gar nicht.

Im SAP stehen Nachrichtenarten, Basistypen und Vorgangscodes, keine VDA-Nummern. Nachrichtenart und Basistyp sind dabei verschiedene Ebenen: DELINS ist die Nachrichtenart, DELFOR01 und DELFOR02 sind die Basistypen — einen Basistyp DELINS gibt es nicht. Ebenso beim Lieferavis: DESADV ist die Nachrichtenart, DELVRY01 bis DELVRY07 sind die Basistypen.

Zwei Stränge im Eingang

Lieferabruf und Feinabruf teilen sich einen Eingang: die Nachrichtenarten DELINS, DELFOR und DELJIT auf den Basistypen DELFOR01 und DELFOR02, verarbeitet über den Vorgangscode DELI zum Lieferplan. Der JIT-Abruf läuft daneben als eigener Strang mit eigenem Beleg: Auf den Basistypen SEQJIT01 bis SEQJIT03 sitzen zwei Nachrichtenarten — SEQJIT für den sequenzierten und PAB_ORDERS für den Mengenabruf. Fachlich unterscheidet der Abruftyp im Kopfsegment drei gleichrangige Fälle: produktionssynchroner Abruf, Mengenabruf und interner Abruf aus dem Pufferlager.

Der Feinabruf kommt als EDI-Nachricht im Regelfall nicht über den JIT-Strang, sondern über DELINS im Lieferplan-Strang. Systemintern ist der Weg dagegen offen: Der Abgleich der JIT-Abrufe gegen Liefer- und Feinabruf (Transaktion JITH) erzeugt daraus Feinabrufe innerhalb des Feinabrufhorizonts — wahlweise per Batch-Input auf den Lieferplan oder über ein erzeugtes IDoc. Wer einen Feinabruf im System sucht und ihn im EDI-Eingang nicht findet, sollte diesen Weg mitprüfen.

Die Findung entscheidet, ob der Abruf ankommt

Die Eingangsverarbeitung liest nicht den Beleg, sondern einen Index: VLPKM, im Data Dictionary „Lieferpläne zum Kundenmaterial“, gelesen über den feldgleichen View M_VLPMA. Vorgeschaltet ist die Ermittlung des Auftraggebers über T661W; ob Abladestelle und Bestellnummer als Filter wirken, steuert die Partnertabelle T663A. Verkaufsbereich und Auftragsart stehen zwar im Schlüssel des Index, filtern aber nicht — der Verkaufsbereich wird erst nach dem Zugriff verprobt. Deshalb löst man ein Findungsproblem im Index, nicht in der Beleganzeige.

Fortschrittszahlen und Jahreswechsel

Die Fortschrittszahlen kommen positionsbezogen im Abruf an; der Kopf trägt nur die zum Nullstellungsdatum erreichte Zahl. Der Jahreswechsel richtet sich nach der Geschäftsjahresvariante des Warenempfängers, gepflegt in den allgemeinen Kundenstammdaten — fehlt sie, rechnet das System mit dem Kalenderjahr. Vier Reset-Verfahren kennt der Standard, und keines davon steht in einer Customizing-Tabelle: ohne Erweiterung gilt hart das automatische Rücksetzen. Dazu kommt das Nullstellungsdatum, das der Kunde selbst im Abruf mitschickt — ein zweiter, unabhängiger Mechanismus.

Lager, Versand und Fracht

Im klassischen Lager setzt der Kommissionierbeleg direkt an der Auslieferung an: der Transportauftrag trägt die Lieferung als Bedarf, lagert vom Bestandsplatz in die Versandzone um und wird quittiert, bevor der Warenausgang gebucht wird. Ein Transportbedarf entsteht auf diesem Weg nicht — der gehört zu den Bewegungen aus Beschaffung und Fertigung. Darunter liegt die Ordnung aus Lagernummer, Lagertyp, Lagerplatz und Quant. Im S/4HANA mit embedded EWM heißen die Belege Lageraufgabe und Lagerauftrag: die Lagerprozessart steuert, wie eine Bewegung abgewickelt wird, der Aktivitätsbereich bestimmt, zu welchem Arbeitspaket sie gebündelt wird.

Kommt embedded TM dazu, plant es vor dem Lager: aus der Lieferung entstehen die Frachtbelege — Frachteinheit und Frachtauftrag —, und aus dem Frachtauftrag wird der Frachtabrechnungsbeleg angefordert. Das Scharnier ist die Lieferung selbst: sie trägt den Steuerschlüssel für die Belegübertragung an TM und den Lagerausführungsstatus, der das Lager erst nach der TM-Planung freigibt. Ein Begriff ist dabei doppelt belegt: im klassischen Lager ist der Transportbedarf der Arbeitsvorrat für Bewegungen aus Beschaffung und Fertigung, im TM heißt so die Anfrage, aus der Frachteinheiten entstehen — und die muss dort nicht als eigener Beleg stehenbleiben. In einer Konzeptrunde kostet diese Doppelbelegung regelmäßig eine halbe Stunde.

Am Ende der Kette: Abrechnung und elektronische Rechnung

Die Rechnung verlässt den Zulieferer als Ausgangsnachricht aus der SD-Faktura; im Gutschriftsverfahren entfällt sie, weil der Abnehmer selbst abrechnet und seine Gutschrift als Eingangsnachricht schickt. Das Zahlungsavis kommt ebenfalls im Eingang an. Daneben steht die elektronische Rechnung als eigene Strecke des SAP-Standards: vom Rechnungsbeleg über die Anlage des elektronischen Dokuments, die Schnittstellenfindung, die Erzeugung der Datei und die Statusfortschreibung bis zur Übergabe an die letzte Meile. Die letzte Meile ist die Zustellung über die zugelassene Plattform; dort endet mein Anteil bewusst, weil dieser Schritt zulassungsgebunden ist.

Die Schaltstellen dieser Kette sind in meinem eigenen S/4HANA-System nachvollzogen: Aktivierung je Buchungskreis, Typfindung, Anlage des eDocuments, Schnittstellenfindung und Statusfortschreibung tragen dort jeweils eine Tabelle und ein Feld, das sich zeigen lässt. Einen Durchstich bis zur zugelassenen Plattform behaupte ich damit nicht — der Außenweg ist zulassungsgebunden und im eigenen System bewusst nicht eingerichtet.

---

Was für ECC gilt, was für S/4HANA, was für beides

Viele Zulieferer betreiben beide Releases nebeneinander, weil der Umstieg werksweise läuft. Die linke Spalte nennt, was ich im ECC 6.0 nachgesehen habe; die rechte, was sich im S/4HANA daran ändert.

Station	ECC 6.0 — nachgesehen	S/4HANA	Anmerkung
Lieferabruf und Feinabruf	Ein Eingang für beide: Vorgangscode DELI auf den Basistypen DELFOR01/02, Eingangsbaustein IDOC_INPUT_DELINS_START	gleicher Standard, kein Unterschied belegt	Die Abrufart steht je Position im Segment E1EDP10, Feld SCREL
Lieferplanfindung	Index VLPKM über den View M_VLPMA, Vorstufe T661W, Sonderregeln T663A	gleicher Standard, kein Unterschied belegt	Verkaufsbereich filtert nicht, er wird erst danach verprobt
Einteilungen	Lieferrelevanz (LFREL) und Bedarfsübergabe (BEDSD) als zwei getrennte Schalter in TVEP	gleicher Standard, kein Unterschied belegt	Zwei Schalter, zwei Fehlerbilder: Lieferfälligkeit gegen Disposition
JIT und JIS	Eigener Strang: SEQJIT und PAB_ORDERS auf SEQJIT01 bis SEQJIT03, Eingangsbaustein IDOC_INPUT_SEQJIT	Dieselben Nachrichtenarten und dasselbe Aktionsnetz — so steht es in der SAP-Dokumentation zu S/4HANA 2023	Belegt sind Struktur und Begriffe des Standards, keine laufende Strecke
Fortschrittszahlen	Vier Reset-Verfahren; eigene Logik nur über den Customer-Exit V45L0001	Dieselben vier Verfahren, zusätzlich ein BAdI (SD_SLS_RESET_CUMLTV_QTY_SA); den gibt es im ECC nicht	Der BAdI nimmt nur zwei der vier Verfahren an, der Exit läuft danach
Kommissionieren, Verpacken, NVE	NVE-Basisnummer kaskadierend aus T313Y/T313Z, Packvorschrift PIKP/PIPO	Im embedded EWM heißt dasselbe Objekt Packspezifikation; den Begriff kennt das ECC-Dictionary gar nicht	Ein Objekt, zwei Namen — die Packvorschrift wird über das Integrationsmodell ins EWM verteilt
Lieferavis	DESADV auf der DELVRY-Reihe, Packstückkopf E1EDL37	gleicher Standard, kein Unterschied belegt	E1EDL38 führt Bezeichnungstexte zum Packmittel, keine Merkmale
Etiketten und Papiere	im SAP nicht als eigenes Objekt abgebildet	Die GTL-Nummer ist im embedded EWM ein eigenes Objekt mit eigener Nummernvergabe — eine Alternative zur NVE	Normfrage: Quelle ist die VDA-Empfehlungsliste, nicht das System
Abrechnung	Drei Eingangsvarianten mit drei Bausteinen, Monitor VSB1N, Steuertabelle T665A	Unverändert Standard: VSB1N, Customizing ab T665B, Basistyp GSVERF03 — in beiden Releases nachgesehen	Hier ändert der Umstieg nichts
VDA-Formatumstellung	SAP mappt über Nachrichtenart und Basistyp, nicht über VDA-Nummern	gleicher Standard, kein Unterschied belegt	Der Formatwechsel ist zuerst eine Frage des Mappings, dann der Feldbelegung

„Gleicher Standard, kein Unterschied belegt“ heißt: Die Objekte der linken Spalte sind im ECC 6.0 nachgesehen, und an dieser Station ist mir ein Releaseunterschied weder im System noch in der SAP-Dokumentation begegnet. Wo einer belegt ist, steht er in der Zeile — erfunden ist keiner.

Unterschiede, die sich belegen lassen

• Fortschrittszahlen-Reset — im S/4HANA steht neben dem klassischen Customer-Exit ein BAdI zur Verfügung; im ECC gibt es ihn nicht. Er nimmt nur zwei der vier Verfahren an, und der Exit läuft danach — wer beides implementiert, überschreibt sein eigenes Ergebnis.
• Gutschriftsverfahren — bleibt im S/4HANA technisch unverändert Standard, mit Eingangsmonitor VSB1N, eigenem Customizing ab T665B und Basistyp GSVERF03. Es fällt beim Umstieg nicht weg.
• Logistik-Informationssystem — läuft in beiden Releases gleichermaßen, Standardanalysen und statistischer Neuaufbau eingeschlossen. Das ist mehr als eine Reportingfrage: die Lieferfortschrittszahl liegt auf der Infostruktur S073, ein Neuaufbau greift damit in die Abrufabwicklung ein.
• Präferenz und Außenhandel — im S/4HANA ist Präferenz kein SD-Thema mehr, SAP verweist auf GTS; Intrastat, Legal Control und Warentarifnummern bleiben im Kern. Die klassischen Außenhandelsobjekte liegen technisch weiter im Repository und sind nicht gesperrt — Zielarchitektur sind sie trotzdem nicht.
• Erweitertes Available-to-Promise — unter diesem Dachbegriff liefert S/4HANA mehrere eigenständige Bausteine aus: Kontingentierung, Verfügbarkeitsschutz, Rückstandsbearbeitung, Freigabe zur Lieferung und alternativenbasierte Bestätigung. Jeder bringt eigene Konfigurationsobjekte mit.
• Lager und Fracht — embedded EWM und embedded TM sind S/4HANA-Themen; embedded TM existiert im ECC nicht. Bei den Frachtkosten stehen mehrere Wege nebeneinander, und welcher passt, entscheidet sich an Kalkulationstiefe, Richtung der Fracht und Lizenz.

---

Die Stationen der Kette

• Lieferabruf und Feinabruf im Eingang — ein gemeinsamer Eingang über den Vorgangscode DELI; das Feld SCREL im Positionssegment entscheidet, ob ein Lieferabruf oder ein Feinabruf entsteht.
• Die Lieferplanfindung — Auftraggeber-Ermittlung, Index VLPKM und Verprobung des Verkaufsbereichs, Schritt für Schritt mit den zugehörigen Meldungsnummern.
• Einteilungen: lieferrelevant und bedarfswirksam — zwei getrennte Schalter im Einteilungstyp; ein sauber verbuchter Abruf erzeugt weder automatisch eine Lieferung noch automatisch einen Bedarf.
• JIT und JIS — der JIT-Abruf als eigener Beleg, mit Abrufsteuerung, Aktionsnetz und Teilegruppenfindung; darunter die drei Abruftypen produktionssynchron, Menge und intern.
• Fortschrittszahlen und Geschäftsjahreswechsel — kumulierte Mengen, Nullstellungsdatum, Geschäftsjahresvariante am Warenempfänger und die vier Verfahren zum Jahreswechsel.
• Kommissionieren, Verpacken, NVE — Handling Units und Packvorschrift, und die Frage, ob ein Packstück überhaupt eine NVE bekommt und woher die Basisnummer stammt.
• Lieferavis im Ausgang — DESADV auf der DELVRY-Reihe: welche Packstückdaten mitgehen und warum Etikett und Avis aus derselben Quelle kommen müssen.
• Etiketten und Papiere — das Global Transport Label nach VDA 4994, die GTL-Nummer neben der NVE und der Warenanhänger VDA 4902.
• Abrechnung: Rechnung, Gutschrift, Zahlungsavis — INVOIC aus der SD-Faktura, das Gutschriftsverfahren mit seinen drei Eingangswegen und das Zahlungsavis REMADV.
• VDA-Formatumstellung auf die Global-Serie — welche alte Satzart auf welche Nachricht der Global-Serie führt und warum das zuerst eine Frage des Mappings ist.

Vertiefungen

Sechs Punkte länger ausgeführt — jeweils dort, wo der Sprachgebrauch etwas zusammenzieht, was im System getrennt ist.

• Feinabruf, Sequenzabruf, Mengenabruf: zwei Stränge, drei Abruftypen — warum der Mengenabruf kein Unterfall des produktionssynchronen Abrufs ist und wo der interne Abruf hingehört.
• Kein Bedarf oder keine Lieferfälligkeit: zwei Kennzeichen, zwei Fehlerbilder — zwei Ankreuzfelder im Einteilungstyp, zwei getrennte Datenspuren.
• Der Fortschrittszahlen-Reset zum Jahreswechsel steht in keiner Customizing-Tabelle — vier Verfahren, auswählbar ist keines davon.
• Woher die NVE kommt – und wann gar keine vergeben wird — ein einzelnes Feld zur Packmittelart entscheidet, ob ein Packstück eine NVE trägt.
• Die VDA-Umstellung: was der Standard trägt und was nicht — der Formatwechsel ändert im SAP zunächst nichts; er entscheidet über die Feldbelegung.
• VDA-Empfehlungen: alt und neu im Überblick — die Zuordnung ist nicht durchgängig eins zu eins; vier Stolperstellen.

Kurzer Weg zur Antwort

Diese Rubrik erklärt den Standard: wie eine Funktion gebaut ist und woher sie ihre Werte nimmt. Wie sich derselbe Standard im Fehlerfall zeigt, steht unter Fehlerbilder — Symptom, Ursache, Vorgehen, Ergebnis.

Wenn Sie an einer Stelle dieser Kette nicht weiterkommen: Nennen Sie mir Nachrichtenart, IDoc-Status und Meldungsnummer sowie die Belegart. Damit lässt sich im Telefonat einordnen, wo es hängt und was zu prüfen ist. Erreichbar per Telefon, per E-Mail oder über das Kontaktformular.