SAP-Beratung für Automobilzulieferer und Automobilhersteller — vom Lieferabruf bis zur Gutschrift

Nach dem Geschäftsjahreswechsel laufen die Fortschrittszahlen auseinander

Kurz nach dem Geschäftsjahreswechsel meldet der Kunde Übermengen, der Versand rechnet dagegen und kommt auf einen anderen Wert. Beide Seiten haben recht: Sie zählen gegen verschiedene Anfangsstände. Was folgt, sind Korrekturlieferungen und eine Diskussion, die niemand am Beleg entscheiden kann.

Symptom

Die kumulierten Mengen im Kundenabruf und im Lieferplan weichen ab dem Wechsel voneinander ab. Der Kunde rechnet gegen seinen Zählerstand, der Lieferant gegen den alten. Dazu kommt ein zweites Bild, das den ersten Verdacht regelmäßig in die falsche Richtung lenkt: Einzelne Abrufe brechen im Nachtlauf ab, während derselbe Abruf im Dialog anstandslos durchläuft.

Ursache

An der Nullstellung hängen drei Größen, die selten zusammen betrachtet werden.

Erstens die Geschäftsjahresvariante. Sie hängt am Warenempfänger, also an der Partnerrolle WE, und wird in den allgemeinen Kundenstammdaten gepflegt (KNA1-PERIV), gesteuert über die Feldauswahl der Kontengruppe. In den Verkaufsbereichsdaten gibt es dieses Feld nicht. Fehlt die Variante, arbeitet der Standard mit dem Kalenderjahr des Abrufdatums — der Jahreswechsel findet also trotzdem statt, nur zum 31. Dezember.

Zweitens das Nullstellungsdatum des Kunden. Er schickt es samt der dazu erreichten Fortschrittszahl mit. Im IDoc stehen beide im Kopfsegment E1EDK09 als CYDAT und CYEFZ, im Beleg als VBLB-CYDAT und VBLB-CYEFZ. Die laufenden Zahlen kommen dagegen positionsbezogen: E1EDP10 führt AKUEM als Eingangsfortschrittszahl, dazu SOLLFZ und die Differenz FZDIF. Wer im Kopf die laufende Fortschrittszahl sucht, verwechselt zwei Mechanismen.

Drittens das Rücksetzverfahren. Der Standard kennt vier: A setzt automatisch zurück, B gar nicht, C und D sind an das Planungsumfeld gebunden — C für im ERP geplante Lieferpläne, D für die über CIF angebundenen. Das falsche Verfahren bricht die Abrufbearbeitung mit V4 335 ab.

Das Verfahren ist nicht customizingfähig. Es gibt dafür keine Tabelle und keine IMG-Aktivität. Ohne Erweiterung liefert der Standardbaustein immer A. Das gehört vor der Zusage geklärt, nicht danach.

Fortschrittszahlen zum Geschäftsjahreswechsel Entscheidungsgrafik zum Rücksetzen der Fortschrittszahlen im Lieferplan. Schritt 1: Das Geschäftsjahr des Kunden richtet sich nach der Geschäftsjahresvariante des Warenempfängers, Partnerrolle WE, Feld KNA1-PERIV in den allgemeinen Stammdaten, nicht nach der des Auftraggebers; ist keine Variante gepflegt, gilt das Kalenderjahr des Abrufdatums und der Jahreswechsel findet trotzdem statt. Schritt 2, gelb hervorgehoben als Falle: Das Reset-Verfahren ist nicht customizingfähig, es gibt keine Customizing-Tabelle und keine IMG-Aktivität; den Wert liefert allein der Baustein SD_DETERMINE_FISC_YEAR_CHANGE, und ohne Erweiterung setzt der Standard hart Verfahren A. Zwei Erweiterungswege: klassisch in ECC und S/4HANA die SAP-Erweiterung V45L0001 mit EXIT_SAPLV45L_004 für das Verfahren und EXIT_SAPLV45L_005 zum Stoppen des Jahreswechsels, die alle vier Verfahren setzen kann; nur in S/4HANA zusätzlich der BAdI SD_SLS_RESET_CUMLTV_QTY_SA mit der Methode RESET_CUMLTV_QTY, der nur A und B annimmt, weil C und D vom Standard verworfen werden. Sind beide implementiert, liefert der BAdI den Vorschlag und die Erweiterung überschreibt ihn. Die vier Verfahren des Standards: A automatisches Rücksetzen zum Jahreswechsel als Standard-Verhalten, B kein Rücksetzen, C kein Jahreswechsel mit Nullstellung über Korrekturlieferungen nur für im ERP geplante Lieferpläne, D Geschäftsjahr von außen mit Reset über Korrektur-Fortschrittszahlen nur für APO- beziehungsweise CIF-geplante Lieferpläne. C und D schließen sich gegenseitig aus; das falsche Verfahren führt zum Abbruch mit Meldung V4 335. Als zweiter Mechanismus neben der Variante sendet der Kunde ein eigenes Nullstellungsdatum im Abruf, IDoc-Segment E1EDK09. Fortschrittszahlen zum Geschäftsjahreswechsel Welches Reset-Verfahren greift — und wo es gesetzt wird 1 Geschäftsjahr des Kunden ermitteln Maßgeblich ist die Geschäftsjahresvariante des Warenempfängers. Partnerrolle WE, Feld KNA1-PERIV in den allgemeinen Stammdaten. Die Variante des Auftraggebers ist nicht maßgeblich. Wenn keine Variante gepflegt ist Dann gilt das Kalenderjahr des Abrufdatums. Der Jahreswechsel findet trotzdem statt — abschalten lässt er sich nur über Verfahren B. 2 Das Reset-Verfahren ist nicht customizingfähig Keine Customizing-Tabelle, keine IMG-Aktivität: den Wert liefert allein der Baustein SD_DETERMINE_FISC_YEAR_CHANGE. Kommt von dort kein Wert, setzt der Standard hart A — ohne Erweiterung ist am Jahreswechsel nichts steuerbar. KLASSISCH · ECC UND S/4HANA Erweiterung V45L0001 EXIT_SAPLV45L_004 setzt das Verfahren. EXIT_SAPLV45L_005 stoppt den Jahreswechsel. Setzt alle vier Verfahren. NUR S/4HANA BAdI SD_SLS_RESET_CUMLTV_QTY_SA Methode RESET_CUMLTV_QTY. Im klassischen ECC gibt es diesen BAdI nicht. Nimmt nur A und B an, C und D verwirft der Standard. Beides implementiert? Der BAdI liefert den Vorschlag, die Erweiterung V45L0001 überschreibt ihn. Die vier Verfahren, die der Standard kennt A Automatisch Fortschrittszahlen werden zum Jahreswechsel auf null gesetzt. Standard-Verhalten. B Kein Reset Kein Rücksetzen zum Jahreswechsel, die Zahlen laufen weiter. C Korrekturlieferungen Kein Jahreswechsel — die Fortschrittszahlen gehen trotzdem auf null. Nur im ERP geplant. D Korrektur-FZ Geschäftsjahr kommt von außen, Reset über Korrektur-Fortschrittszahlen. Nur APO/CIF-geplant. C und D schließen sich gegenseitig aus Falsches Verfahren: Abbruch mit Meldung V4 335. Zweiter Mechanismus: Nullstellungsdatum Der Kunde sendet es im Abruf mit — IDoc-Segment E1EDK09.
Welches Rücksetzverfahren am Geschäftsjahreswechsel greift — und an welcher Stelle es gesetzt wird.

Der Unterschied zwischen Dialog und Hintergrund war kein Zufall. Über die Nachrichtenversion MSGVS in T663A, gepflegt je Auftraggeber und Abladestelle, entscheidet sich, ob dieselbe Prüfung als Information oder als Fehler ausgegeben wird.

Vorgehen

  • Geschäftsjahresvariante am Warenempfänger geprüft und gesetzt — nicht am Auftraggeber.
  • Das Rücksetzverfahren als fachliche Entscheidung dokumentiert und dort verankert, wo der Standard es vorsieht: in der SAP-Erweiterung V45L0001, Komponente EXIT_SAPLV45L_004. Zum Stoppen des Jahreswechsels steht daneben EXIT_SAPLV45L_005.
  • Nachrichtenversion MSGVS in T663A je Auftraggeber abgeglichen, damit Dialog und Nachtlauf dieselbe Meldung gleich bewerten.

Für S/4HANA kommt ein Punkt dazu, der leicht zu einem zweiten Fehlerbild wird. Dort gibt es zusätzlich den BAdI SD_SLS_RESET_CUMLTV_QTY_SA mit der Methode RESET_CUMLTV_QTY. Er akzeptiert nur A und B; C und D verwirft das Standardcoding wieder. Außerdem greifen BAdI und Customer-Exit nacheinander, nicht alternativ — der Exit kommt danach und überschreibt. Beides gleichzeitig zu implementieren erzeugt Verhalten, das später niemand mehr nachvollzieht.

Ergebnis

Die Zählerstände stimmten auf beiden Seiten überein, der Stichtagslauf lief im Hintergrund durch. Ein Punkt kam ausdrücklich in die Betriebsanleitung: Die Fortschrittszahlen liegen auf der LIS-Struktur S073. Wer diese Infostruktur neu aufbaut, greift damit in die Abrufabwicklung ein und nicht nur ins Reporting.

Die Station im Zusammenhang beschreibt Fortschrittszahlen und Geschäftsjahreswechsel. Warum das Rücksetzverfahren Entwicklung ist und keine Einstellung, steht ausführlich in Der Fortschrittszahlen-Reset steht in keiner Customizing-Tabelle. Wo die Felder im Abruf herkommen, steht unter Lieferabruf und Feinabruf im Eingang.

Weiter in dieser Rubrik

Zurück zur Übersicht: Fehlerbilder.