Projekte

Fälle statt Kundenliste

Ich nenne keine Kundennamen. Auch keine, die früher öffentlich standen. Beurteilen lässt sich meine Arbeit an den Fällen unten — jeder nennt Symptom, Ursache, Tabelle und Korrektur.

Auf dieser Seite stehen sechs Fälle aus der Zulieferer-Abwicklung. Jeder folgt demselben Aufbau: Ausgangslage, Diagnose, Vorgehen, Ergebnis. Die fachlichen Angaben darin sind SAP-Standard und öffentliche Norm — Tabellen, Felder, Meldungsnummern, Nachrichtenarten, VDA-Empfehlungen. Jeder Fachleser kann sie in seinem eigenen System nachschlagen.

Was aus den Häusern selbst stammt, bleibt draußen: keine Namen, keine Stichtage, keine Werks- und Mengengerüste, keine Konfigurationsstände, nichts aus laufenden Projekten. Rolle, Zeitraum und Umfang je Mandat nenne ich im Gespräch.

Fall 1: Der Abruf kommt an, der Lieferplan bleibt leer

Ausgangslage: Ein Tier-1-Zulieferer erhielt Lieferabrufe per EDI. Die IDocs lagen im System, die Übertragung war quittiert, im Lieferplan entstanden keine neuen Einteilungen. Die Disposition plante gegen den alten Stand weiter. Im Eingang standen die Abrufe auf Status 51 mit der Meldung V4 034: kein Lieferplan gefunden. Der Lieferplan existierte, das Kundenmaterial war am Beleg gepflegt.

Diagnose: Die Eingangsverarbeitung liest nicht die Auftragsposition. Sie sucht über den Index VLPKM, im Data Dictionary „Lieferpläne zum Kundenmaterial“, gelesen über den DB-View M_VLPMA mit der Basistabelle VLPKM. Der Schlüssel dieses Index hat neben dem Mandanten elf fachliche Felder — Kundenmaterial, Auftraggeber, Kundenwerk, Abladestelle, Abrufverwendung, Verkaufsorganisation, Vertriebsweg, Sparte, Verkaufsbelegart, Lieferplan und Position. Selektiert wird aber nur mit den ersten fünf davon und der Bezeichnung. Der Verkaufsbereich wird erst nach dem Lesen des Index geprüft, über TVTA und über die Lieferantennummer beim Kunden, Feld EIKTO in KNVV. Nicht zu verwechseln ist VLPKM mit VLPMA: Letzteres ist der Vertriebsindex für Lieferungspositionen zu Material und hat mit der Lieferplanfindung nichts zu tun.

Vorgeschaltet ist die Ermittlung des Auftraggebers über T661W. Fehlt dort der Satz zu Lieferant, Kundenwerk und Abladestelle, endet der Abruf mit V4 032, bevor der Index überhaupt gelesen wird. Ob Abladestelle und Bestellnummer als Filter wirken, steuert die Partnertabelle T663A über die Kennzeichen ABLADPL und BSTNKP. Fehlt zum Auftraggeber die Sonderregel in T663A, meldet das System V4 033.

In diesem Fall war der Index verwaist. Er wird von der Belegpflege mitgeschrieben; ein Kundenmaterial, das an der Belegpflege vorbei gesetzt wurde, erzeugt keinen Eintrag. Der Beleg sah in der Anzeige vollständig aus und war für die Findung unsichtbar. Das Gegenstück dazu ist V4 078: eine Lieferplannummer, die im Index steht, aber nicht mehr im Beleg.

Vorgehen: Zuerst die Meldungsnummer sauber getrennt. V4 034 heißt kein Treffer, V4 035 heißt mehrere Treffer — dasselbe rote IDoc, gegenläufige Korrektur. Danach die Kette von hinten aufgerollt: T661W, T663A, Indexeintrag, Absagegrund. Den Indexeintrag über die Belegpflege wiederhergestellt, die fehlende Sonderregel ergänzt und den Originalabruf wiederholt statt einen konstruierten Testfall zu bauen.

Ergebnis: Die Abrufe liefen durch, die Einteilungen standen im Lieferplan. In die Betriebsdokumentation des Hauses ging, was dabei nebenher auffiel: Lieferplanpositionen mit Absagegrund fallen aus der Trefferliste und werden nur als Warnung V4 053 protokolliert — das Symptom ist ein plötzliches V4 034 ohne erkennbare Änderung am Beleg. Und fehlt das Kundenwerk im Abruf, fällt die Findung auf Kunde plus Kundenmaterial zurück; SAP setzt in diesem Zweig den Trefferzähler bewusst auf zwei. Es kommt V4 035 auch dann, wenn es nur einen Lieferplan gibt. Diese Rückfrage kommt regelmäßig aus dem Fachbereich. Auflösen lässt sich 035 über die Protokollmeldungen V4 073, 074 und 075 — dort stehen alle gefundenen Lieferpläne samt Findungswerten.

Fall 2: Nach dem Geschäftsjahreswechsel laufen die Fortschrittszahlen auseinander

Ausgangslage: Ein Kunde mit abweichendem Geschäftsjahr. Nach dem Wechsel wichen die kumulierten Mengen zwischen Kundenabruf und Lieferplan ab. Der Kunde rechnete gegen seinen Zählerstand, der Lieferant gegen den alten. Übermengen und Korrekturlieferungen waren die Folge. Zusätzlich brachen einzelne Abrufe im Nachtlauf ab, während derselbe Abruf im Dialog anstandslos durchlief.

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

Die Geschäftsjahresvariante 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 SAP mit dem Kalenderjahr des Abrufdatums; der Jahreswechsel findet also trotzdem statt, nur zum 31. Dezember.

Daneben schickt der Kunde ein eigenes Nullstellungsdatum 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, SOLLFZ als Sollfortschrittszahl und FZDIF als Differenz.

Die dritte Größe ist das Rücksetzverfahren. Der Standard kennt vier: A setzt automatisch zurück, B gar nicht, C und D sind an das Planungsumfeld gebunden — C nur für im ERP geplante Lieferpläne, D nur für über CIF an APO angebundene. Das falsche Verfahren bricht die Abrufbearbeitung mit V4 335 ab. Wichtig für die Erwartungshaltung im Projekt: Das Verfahren ist nicht customizingfähig. Ohne Erweiterung liefert der Standardbaustein immer A.

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. 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. In S/4HANA gibt es dafür zusätzlich den BAdI SD_SLS_RESET_CUMLTV_QTY_SA mit der Methode RESET_CUMLTV_QTY. Der akzeptiert allerdings nur A und B, C und D verwirft das Standardcoding wieder; außerdem läuft der klassische Exit danach und überschreibt das BAdI-Ergebnis. Beides gleichzeitig zu implementieren führt zu Verhalten, das später niemand mehr nachvollzieht. Zuletzt die Nachrichtenversion in T663A je Auftraggeber abgeglichen, damit Dialog und Nachtlauf dieselbe Nachricht gleich bewerten.

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.

Fall 3: Das Lieferavis stimmt in der Menge und nicht in der Struktur

Ausgangslage: Der Kunde konnte im Wareneingang nicht gegen die Packstücke vereinnahmen. Im eigenen System war alles grün: Lieferung gebucht, Nachricht gefunden, Nachricht versendet. Die Mengen im Avis stimmten mit der Lieferung überein.

Diagnose: Das Lieferavis überträgt die Verpackungsstruktur, nicht nur Mengen. Im Basistyp DELVRY03 steht der Packstückkopf im Segment E1EDL37, darunter hängt genau ein Segment E1EDL38 mit den Bezeichnungstexten zum Packmittel. Die Packstückpositionen führt E1EDL44, dort stehen unter anderem die externe Handling-Unit-Nummer EXIDV und die Charge. Mehrstufiges Packen ist im Standard abgebildet — die Struktur war formal gültig und inhaltlich einstufig, während der Kunde zwei Stufen erwartete.

Der zweite Auslöser lag am Packmittel. Ob überhaupt eine NVE vergeben wird, entscheidet nicht das Verpackungsmaterial selbst, sondern seine Packmittelart im Materialstamm, Feld MARA-VHART, und dazu das Customizing in TVTY. Dort steuert NRVERG die Nummernvergabe: A erzeugt beim Anlegen der Handling Unit eine SSCC18, B zieht nur eine Nummer aus dem Nummernkreisobjekt HU_VEKP und damit gar keine NVE, leer bedeutet keine HU-Funktionalität. Die eingesetzte Packmittelart war aus einer Standardart geklont, bei der die Vergabe ausgeschaltet war. Nicht zu verwechseln ist das mit MARA-MAGRV und der Tabelle TVEGR: die Materialgruppe Packmittel steuert erlaubte Packmittel und die Packvorschriftsfindung, nicht die NVE.

Die Basisnummer ist die zweite Voraussetzung. Gesucht wird kaskadierend: erst Werk plus Lagerort in T313Y, dann die Lagernummer in T313Z, dann das Werk allein, zuletzt die Mandantenebene. Die 18-stellige NVE setzt sich zusammen aus der HU-Art als erster Stelle, der ILN-Basisnummer aus dem Customizing, der laufenden Nummer aus dem Nummernkreis und einer Modulo-10-Prüfziffer.

Der dritte Auslöser betraf die Reihenfolge. Die Nachricht wird bei der Lieferungsanlage gefunden, das ist richtig so. Ob und wann sie hinausgeht, entscheiden Versandzeitpunkt und Anforderungsroutine.

Vorgehen: Packvorschrift und deren Findung so eingestellt, dass die vom Kunden erwartete Stufigkeit automatisch entsteht — angelegt über POP1, Findung über POF1 bis POF3, Stammdaten in PIKP und PIPO. Eine eigene Packmittelart mit aktiver SSCC18-Vergabe angelegt statt die Standardart weiter zu klonen. Basisnummer je Werk und Lagerort hinterlegt. Versandzeitpunkt und Anforderung so gesetzt, dass die Verarbeitung erst nach dem Warenausgang läuft. Nachgewiesen habe ich das am echten Beleg über VEKP: EXIDV trägt das Ergebnis, EXIDA die Herkunft — C für eine generierte SSCC18, E für einen externen Nummernkreis, A für eine interne Nummer.

Ergebnis: Avis mit vollständiger Packhierarchie, jede Handling Unit mit eigener NVE. Für die Abstimmung mit dem Kunden gilt außerdem: Das Global Transport Label nach VDA 4994 ist ein Kennzeichnungsstandard und keine Nachricht — die Daten wandern per Lieferavis, VDA 4987. Und wenn dieselbe Packstruktur später im EWM gebraucht wird, heißt das Objekt dort Packspezifikation; die ERP-Packvorschrift lässt sich über CIF dorthin verteilen.

Fall 4: Die Selbstabrechnung des Kunden findet die Lieferung nicht

Ausgangslage: Ein Zulieferer rechnete mit einem OEM im Gutschriftsverfahren ab. Ein Teil der eingehenden IDocs blieb im Fehler stehen, weil keine Lieferung zugeordnet werden konnte. Die Nacharbeit lief von Hand, Beleg für Beleg.

Diagnose: Das Gutschriftsverfahren hat zwei Enden. Beim Besteller entsteht die Gutschrift aus der Rechnungsprüfung — die automatische Wareneingangsabrechnung über MRRL beziehungsweise MRER, daneben die Konsignationsabrechnung MRKO und die Neubewertung MRNB — und geht als IDoc GSVERF hinaus. Beim Zulieferer kommt genau dieses IDoc im SD an und wird gegen Lieferung und Faktura abgeglichen. Die eigene Rechnung entfällt in diesem Modell; INVOIC verlässt den Zulieferer sonst als Ausgangsnachricht aus der SD-Faktura. Das Zahlungsavis REMADV kommt wiederum im Eingang an und kann den Zahlungseingang im FI ausgleichen.

Auf der Eingangsseite gibt es drei Ausprägungen. Sie teilen sich die Basistypen GSVERF01 bis GSVERF03, laufen aber unter drei getrennten Nachrichtentypen mit eigenen Vorgangscodes: GSVERF über GSVE und den Baustein IDOC_INPUT_GSVERF_START, SBWAP über SBAP und IDOC_INPUT_SBWAP, SBINV über SBII und IDOC_INPUT_SBINV_START. Nur die SBWAP-Variante legt den Eingang in eigenen Belegtabellen ab und wird über den Eingangsmonitor VSB1N gesteuert, mit Vorlauf, Hauptlauf und Wiederaufsetzen im Fehlerfall. Die beiden anderen buchen unmittelbar im SD. Wer im Repository nach IDOC_INPUT_GSVERF sucht, übersieht zwei Drittel des Verfahrens.

Die eigentliche Ursache lag in der Zuordnung. Der Eingangsbaustein sucht die Lieferung je nach Qualifier im IDoc ü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 nichts davon, bleibt das IDoc im Fehler stehen.

Vorgehen: Qualifier je Partner geklärt und mit dem Konverterhaus abgeglichen. Externe Lieferscheinnummer in der Lieferung durchgängig belegt. T665A je Kunde geprüft, einschließlich der Auftragsarten für Gutschrifts- und Lastschriftsanforderung und des Kennzeichens für die Sonderregeln Automobilfirmen, das im Standard bis in die Behandlung der externen Belegnummer wirkt. 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 vorgesehenen Beleg statt über Handarbeit. Für die Zielarchitektur war ein Punkt entscheidend: Das Verfahren ist in S/4HANA unverändert Standard — Eingangsmonitor VSB1N, Customizing ab T665B, Basistyp GSVERF03. Es fällt beim Umstieg also nicht weg.

Fall 5: Die Einteilung fehlt in der Lieferfälligkeit — oder in der Disposition

Ausgangslage: Zwei Meldungen aus demselben Haus, die im Ticket wie eine klangen. Der Versand meldete, VL10 finde bestimmte Positionen nicht. Die Disposition meldete, zu denselben Materialien entstehe kein Bedarf. Beides wurde als ein Fehler behandelt und blieb deshalb offen.

Diagnose: Es sind zwei getrennte Schalter mit zwei Datenspuren. Im Einteilungstyp, gepflegt über VOV6 in der Tabelle TVEP, steuert LFREL die Lieferrelevanz und BEDSD die Bedarfsübergabe. Fehlt LFREL, steht die Einteilung nicht im Lieferfälligkeitsindex VEPVG und taucht in VL10 nicht auf — der Bedarf kann trotzdem in VBBE stehen. Fehlt BEDSD, entsteht kein Bedarfssatz, die Einteilung ist aber lieferbar. Die Verfügbarkeitsprüfung ist mit ATPPR noch einmal ein eigenes Kennzeichen.

Die Bedarfsart im Einteilungstyp legt nur fest, welcher Bedarf entstehen würde; ob überhaupt einer entsteht, entscheidet allein BEDSD. Und die Lieferrelevanz gibt es auf zwei Ebenen: am Positionstyp in TVAP für Positionen ohne Einteilungen und am Einteilungstyp in TVEP für alles mit Terminen. Bei Materialpositionen zählt der Einteilungstyp. Wer nur den Positionstyp prüft, sucht an der falschen Stelle.

Im Lieferplan mit Abruf, Belegart LZ und Positionstyp LZN, kommt der Einteilungstyp aus der Findung in VOV5, Tabelle TVEPZ, und hängt am Dispomerkmal des Materials: CP bei plangesteuerter, CV bei verbrauchsgesteuerter und CN bei nicht disponierter Ware. CN ist lieferrelevant und arbeitet mit Bewegungsart 601, übergibt aber keinen Bedarf. Ein falsch gesetztes Dispomerkmal erzeugt so das Bild aus beiden Meldungen, obwohl die Einteilungstypfindung selbst korrekt arbeitet.

Vorgehen: Die beiden Symptome getrennt und je Symptom die zuständige Spur geprüft, VEPVG für die Lieferfälligkeit und VBBE für den Bedarf. Dispomerkmal in den betroffenen Materialstämmen korrigiert, die Einteilungstypfindung gegen die Sollbelegung abgeglichen, die vorhandenen Belege nachgezogen.

Ergebnis: Die Lieferfälligkeit war wieder vollständig, die Bedarfe standen in der Disposition. In der Betriebsdokumentation steht seitdem, welches Symptom auf welchen Schalter zeigt. Das erspart dem Haus die Diskussion, ob es sich um ein Versand- oder ein Dispositionsproblem handelt.

Fall 6: Der JIT-Abruf steht, obwohl die Teile längst gefahren sind

Ausgangslage: Bei einem Zulieferer mit produktionssynchroner Belieferung blieben Teilegruppen in einem Bearbeitungsstand hängen. Im Cockpit sah der Vorgang offen aus, in der Fertigung war er erledigt. Der Rückstand wuchs, ohne dass jemand ihn abbauen konnte.

Diagnose: Ein JIT-Abruf zerfällt in Teilegruppen, Tabelle JITIT; jede Teilegruppe trägt ihre Abrufkomponenten in JITCO, darüber steht der Abrufumfang JITHD. Jede Teilegruppe führt zwei Statusinformationen: den externen Status, den der Kunde meldet und den CJIT03 auf den SAP-Status umsetzt, und den internen Bearbeitungsstand aus CJIT04. Welche Aktion aus welchem Bearbeitungsstand in welchen Folgestand führt, legt das Aktionsnetz fest — anzeigbar über JITQ, hinterlegt in CJIT06 und CJIT07. Es gilt je Abrufsteuerung; die Abrufsteuerung selbst steht vierstellig in CJIT01 und hängt am Teilegruppentyp in JITPG. Ohne hinterlegten Übergang kommt die Teilegruppe nicht in den Folgestand.

Der Abruftyp wird nicht im Kundenstamm eingestellt. Er steht je Abruf in JITHD-ABTYP und kommt vom Kunden im Kopfsegment E1KSJCL: S für den produktionssynchronen Abruf, D für den Mengenabruf, I für den internen Abruf aus dem Pufferlager. Der JIT-Kundenstamm JITCU liefert dazu nur einen Vorschlagswert und steuert unter anderem die Teilegruppenfindung über das Findungsprofil in CJIT08. In diese Findung gehen Abladestelle und Verbauort ein, gepflegt je Kunde in JITPGD.

Vorgehen: Aktionsnetz je Abrufsteuerung aufgenommen und die fehlenden Übergänge ergänzt. Das Aktionsprotokoll eingeschaltet, das in der Abrufsteuerung ein eigenes Kennzeichen hat — ohne Protokoll diskutiert man über Vermutungen. Teilegruppenfindung über Abladestelle und Verbauort nachgezogen und gegen die Meldungen des Kunden geprüft.

Ergebnis: Die Abrufe liefen wieder bis in den Endstand durch, der Rückstand im Cockpit löste sich auf.

Zwei Trennlinien verschwimmen im Gespräch regelmäßig. Der Feinabruf ist kein JIT-Beleg: Als EDI-Eingangsnachricht läuft er über denselben Strang wie der Lieferabruf, Nachrichtenart DELINS auf den Basistypen DELFOR01 und DELFOR02, verarbeitet über den Vorgangscode DELI, der IDOC_INPUT_DELINS_START ruft und von dort an IDOC_INPUT_DELINS weiterreicht. Sequenz- und Mengenabruf laufen dagegen auf SEQJIT01 bis SEQJIT03, der sequenzierte unter der Nachrichtenart SEQJIT, der Mengenabruf unter PAB_ORDERS, beide über IDOC_INPUT_SEQJIT. Systemintern lassen sich Feinabrufe umgekehrt sehr wohl aus JIT-Abrufen erzeugen: Die Transaktion JITH gleicht JIT-Abrufe gegen Liefer- und Feinabruf ab und erzeugt Feinabrufe innerhalb des Feinabrufhorizonts, wahlweise per Batch-Input auf den Lieferplan oder über ein erzeugtes IDoc. Für eigene Logik steht dort der BAdI JIT_JITH bereit.

Von der VDA-Satzart zur Global-Serie

In jedem zweiten Projekt geht es irgendwann um die Frage, welcher VDA-Stand gilt. Die VDA führt ihre Empfehlungen mit einer Ampel: grün ist die aktuelle Empfehlung, gelb heißt nicht mehr empfohlen, aber operativ genutzt, rot heißt nicht mehr anwendbar. Der Satz „die alten VDA-Formate sind abgeschafft“ stimmt deshalb nicht. Stand der VDA-Empfehlungsliste vom August 2024:

Lieferabruf: 4905 ist rot und wurde durch 4984 abgelöst, Global DELFOR auf EDIFACT.
Feinabruf: 4915 steht auf gelb und ist weiterhin verbreitet im Einsatz; Nachfolger sind 4984 für die Lieferabruf-Anteile und 4985 für die JIT-Abrufe mit DELJIT.
Produktionssynchroner Abruf: 4916 steht auf gelb, Nachfolger ist 4986, JIS mit DELJIT.
Lieferschein- und Transportdaten: 4913 steht auf gelb, Nachfolger ist 4987, Global DESADV; einzelne Satzarten gehen dabei nicht auf 4987, sondern auf 4937 (RECADV) beziehungsweise 4990 (INVRPT).
Rechnung: 4906 ist rot, Nachfolger ist 4938, Global INVOIC.
Gutschriftsanzeige und Selbstabrechnung: 4908 ist rot und geht ebenfalls auf 4938 — Rechnung und Gutschrift teilen sich denselben Standard.
Zahlungsavis: 4907 ist rot, Nachfolger ist 4988 mit REMADV.
Warenanhänger: 4902 steht auf gelb, Nachfolger ist 4994, das Global Transport Label. Beides sind Kennzeichnungsstandards, keine Nachrichten.
Warenbegleitschein: 4912 ist rot, aufgegangen in 4939, den Sendungsbelegen als PDF-Formular; dort ist auch der alte Speditionsauftrags-Vordruck 4922 eingeflossen.

Bei 4938 lohnt der Blick auf die Teile: produktiv ist heute die EDIFACT-INVOIC-Guideline in Teil 2. Der XML-Teil für kleinere Unternehmen stand in der Liste vom August 2024 noch in Überarbeitung.

Eine SAP-Entsprechung haben diese Nummern nicht — SAP bildet die Prozesse über Nachrichtenarten und Basistypen ab: Lieferabruf und Feinabruf auf DELFOR01 und DELFOR02, JIT-Abrufe auf SEQJIT01 bis SEQJIT03, das Lieferavis auf DELVRY03, die Selbstabrechnung auf GSVERF01 bis GSVERF03. Beide Sprachen zu kennen spart in der Abstimmung mit dem Konverterhaus eine Runde Rückfragen.

Wie ich solche Fälle angehe

Zuerst die Meldungsnummer, dann der Status. V4 034 und V4 035 sehen im Monitor gleich aus und verlangen gegenläufige Korrekturen.
Die Steuerkette von hinten aufrollen: Stammdaten, Customizing-Tabelle, Index, Beleg. In der Lieferplanfindung liegen zwischen Abruf und Treffer zwei Tabellen, an denen es scheitern kann, bevor der eigentliche Index gelesen wird.
Am Originalbeleg nachstellen. Ein konstruierter Testfall trifft selten dieselbe Kombination aus Partner, Kundenwerk, Abladestelle und Abrufverwendung.
Trennen, was Customizing ist und was Entwicklung braucht. Beim Fortschrittszahlen-Reset gibt es keine Customizing-Tabelle; ohne Erweiterung gilt immer Verfahren A. Das gehört vor der Zusage geklärt, nicht danach.
Den Befund so dokumentieren, dass der nächste gleichartige Fall im Haus ohne mich läuft.

Referenzen

Wer mich beauftragt, soll sich darauf verlassen können, dass sein Name, sein Fehlerbestand und seine Systemstände nicht als Werbematerial enden.

Im Gespräch nenne ich zu jedem Mandat Rolle, Zeitraum und Umfang. Referenzkontakte gebe ich nach Rücksprache mit dem betreffenden Unternehmen weiter. Ein Profil schicke ich auf Anfrage, zugeschnitten auf die Rolle, um die es geht.

Zum Hintergrund ohne Namen: Der größere Teil meiner Arbeit steckt in der Zulieferer-Abwicklung — Lieferplan und Abruf, Lieferavis und Verpackung, Selbstabrechnung, EDI-Betrieb — inhouse wie beratend, in ECC und in S/4HANA. Davor habe ich bei einem Automobilhersteller im Logistik-Support gearbeitet: Disponenten geschult, Prozesse überwacht, Geschäftsjahreswechsel begleitet.

Kontakt

Fehlerbild schildern

Wenn Sie eines dieser Bilder wiedererkennen: Schildern Sie mir die Ausgangslage in ein paar Sätzen. Nachrichtenart, Meldungsnummer und der Zeitpunkt des ersten Auftretens genügen für einen ersten Hinweis.

Ich sage Ihnen, wo ich zuerst nachsehen würde — auch dann, wenn daraus kein Auftrag wird.

Beschreiben Sie mir Ihr Fehlerbild — Nachrichtenart, Meldungsnummer und Zeitpunkt genügen für einen ersten Hinweis.