Die Abrechnung meldet, dass ein Teil der Gutschriften des Kunden nicht ankommt. Die IDocs sind da, sie bleiben nur im Fehler stehen, weil sich keine Lieferung zuordnen lässt. Nachgearbeitet wird von Hand, Beleg für Beleg — und mit jedem Abrechnungslauf wird der Stapel größer.
Symptom
Eingehende Selbstabrechnungen bleiben im Fehler mit dem Hinweis, dass die Lieferung fehlt. Ein Teil derselben Strecke läuft unauffällig durch, was den Verdacht zuerst auf den Konverter lenkt.
Zur Einordnung: Das Gutschriftsverfahren hat zwei Enden. Beim Besteller entsteht die Gutschrift in der Rechnungsprüfung — automatische Wareneingangsabrechnung, Konsignationsabrechnung, Neubewertung — und geht als IDoc hinaus. Beim Zulieferer kommt genau dieses IDoc im SD an und wird gegen Lieferung und Faktura abgeglichen. Eine eigene Rechnung entfällt in diesem Modell.
Ursache
Die Ursache lag in der Zuordnung, nicht im Format. Der Eingangsbaustein sucht die Lieferung je nach Qualifier im IDoc auf drei Wegen: über die interne SAP-Lieferungsnummer, über die externe Lieferscheinnummer LIKP-LIFEX oder über die Konsignationsentnahme. Der Kunde meldete seine eigene Lieferscheinnummer, im Versand war LIFEX aber nicht durchgängig gefüllt.
Passt zusätzlich der Auftraggeber am gefundenen Beleg nicht zur Steuertabelle T665A, greift ein Fallback über die Lieferantennummer beim Kunden. Findet der Baustein auch damit nichts, bleibt das IDoc stehen.
Auf der Eingangsseite gibt es mehrere Ausprägungen. Sie teilen sich die Basistypen GSVERF01 bis GSVERF03, laufen aber unter getrennten Nachrichtentypen mit eigenen Vorgangscodes: GSVE führt über IDOC_INPUT_GSVERF unmittelbar in den SD-Beleg, SBAP über IDOC_INPUT_SBWAP in eigene Belegtabellen und den Eingangsmonitor VSB1N, SBII über IDOC_INPUT_SBINV_START in die Rechnungserstellung. Wer im Repository nur nach dem ersten Namen sucht, übersieht den Rest des Verfahrens.
Vorgehen
- Erst geprüft, über welchen Vorgangscode die Strecke überhaupt läuft. Davon hängt ab, ob der Fehler im Monitor sichtbar wird oder nur im IDoc-Status.
- Qualifier je Partner geklärt und mit dem Konverterhaus abgeglichen — welche Nummer der Kunde sendet und wie sie ankommt.
- Externe Lieferscheinnummer in der Lieferung durchgängig belegt, statt die fehlenden Fälle nachträglich zuzuordnen.
- T665A je Kunde geprüft, einschließlich der Auftragsarten für Gutschrifts- und Lastschriftsanforderung und des Kennzeichens für die Sonderregeln Automobilfirmen. Dieses Kennzeichen wirkt im Standard bis in die Behandlung der externen Belegnummer.
- Die Verarbeitungsvariante bewusst gewählt: Die Gutschriftsanzeige gleicht nur gegen die eigenen Fakturen ab, die Ausgleichsrechnung erzeugt bei Differenzen einen eigenen SD-Beleg.
Ergebnis
Die Gutschriften ordneten sich wieder automatisch zu. Differenzfälle liefen über den dafür vorgesehenen Beleg statt über Handarbeit in der Buchhaltung.
Für die Zielarchitektur war ein Punkt wichtig: Das Verfahren ist in S/4HANA unverändert Standard — Eingangsmonitor VSB1N, Customizing ab T665B, Basistyp GSVERF03. Es fällt beim Umstieg also nicht weg.
Die Abrechnungsstrecke im Zusammenhang steht unter Abrechnung: Rechnung, Gutschriftsverfahren, Zahlungsavis. Welche VDA-Empfehlung für Rechnung und Gutschriftsanzeige heute gilt — beide teilen sich denselben Nachfolger — steht in VDA-Empfehlungen: alt und neu. Was die Formatumstellung im SD auslöst und was nicht, beschreibt VDA-Formatumstellung auf die Global-Serie.
Weiter in dieser Rubrik
- Der Abruf kommt an, der Lieferplan bleibt leer
- Nach dem Geschäftsjahreswechsel laufen die Fortschrittszahlen auseinander
- Das Lieferavis stimmt in der Menge, nicht in der Struktur
- Die Einteilung fehlt in der Lieferfälligkeit – oder in der Disposition
- Der JIT-Abruf steht, obwohl die Teile längst gefahren sind
- V4 034 und V4 035 sind zwei verschiedene Fehlerbilder
Zurück zur Übersicht: Fehlerbilder.

