Die Selbstabrechnung des Kunden findet die Lieferung nicht

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.

Die Zulieferer-Prozesskette Prozessgrafik in zwei Bahnen. Obere Bahn von links nach rechts, sieben Stationen: Lieferabruf vom Kunden (Nachrichtenart DELINS auf Basistyp DELFOR02, Vorgangscode DELI), Lieferplan mit Einteilungen (Findung ueber den Index VLPKM, Abrufart im Feld SCREL des Segments E1EDP10), Lieferung und Kommissionierung (Lieferfaelligkeitsliste VL10, Einteilungstyp in Tabelle TVEP), Verpackung in Handling Units (NVE beziehungsweise SSCC, achtzehnstellig, gesteuert ueber die Packmittelart in Tabelle TVTY), Warenausgang mit Bewegungsart 601, Lieferavis an den Kunden (DESADV auf Basistyp DELVRY03, VDA 4987) und Faktura (INVOIC im Ausgang, VDA 4938). Am rechten Rand steht der Kunde. Von dort laeuft die untere Bahn in Gegenrichtung von rechts nach links zurueck: Gutschriftsverfahren (GSVERF im Eingang, Abgleich gegen die Faktura, VDA 4938) und Zahlungsavis (REMADV im Eingang, Ausgleich im FI, VDA 4988). Gelb markiert ist die Lieferplanfindung als Bruchstelle der Kette mit den Meldungen V4 034 und V4 035. Die Zulieferer-Prozesskette Vom Lieferabruf bis zur Abrechnung — und zurück Lieferabruf vom Kunden DELINS auf DELFOR02 Vorgangscode DELI Lieferplan und Einteilungen Findung über VLPKM SCREL in E1EDP10 Lieferung und Kommissionierung Lieferfälligkeit VL10 Einteilungstyp TVEP Verpackung in Handling Units NVE/SSCC, 18-stellig Packmittelart TVTY Warenausgang Bewegungsart 601 Lieferavis an den Kunden DESADV auf DELVRY03 VDA 4987 Faktura INVOIC im Ausgang VDA 4938 Kunde Bruchstelle der Kette — die Lieferplanfindung V4 034: kein Treffer · V4 035: nicht eindeutig Rückfluss vom Kunden Der Kunde rechnet selbst ab und avisiert die Zahlung. Beide Nachrichten laufen beim Zulieferer im Eingang. Gutschriftsverfahren GSVERF im Eingang Abgleich gegen Faktura VDA 4938 Zahlungsavis REMADV im Eingang Ausgleich im FI VDA 4988 Prozessrichtung Bruchstelle DELINS = SAP-Nachrichtenart oder Objekt
Der Rückfluss vom Kunden: Gutschriftsverfahren und Zahlungsavis laufen beim Zulieferer im Eingang.

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

Zurück zur Übersicht: Fehlerbilder.