Wissen

Fachbeiträge zur SAP-Zulieferer-Strecke

Sechs Fragen aus der Zulieferer-Strecke. Warum die Abruf-Findung Mehrdeutigkeit meldet, obwohl es nur einen Lieferplan gibt. Warum das Reset-Verfahren der Fortschrittszahlen in keiner Customizing-Tabelle steht. Was die Umstellung auf die neuen VDA-Empfehlungen im SD auslöst und was nicht.

Zwei Quellen liegen darunter, und sie bleiben hier getrennt: die VDA-Empfehlungen als Norm — Nummer, Ampelstatus, Nachfolger — und der SAP-Standard als Tabelle, Feld, Meldungsnummer, Funktionsbaustein. Wo eine Angabe aus der Norm stammt und wo aus dem System, steht jeweils dabei.

Was auf dieser Seite steht

Die Beiträge setzen den Prozess als bekannt voraus. Sie fangen dort an, wo er stehenbleibt: bei einer Meldungsnummer, bei einem Index ohne Treffer, bei einem Kennzeichen, das an einer anderen Stelle hängt als vermutet. Deshalb steht in jedem Abschnitt, wo man nachsieht. Aus Kundenprojekten steht hier nichts: keine Belegnummern, keine OEM-Guidelines, keine Konfiguration eines fremden Hauses. Beschrieben wird der SAP-Standard und die öffentlich beziehbare Norm.

Die VDA-Umstellung: was der Standard trägt und was er nicht sieht

Die VDA-Liste der Empfehlungen zum Datenaustausch (Arbeitskreis SID, Stand August 2024) führt jede Empfehlung mit einer Ampel: grün ist die aktuelle Fassung, gelb heißt abgelöst, aber weiter in Gebrauch, rot heißt nicht mehr anwendbar.

Die alten Satzarten sind damit nicht pauschal abgeschafft. Rot stehen Lieferabruf 4905, Rechnung 4906, Zahlungsavis 4907, Gutschriftanzeige 4908 und der Warenbegleitschein 4912 — bei 4906 und 4908 mit dem ausdrücklichen Zusatz, dass sie die gesetzlichen Anforderungen nicht mehr erfüllen. Gelb und laut VDA weiter verbreitet im Einsatz sind dagegen der Feinabruf 4915, die Lieferschein- und Transportdaten 4913, der produktionssynchrone Abruf 4916 und der Warenanhänger 4902.

Auf der SAP-Seite ändert der Formatwechsel zunächst nichts. SAP kennt keine VDA-Nummern; der Prozess hängt an Nachrichtenarten. Der Lieferabruf kommt als Nachrichtenart DELINS auf den Basistypen DELFOR01 und DELFOR02 herein, über den Vorgangscode DELI und den Eingangsbaustein IDOC_INPUT_DELINS_START, der IDOC_INPUT_DELINS ruft. Anwendungsobjekt ist der Lieferplan. Das gilt vor und nach der Umstellung.

Was sich ändert, ist die Feldbelegung — und die wirkt unmittelbar im SD. Drei Beispiele. Das Kundenwerk entscheidet mit darüber, ob die Lieferplanfindung eindeutig wird. Nullstellungsdatum und die dazu erreichte Fortschrittszahl kommen im Kopfsegment E1EDK09 mit (Felder CYDAT und CYEFZ) und greifen direkt in die Fortschrittszahlenführung ein. Die Abrufart steht je Position im Feld SCREL des Segments E1EDP10: 02 erzeugt einen Feinabruf, 03 und 04 einen Lieferabruf, jeder andere Wert bricht die Verarbeitung mit „ungültige Abrufart“ ab.

Ein vierter Punkt betrifft das Bis-Datum der Einteilung. Der Standard wertet es in jedem Datumstyp aus, auch im taggenauen Zweig. Ein Mapping, das das Bis-Datum nur bei Wochen- und Periodenangaben füllt, unterstellt eine Ausnahme, die es im Standard nicht gibt.

Und die Abrechnung: Rechnung und Gutschriftsanzeige sind heute in einer Empfehlung zusammengefasst, VDA 4938 (Global INVOIC). Sie hat vier Teile mit unterschiedlichem Reifegrad; produktiv ist der EDIFACT-Teil, der XML-Teil für kleinere Unternehmen stand im Stand 08/2024 noch in Überarbeitung. Die Nummer 4988 gehört nicht dazu — das ist der Zahlungsavis (REMADV).

VDA-Empfehlungen: alt und neu

Die Zuordnung, wie sie in der VDA-Liste vom August 2024 steht. Die Farbe bezieht sich jeweils auf die alte Empfehlung.

Alt	Neu
VDA 4902 Warenanhänger (Etikett, gelb)	VDA 4994 Global Transport Label (Papier)
VDA 4905 Lieferabruf (rot)	VDA 4984 Global DELFOR (EDIFACT)
VDA 4906 Rechnung (rot)	VDA 4938 Global INVOIC
VDA 4907 Zahlungsavis (rot)	VDA 4988 REMADV
VDA 4908 Gutschriftanzeige (rot)	VDA 4938 Global INVOIC
VDA 4912 DFÜ-Warenbegleitschein (rot)	VDA 4939 Sendungsbelege
VDA 4913 Lieferschein- und Transportdaten (gelb)	VDA 4987 Global DESADV; einzelne Satzarten dagegen auf VDA 4937 (RECADV) und VDA 4990 (INVRPT)
VDA 4915 Feinabruf (gelb)	VDA 4984 (DELFOR) und VDA 4985 (DELJIT)
VDA 4916 Produktionssynchrone Abrufe (gelb)	VDA 4986 (JIS mit DELJIT)
VDA 4922 Speditionsauftrag-Vordruck (rot)	VDA 4939 Sendungsbelege

Im SAP selbst findet sich zu diesen Nummern nichts. Abgebildet wird der Prozess über die Nachrichtenarten: DELINS, DELFOR und DELJIT für die Abrufe, DESADV für das Lieferavis, INVOIC für die Rechnung, REMADV für den Zahlungsavis. Wer beide Sprachen nebeneinander legt, spart sich in Abstimmungen mit dem Kunden die halbe Übersetzungsarbeit.

V4 034 und V4 035 sind zwei verschiedene Fehlerbilder

034 heißt: kein Treffer. 035 heißt: mehrere Treffer, die Findung ist nicht eindeutig. Beide setzen das IDoc auf Status 51, die Korrektur läuft aber in entgegengesetzte Richtungen.

Gesucht wird im Index VLPKM, den SAP selbst „Lieferpläne zum Kundenmaterial“ nennt; gelesen wird er über den feldgleichen View M_VLPMA. Für den Prüfweg wichtig: Die Tabelle VLPMA ohne führendes M ist etwas anderes, nämlich der Vertriebsindex der Lieferungspositionen zu Material. Sie hat mit der Abruf-Findung nichts zu tun.

Selektiert wird über Kundenmaterial, Auftraggeber, Kundenwerk, Abladestelle, Abrufverwendung und Bezeichnung. Verkaufsorganisation, Vertriebsweg, Sparte und Verkaufsbelegart stehen zwar im Schlüssel des Index, filtern aber nicht. Der Verkaufsbereich wird erst nach dem Zugriff verprobt, über die eigene Lieferantennummer im System des Kunden, hinterlegt im Kundenstamm (KNVV-EIKTO). Passt sie nicht zum Treffer, kommt V4 298; fehlt sie ganz, V4 076.

Ob Abladestelle und Bestellnummer überhaupt als Kriterium wirken, entscheidet nicht die Struktur des Index, sondern die Partnertabelle T663A mit den Kennzeichen ABLADPL und BSTNKP. Ist ABLADPL leer, wird die Abladestelle bei der Suche maskiert — sie ist dann Schlüsselfeld, aber kein Filter.

Vorgeschaltet ist die Ermittlung des Auftraggebers über T661W, gelesen mit Lieferant, Kundenwerk und Abladestelle, mit Rückfall auf leere Abladestelle. Fehlt dort der Satz, endet es bei V4 032, bevor der Index überhaupt gefragt wird. Fehlt die Sonderregel zum Auftraggeber in T663A, bei V4 033.

Eigene Beachtung verlangt 035 bei genau einem Lieferplan. Findet der genaue Zugriff nichts, wiederholt der Standard die Suche nur mit Kundenmaterial und Auftraggeber. In diesem Zweig setzt SAP den Trefferzähler bewusst auf zwei, mit dem Kommentar, ein Einzeltreffer aus dieser Notsuche könne trotzdem der falsche Lieferplan sein. Dieser Pfad endet also immer in 035, nie in einer stillen Verbuchung. Ein Abruf ohne Kundenwerk führt genau in diesen Zweig. „Es gibt doch nur einen Lieferplan“ ist deshalb kein Gegenargument, sondern die Beschreibung des Normalfalls dieses Zweigs.

Zwei weitere Ursachen sieht man der Meldung nicht an. Lieferplanpositionen mit Absagegrund fallen aus der Trefferliste und erscheinen nur noch als Warnung V4 053 — eine über VA32 abgesagte Position sieht im Index unverändert aus und erzeugt trotzdem ein 034. Und V4 078 meldet einen verwaisten Indexeintrag: Der Index nennt eine Lieferplannummer, die es im Belegkopf nicht mehr gibt.

Aufgelöst wird 035 über das Protokoll selbst. Zu jedem Treffer schreibt der Standard V4 073, 074 und 075 mit den Findungswerten — Lieferplan, Kundenmaterial, Auftraggeber, Werk, Abladestelle, Verwendungskennzeichen, Verkaufsorganisation, Vertriebsweg, Sparte, Auftragsart und Abschlussnummer.

Eine Falle beim Testen zum Schluss. Ob derselbe Abruf abbricht oder nur eine Information zeigt, hängt an der Nachrichtenversion MSGVS in T663A, gepflegt je Auftraggeber und Abladestelle. Ein Dialogtest kann deshalb unauffällig durchlaufen, während der Hintergrundlauf denselben Beleg auf Fehler setzt.

Der Fortschrittszahlen-Reset zum Jahreswechsel steht in keiner Customizing-Tabelle

Der SAP-Standard kennt vier Verfahren für das Rücksetzen der Fortschrittszahlen zum Geschäftsjahreswechsel. A setzt automatisch zurück, B setzt nicht zurück, C arbeitet mit Korrekturlieferungen, D mit Korrektur-Fortschrittszahlen aus einer eigenen Tabelle (VBKFZ), die auf die Statistik aufaddiert werden.

Wählen lässt sich das nicht im Customizing. Es gibt dafür keine Tabelle und keine IMG-Aktivität. Den Wert ermittelt der Funktionsbaustein SD_DETERMINE_FISC_YEAR_CHANGE über einen Kundenaufruf; liefert dort niemand etwas, gilt hart A. Wer B, C oder D fahren will, braucht eine Erweiterung — das ist keine Einstellung, sondern Entwicklung, mit allem, was daran hängt.

Der klassische Weg ist die SAP-Erweiterung V45L0001 mit der Komponente EXIT_SAPLV45L_004, „Rücksetzen der Lieferfortschrittszahl zum Geschäftsjahresende“; daneben steht EXIT_SAPLV45L_005 zum Stoppen des Jahreswechsels.

In S/4HANA kommt der BAdI SD_SLS_RESET_CUMLTV_QTY_SA mit der Methode RESET_CUMLTV_QTY dazu. Zwei Dinge muss man dabei wissen. Erstens akzeptiert er nur A und B: Liefert er C oder D, verwirft das Standardcoding den Wert und fällt auf A zurück. Zweitens greifen BAdI und Customer-Exit nacheinander, nicht alternativ — der Exit kommt danach und überschreibt. Beides gleichzeitig zu implementieren erzeugt Verhalten, das nur noch im Debugger erklärbar ist. Im klassischen ECC existiert dieser BAdI nicht; dort bleibt allein der Exit.

C und D schließen sich außerdem gegenseitig aus. C ist für im ERP geplante Lieferpläne vorgesehen, D für die über CIF angebundenen. Kommt das falsche Verfahren zurück, bricht die Abrufbearbeitung mit V4 335 ab.

Verwechslungsgefahr am Rand: Der BAdI ME_ME88_CQ_RESET klingt ähnlich, gehört aber zur Einkaufsseite und hat mit den vier SD-Verfahren nichts zu tun.

Welches Geschäftsjahr überhaupt gilt, entscheidet die Geschäftsjahresvariante des Warenempfängers — Partnerrolle WE, nicht Auftraggeber. Gepflegt wird sie in den allgemeinen Stammdaten des Kunden (KNA1-PERIV), nicht in den Verkaufsbereichsdaten; ob das Feld überhaupt sichtbar ist, steuert die Feldauswahl der Kontengruppe. Ist keine Variante gepflegt, nimmt SAP das Kalenderjahr des Abrufdatums. Der Jahreswechsel findet also trotzdem statt, nur zum 31. Dezember. Unterdrücken lässt er sich ausschließlich über Verfahren B.

Daneben läuft ein zweiter, davon unabhängiger Mechanismus. Der Kunde überträgt im Abruf ein eigenes Nullstellungsdatum samt der dazu erreichten Fortschrittszahl. Im Beleg sind das VBLB-CYDAT und VBLB-CYEFZ, im IDoc die gleichnamigen Felder im Kopfsegment E1EDK09.

Die laufenden Zahlen kommen dagegen positionsbezogen. E1EDP10 führt die aktuelle kumulierte erhaltene Menge (AKUEM) als Eingangsfortschrittszahl, dazu die Sollfortschrittszahl (SOLLFZ) und die Differenz (FZDIF). Im Kopf steht nur die zum Nullstellungsdatum erreichte Zahl — ein Feld, das leicht mit der laufenden Fortschrittszahl verwechselt wird.

Und eine Nebenwirkung: Die Lieferfortschrittszahl wird aus einer Infostruktur des Logistik-Informationssystems gelesen (S073). Ein Neuaufbau dieser Statistik ist damit kein reiner Auswertungsvorgang.

Feinabruf, Sequenzabruf, Mengenabruf: zwei Stränge, drei Abruftypen

Der erste Strang trägt Lieferabruf und Feinabruf. Die Nachrichtenarten DELINS, DELFOR und DELJIT sitzen alle auf denselben Basistypen DELFOR01 und DELFOR02. Registriert ist der Eingang unter der Nachrichtenart DELINS: Vorgangscode DELI, Anwendungsobjekt Lieferplan. Der EDIFACT-Feinabruf DELJIT hat im SAP-Standard keinen eigenen registrierten Eingang; er wird auf denselben Basistyp gemappt und läuft über den DELINS-Eingang mit.

Getrennt werden Lieferabruf und Feinabruf erst bei der Verarbeitung, über das Feld SCREL im Positionssegment E1EDP10: 02 setzt die Abrufart auf Feinabruf, 03 und 04 auf Lieferabruf. Ein Feld ABART kommt dagegen in keinem Segment des DELFOR-Basistyps vor — die Abrufart wird aus SCREL abgeleitet und erst im Beleg gesetzt (VBLB-ABART).

Der zweite Strang trägt den JIT-Abruf: Basistypen SEQJIT01, SEQJIT02 und SEQJIT03, verarbeitet von IDOC_INPUT_SEQJIT, Anwendungsobjekt ist der JIT-Abruf. Darauf sitzen zwei Nachrichtenarten: SEQJIT für den produktionssynchronen, sequenzierten Abruf und PAB_ORDERS für den Mengenabruf. Gleicher Basistyp, gleicher Baustein, verschiedene Nachrichtenart — mit Folgen für die Partnervereinbarung.

Fachlich unterschieden werden sie über den Abruftyp im Kopfsegment E1KSJCL, Feld ABTYP. Es gibt drei gleichrangige Werte, nicht zwei: S für den produktionssynchronen Abruf, D für den Mengenabruf, I für den internen Abruf aus dem Pufferlager. Persistent steht der Wert danach in JITHD-ABTYP. Der JIT-Kundenstamm liefert dazu nur einen Vorschlagswert; entschieden wird es je Abruf.

Nicht jeder Feinabruf kommt über EDI. Die Transaktion JITH gleicht JIT-Abrufe gegen Liefer- und Feinabruf ab (Programm RJITLAB001) und erzeugt daraus Feinabrufe, begrenzt auf den Feinabrufhorizont der Lieferplanposition. Zwei Wege stehen zur Wahl: Batch-Input auf den Lieferplan oder ein erzeugtes IDoc. Eingreifen lässt sich über den BAdI JIT_JITH, Methode HANDLE_CHANGE, der die beteiligten Tabellen vor der Erzeugung zur Änderung bekommt.

Zum Vokabular: Ein JIT-Abruf zerfällt in Teilegruppen (JITIT), jede Teilegruppe trägt ihre Abrufkomponenten (JITCO); der Kopf heißt in der deutschen Beschreibung Abrufumfang (JITHD). Jede Teilegruppe führt einen externen Status und einen internen Bearbeitungsstand — „interner Status“ ist keine SAP-Bezeichnung. Welche Aktion aus welchem Bearbeitungsstand in welchen Folgestand führt, legt das Aktionsnetz fest (Transaktion JITQ), und zwar je Abrufsteuerung.

Kein Bedarf oder keine Lieferfälligkeit: zwei Kennzeichen, zwei Fehlerbilder

Im Einteilungstyp (VOV6, Tabelle TVEP) sind das zwei voneinander unabhängige Ankreuzfelder: LFREL für die Lieferrelevanz, BEDSD für die Bedarfsübergabe. Ein drittes, ATPPR, schaltet die Verfügbarkeitsprüfung. Drei Schalter, nicht einer.

Die Symptome sind verschieden. Fehlt LFREL, steht die Einteilung nicht im Lieferfälligkeitsindex und taucht in VL10 nicht auf — ein Bedarfssatz kann trotzdem existieren. Fehlt BEDSD, entsteht kein Bedarfssatz und die Disposition sieht nichts — geliefert werden kann die Einteilung trotzdem. Im Standard sind alle vier Kombinationen der beiden Kennzeichen produktiv belegt; wäre es in Wahrheit ein Schalter, könnte es die beiden gemischten Fälle nicht geben.

Deshalb taugt das Paar CN und BN nicht als Beispiel für die Bedarfsübergabe: Beide übergeben keinen Bedarf. Sie unterscheiden sich in der Lieferrelevanz — CN ist lieferrelevant und bucht mit Bewegungsart 601, BN ist es nicht. Das Gegensatzpaar für die Bedarfsübergabe ist CN gegen CP.

Eine gefüllte Bedarfsart im Einteilungstyp beweist nichts. Sie legt nur fest, welcher Bedarf entstünde. CN trägt eine Bedarfsart und erzeugt trotzdem keinen Bedarfssatz.

Die Lieferrelevanz gibt es zudem auf zwei Ebenen: dasselbe Feld existiert am Positionstyp noch einmal. Es greift bei Positionen ohne Einteilungen. Bei Materialpositionen mit Terminen zählt der Einteilungstyp — eine Prüfung, die nur den Positionstyp ansieht, findet den Fehler nicht.

Im Lieferplan mit Abruf (Belegart LZ, Positionstyp LZN) hängt der Einteilungstyp am Dispomerkmal des Materials: ohne Dispomerkmal CP, bei nicht disponierter Ware CN, bei verbrauchsgesteuerter Disposition CV. Die Findung steht in VOV5 (Tabelle TVEPZ).

Woher die NVE kommt — und wann gar keine vergeben wird

Ob eine Handling Unit eine NVE bekommt, entscheidet nicht das Verpackungsmaterial selbst, sondern seine Packmittelart (MARA-VHART) und deren Customizing in der Tabelle TVTY. Maßgeblich ist dort das Feld NRVERG. Wert A erzeugt die achtzehnstellige Nummer schon beim Anlegen der Handling Unit. Wert B zieht dagegen nur eine Nummer aus dem Nummernkreisobjekt HU_VEKP — die HU bekommt eine Nummer und gar keine NVE. Ist das Feld leer, gibt es keine HU-Funktionalität und die Nummer ist frei vorgebbar. Die HU-Art aus derselben Tabelle wird die erste Stelle der NVE.

Nicht verwechseln mit der Materialgruppe Packmittel (MARA-MAGRV). Die steuert erlaubte Packmittel und die Packvorschriftsfindung, nicht die Nummernvergabe.

Die ILN-Basisnummer sucht der Standard kaskadierend: zuerst Werk plus Lagerort (T313Y), dann die Lagernummer (T313Z), dann das Werk allein — wieder T313Y, nur mit leerem Lagerort — und zuletzt die Mandantenebene mit leerem Werk und leerem Lagerort. T313Z ist also nicht die zweite Ebene von Werk und Lagerort, sondern der Einstieg über die Lagernummer. Gesperrte Sätze werden übersprungen; das Sperrkennzeichen setzt sich selbst, sobald das Nummernkreisintervall seine letzte Nummer ausgegeben hat. Findet die Kaskade nichts, bricht die Vergabe mit dem Hinweis auf fehlende ILN-Basisnummer und fehlendes Nummernkreisobjekt ab.

Aufgebaut ist die Nummer aus vier Teilen: HU-Art als erste Stelle, ILN-Basisnummer aus dem Customizing, laufende Nummer aus dem Nummernkreis und eine Prüfziffer nach Modulo 10.

Im Beleg lässt sich das in einem Zug prüfen. Die vergebene Nummer steht in VEKP-EXIDV, die Herkunft in VEKP-EXIDA: C für eine generierte SSCC18, E für den externen HU-Nummernkreis, A für eine interne Nummer. Damit ist die Frage, ob eine Lieferung überhaupt echte NVE trägt, beantwortet, bevor man das Avis öffnet.

Beim Avis selbst muss ein Begriff geradegerückt werden. Im Lieferavis (Basistyp DELVRY03) hängt unter dem Packstückkopf E1EDL37 genau ein Segment E1EDL38 — und das führt keine Merkmale, sondern die Bezeichnungstexte zum Packmittel: Packmittelbezeichnung, Versandelementgruppen, Versandhilfsmittelart, Materialgruppe. Wer dort Klassifizierungsmerkmale erwartet, sucht an der falschen Stelle.

Zur Sprachregelung zwischen den Systemen: Im ERP heißt das Regelwerk Packvorschrift (Tabellen PIKP und PIPO, Transaktionen POP1 bis POP3), im EWM Packspezifikation; über CIF lässt sich die ERP-Packvorschrift als EWM-Packspezifikation verteilen. PACKKP und PACKPO sind trotz des ähnlichen Klangs nicht die Packvorschrift, sondern das Packobjekt.

Und zur Norm: VDA 4994 ist kein Nachrichtenformat, sondern ein Etiketten- und Nummernstandard. Die zugehörigen Daten wandern per Lieferavis nach VDA 4987 (DESADV).

Kontakt

Wenn Ihr Fehlerbild hier nicht steht

Schreiben Sie mir Meldungsklasse, Meldungsnummer und Belegart. Mehr brauche ich für eine erste Einschätzung nicht — und mehr sollten Sie mir auch nicht schicken.

Keine Auszüge aus Ihrem System, keine Belegnummern, keine Guideline-Dokumente per Mail. Was Sie mir schreiben, behandle ich vertraulich, gebe es nicht weiter und verwende es nicht als Beispiel auf dieser Seite, solange wir das nicht ausdrücklich vereinbart haben.

Ob daraus eine kurze Antwort wird oder ein Termin, klären wir in derselben Mail.

---

Belegnachweis des Autors

• VDA-Ampel grün/gelb/rot, gelb = abgelöst, aber weiter in Gebrauch ← MESSERGEBNISSE, VDA-Abschnitt, Randnotiz: ‚Die Liste kennt drei Status: gruen (aktuelle Empfehlung), gelb (nicht mehr empfohlen, aber operativ genutzt), rot (nicht mehr anwendbar)‘
• Rot: 4905, 4906, 4907, 4908, 4912 ← MESSERGEBNISSE, Randnotiz: ‚Nur 4905 (Lieferabruf), 4906 (Rechnung), 4907 (Zahlungsavis), 4908 (Gutschrift) und 4912 (Warenbegleitschein) sind ROT‘
• Gelb und weiter verbreitet: 4913, 4915, 4916, 4902 ← MESSERGEBNISSE, Randnotiz: ‚4913 (Lieferschein), 4915 (Feinabruf), 4916 (PAB) und 4902 (Warenanhaenger) stehen 2024 ausdruecklich auf GELB mit dem Zusatz „ist noch verbreitet im Einsatz“‚
• 4906 und 4908 erfüllen die gesetzlichen Anforderungen nicht mehr ← BESTAETIGT 4938 / WIDERLEGT 4908: Bemerkung der VDA-Liste ‚Entspricht nicht mehr den gesetzlichen Anforderungen!‘ zu 4906 (S.8) und 4908 (S.10)
• 4905 → 4984 Global DELFOR (EDIFACT) ← BESTAETIGT — ‚Lieferabruf: VDA 4905 (alt) wurde durch VDA 4984 abgeloest‘, VDA-Liste 08/2024 S.7 und S.51
• 4915 → 4984 (DELFOR) und 4985 (DELJIT); 4916 → 4986 ← WIDERLEGT — ‚Feinabruf: VDA 4915 wurde durch genau eine neue Nummer ersetzt‘: zwei Nachfolger 4984 und 4985; 4916 → 4986 (VDA-Liste S.15, S.16, S.52)
• 4913 → 4987 Global DESADV; einzelne Satzarten auf 4937 (RECADV) und 4990 (INVRPT) ← BESTAETIGT — ‚Lieferschein/Lieferavis (ASN): VDA 4913 wurde durch VDA 4987 abgeloest‘, VDA-Liste S.13 satzartenscharf VG30/32 → 4937, VG35/36 → 4990, VG40 → 4987
• 4906 → 4938 Global INVOIC; 4908 → 4938 (nicht 4988) ← WIDERLEGT — ‚Gutschriftsanzeige/Selbstabrechnung: alt VDA 4908, neu VDA 4988‘: richtig ist 4938; 4988 ist der Zahlungsavis
• 4907 → 4988 REMADV ← BESTAETIGT — ‚Zahlungsavis: welche VDA-Nummer?‘, VDA-Liste S.9 und S.55
• 4912 und 4922 → 4939 Sendungsbelege ← WIDERLEGT — ‚VDA 4939 ist der Warenbegleitschein‘: 4939 ‚Sendungsbelege‘ ist Nachfolger von 4912 UND 4922 (VDA-Liste S.36, S.12, S.21)
• 4902 Warenanhänger (Etikett) → 4994 Global Transport Label ← BESTAETIGT — ‚Unterschied Warenanhaenger VDA 4902 gegenueber Global Transport Label VDA 4994‘
• VDA 4994 ist ein Etiketten-/Nummernstandard, keine Nachricht; Daten laufen per 4987 DESADV ← WIDERLEGT — ‚VDA 4994 ist eine Nachricht‘: Format ausdrücklich ‚Papier‘, Status grün; zugehörige Nachricht ist 4987
• VDA 4938 hat vier Teile; produktiv EDIFACT-Teil, XML-Teil für KMU in Überarbeitung ← MESSERGEBNISSE, Randnotiz VDA: ‚Teil 3 XML fuer KMU steht laut VDA-Liste 08/2024 noch „in Ueberarbeitung“, … produktiv ist heute der EDIFACT-INVOIC-Teil 2‘
• Quelle der VDA-Angaben: Liste des Arbeitskreises SID, Stand August 2024 ← MESSERGEBNISSE, Randnotiz VDA: ‚Liste der Empfehlungen zum Datenaustausch … Arbeitskreis SID (EDI), Stand August 2024‘
• SAP kennt keine VDA-Objekte; abgebildet über Nachrichtenarten DELINS/DELFOR/DELJIT, DESADV, INVOIC, REMADV ← UNPRUEFBAR — ‚Die VDA-Nummern lassen sich im SAP ECC verifizieren‘: Repository-Suche ‚*VDA*‘ liefert keine EDI-Empfehlungsobjekte; ‚Für die Seite‘-Satz nennt die SAP-Entsprechungen
• DELINS ist Nachrichtenart, DELFOR01/DELFOR02 sind die Basistypen ← WIDERLEGT — ‚Es gibt einen IDoc-Basistyp namens DELINS‘: EDIMSG, kein Basistyp DELINS01 in EDBAS/IDOCSYN
• Vorgangscode DELI, Baustein IDOC_INPUT_DELINS_START, der IDOC_INPUT_DELINS ruft ← BESTAETIGT/WIDERLEGT — TBD52 EVCODE DELI → IDOC_INPUT_DELINS_START; Quelltext ruft CALL FUNCTION ‚IDOC_INPUT_DELINS‘
• Anwendungsobjekt des DELFOR-Strangs ist der Lieferplan ← TBD52: EVCODE DELI, APPLOBJTYP BUS2035 (Lieferplan); Randnotiz 1 im Abschnitt Nachrichtenarten
• E1EDK09 führt CYDAT (Nullstellungsdatum der Eingangsfortschrittszahl) und CYEFZ ← BESTAETIGT — ‚E1EDK09 enthaelt das Nullstellungsdatum‘ und WIDERLEGT — ‚E1EDK09 enthaelt die Fortschrittszahl‘
• SCREL steht im Positionssegment E1EDP10; 02 = Feinabruf, 03/04 = Lieferabruf, sonst Abbruch mit ‚ungültige Abrufart‘ ← WIDERLEGT — ‚Die Abrufart (Feld SCREL) steht im Kopfsegment E1EDK09‘ und BESTAETIGT — ‚SCREL transportiert tatsaechlich die Abrufart‘ (FORM ABRUFART_ERMITTELN, VBLB-ABART 2 bzw. 1)
• Das Bis-Datum der Einteilung wird in jedem Datumstyp ausgewertet, auch im taggenauen Zweig ← BESTAETIGT — KRITIK automotive-prozesskette, Fachfehler 3: FORM DATUM_MENGE_ERMITTELN, Include LVED4F0D, EDATUB auch im Tageszweig
• V4 034 = kein Treffer, V4 035 = mehrere Treffer, beide Status 51 ← WIDERLEGT — ‚V4 034 und V4 035 bedeuten dasselbe‘: T100 ARBGB V4, MSGNR 034/035; LVED4TOP-Konstanten
• Index VLPKM ‚Lieferpläne zum Kundenmaterial‘, gelesen über View M_VLPMA ← BESTAETIGT — ‚Der Index fuer die Lieferplanfindung ueber Kundenmaterial ist die Tabelle VLPKM‘ und BESTAETIGT — ‚M_VLPMA ist fuer die Lieferplanfindung relevant‘ (DD26S: View auf VLPKM)
• VLPMA ist der Vertriebsindex der Lieferungspositionen zu Material und für die Findung irrelevant ← WIDERLEGT — ‚Der Index … ist die Tabelle VLPMA‘: DD02T ‚Vertriebsindex: Lieferungspositionen zu Material‘
• Selektionskriterien: Kundenmaterial, Auftraggeber, Kundenwerk, Abladestelle, Abrufverwendung, Bezeichnung ← WIDERLEGT — ‚Verkaufsbereich und Auftragsart sind Findungskriterien‘: WHERE-Bedingung in FORM M_CODE_SELECT (KDMAT, KUNNR, KNREF, ABLAD, ABRVW, KTEXT)
• Verkaufsorganisation, Vertriebsweg, Sparte und Verkaufsbelegart sind Schlüsselfelder, aber keine Filter ← WIDERLEGT — ‚Verkaufsbereich und Auftragsart sind Findungskriterien‘: VKORG/VTWEG/SPART/AUART kommen in der WHERE-Bedingung nicht vor, AUART nur im Protokoll V4 075
• Verprobung des Verkaufsbereichs über KNVV-EIKTO; V4 298 bei unpassendem Lieferanten, V4 076 bei fehlender Lieferantennummer ← WIDERLEGT — ‚Verkaufsbereich und Auftragsart sind Findungskriterien‘ (FORM M_CODE_TABELLE_CHECK, V4 298) und BESTAETIGT — ‚weitere V4-Meldungen‘ (V4 076)
• T663A-ABLADPL und T663A-BSTNKP entscheiden, ob Abladestelle und Bestellnummer als Kriterium wirken; leeres ABLADPL maskiert die Abladestelle ← WIDERLEGT — ‚Die Abladestelle wird bei der Lieferplanfindung immer als Kriterium herangezogen‘: LVED4F0M, CON_ANY_CHAR = ‚%‘
• Vorstufe T661W (Lieferant, Kundenwerk, Abladestelle, Fallback leere Abladestelle); fehlender Satz → V4 032 ← MESSERGEBNISSE, Randnotiz Lieferplanfindung: ‚die Vorstufe der Findung ist die Auftraggeber-Ermittlung ueber T661W … mit Fallback auf ABLAD = SPACE‘; V4 032 aus BESTAETIGT — ‚weitere V4-Meldungen‘
• V4 033: fehlende Sonderregel zum Auftraggeber in T663A ← BESTAETIGT — ‚weitere V4-Meldungen‘: V4 033 ‚Zum Auftraggeber & fehlt eine Sonderregel in T663A‘
• Fallback-Suche nur mit Kundenmaterial und Auftraggeber; Trefferzähler wird bewusst auf 2 gesetzt, deshalb immer V4 035 ← BESTAETIGT — KRITIK automotive-prozesskette, Fachfehler 2 und Randnotiz 1: FORM M_CODE_KDMAT, ‚IF ZAEHLER = 1. ZAEHLER = 2. ENDIF.‘ mit SAP-Kommentar
• Positionen mit Absagegrund fallen aus der Trefferliste, nur Warnung V4 053; per VA32 abgesagte Position sieht im Index unverändert aus ← MESSERGEBNISSE, Randnotiz Lieferplanfindung Punkt 2: ‚Lieferplanpositionen mit gefuelltem ABGRU werden aus der Trefferliste entfernt und nur als Warnung V4 053 protokolliert‘
• V4 078 meldet einen verwaisten Indexeintrag (Lieferplannummer nicht in VBAK) ← BESTAETIGT — ‚weitere V4-Meldungen‘: V4 078 ‚Index VLPKM: Gefundene Lieferplannummer & ist nicht vorhanden (VBAK)‘
• V4 073/074/075 protokollieren je Treffer Lieferplan, Kundenmaterial, Auftraggeber, Werk, Abladestelle, Verwendungskennzeichen, VkOrg, Vertriebsweg, Sparte, Auftragsart, Abschlussnummer ← BESTAETIGT — ‚weitere V4-Meldungen‘: Protokoll aller Findungswerte über V4 073/074/075
• Nachrichtenversion MSGVS in T663A (je Auftraggeber und Abladestelle) entscheidet über Dialog- gegen Hintergrundverhalten ← BESTAETIGT — KRITIK startseite, Fachfehler 1 (Teil a): T663A Schlüssel KUNNR + ABLAD, Feld MSGVS, FORM M_CODE_AUSWAHL
• Vier Reset-Verfahren für Fortschrittszahlen (A automatisch, B kein Reset, C Korrekturlieferungen, D Korrektur-Fortschrittszahlen) ← BESTAETIGT — ‚Der Standard kennt vier Reset-/Nullstellungsverfahren‘: Domäne SDLS_RESET_CDQ, ausgewertet in SD_DETERMINE_FISC_YEAR_CHANGE. Wirkung statt Domänentext beschrieben, wie in Randnotiz 1 empfohlen
• Verfahren D zieht die Tabelle VBKFZ mit Korrektur-Fortschrittszahlen, die aufaddiert werden ← MESSERGEBNISSE, Randnotiz Fortschrittszahlen Punkt 2: ‚Verfahren D zieht eine eigene Tabelle: VBKFZ … und auf S073 aufaddiert‘
• Kein Customizing für das Reset-Verfahren; ohne Erweiterung gilt hart A, ermittelt in SD_DETERMINE_FISC_YEAR_CHANGE über CALL CUSTOMER-FUNCTION 004 ← WIDERLEGT — ‚Das Reset-Verfahren wird im Customizing hinterlegt‘: ‚IF E_RESET_CDQ = SPACE. E_RESET_CDQ = A.‘
• Erweiterung V45L0001 mit EXIT_SAPLV45L_004 (Rücksetzen der Lieferfortschrittszahl zum Geschäftsjahresende) und EXIT_SAPLV45L_005 (Jahreswechsel stoppen) ← BESTAETIGT — ‚Daneben existiert ein klassischer Customer-Exit fuer dasselbe Thema‘: MODSAP/TFTIT
• BAdI SD_SLS_RESET_CUMLTV_QTY_SA mit Methode RESET_CUMLTV_QTY nur in S/4HANA, im klassischen ECC nicht vorhanden ← BESTAETIGT — ‚Es gibt einen BAdI fuer kundeneigene Logik beim Fortschrittszahlen-Reset‘: BADI_MAIN in S/4; im ECC 0 Treffer, dort nur der Customer-Exit
• Der BAdI akzeptiert nur A und B; C oder D werden verworfen und fallen auf A zurück ← BESTAETIGT — ‚Der BAdI beherrscht nur zwei der vier Verfahren‘: ‚IF e_reset_cdq <> A AND e_reset_cdq <> B. CLEAR: e_reset_cdq.‘
• BAdI und Customer-Exit greifen nacheinander; der Exit kommt danach und überschreibt ← WIDERLEGT — ‚BAdI und Customer-Exit sind alternativ‘: BAdI zuerst, danach unbedingt CALL CUSTOMER-FUNCTION 004 mit IMPORTING E_RESET_CDQ
• C nur für im ERP geplante, D nur für über CIF angebundene Lieferpläne; sonst Abbruch mit V4 335 ← WIDERLEGT — ‚Verfahren C und D sind gleichwertig einsetzbar‘: Prüfung gegen SDS_CHECK_CIF, T100 V4 335
• ME_ME88_CQ_RESET gehört zur Einkaufsseite und hat mit den vier SD-Verfahren nichts zu tun ← MESSERGEBNISSE, Randnotiz Fortschrittszahlen Punkt 4: ‚Der gehört zur MM-Seite (Transaktion ME88 …) und hat mit den vier SD-Verfahren nichts zu tun‘
• Geschäftsjahresvariante hängt am Warenempfänger (Partnerrolle WE), nicht am Auftraggeber ← BESTAETIGT — ‚Die Geschäftsjahresvariante … hängt am Warenempfänger‘: KUWEV-PERIV, FORM VBLB-GJKUN_ERMITTELN, XVBPA_LESEN USING ‚WE‘
• Gepflegt in den allgemeinen Kundenstammdaten (KNA1-PERIV), nicht in den Verkaufsbereichsdaten; gesteuert über die Feldauswahl der Kontengruppe ← BESTAETIGT — ‚Gepflegt wird die Variante im Kundenstamm … KNA1, Feld PERIV‘: KNVV hat kein Feld mit Domäne PERIV; TMODU/TMODP Feldgruppe ‚Geschäftsjahr‘
• Ohne gepflegte Variante rechnet SAP mit dem Kalenderjahr des Abrufdatums; unterdrücken nur über Verfahren B ← WIDERLEGT — ‚Ohne gepflegte Geschäftsjahresvariante findet kein Jahreswechsel statt‘: ‚VBLB-GJKUN = DA_ABRDT(4)‘
• Eigenes Nullstellungsdatum samt erreichter Fortschrittszahl aus dem Abruf: VBLB-CYDAT und VBLB-CYEFZ, im IDoc E1EDK09 ← BESTAETIGT — ‚Das Nullstellungsdatum kommt beim Kunden-Abruf per EDI mit und ist ein eigener Mechanismus‘
• Laufende Fortschrittszahlen positionsbezogen in E1EDP10: AKUEM (Eingangsfortschrittszahl), SOLLFZ, FZDIF; Kopf trägt nur CYEFZ ← WIDERLEGT — ‚E1EDK09 enthaelt die Fortschrittszahl‘: DD04T-Texte zu AKUEM/SOLLFZ/FZDIF, Kopf nur CYEFZ
• Die Lieferfortschrittszahl wird aus der LIS-Infostruktur S073 gelesen ← MESSERGEBNISSE, Randnotiz Fortschrittszahlen Punkt 3: ‚Basis der Fortschrittszahlen ist die LIS-Struktur S073 … gelesen in FORM S073_SELECT‘
• DELINS, DELFOR und DELJIT sitzen auf denselben Basistypen DELFOR01/DELFOR02 ← BESTAETIGT — ‚Den Nachrichtenarten DELINS, DELFOR, DELJIT und SEQJIT sind die Basistypen … zugeordnet‘ (EDIMSG)
• DELJIT hat im SAP-Standard keinen eigenen registrierten Eingangsstrang und läuft über den DELINS-Eingang mit ← WIDERLEGT — ‚Die Nachrichtenart DELJIT ist ein eigener Eingangsstrang mit eigenem Vorgangscode‘: kein EDIFCT-Standardeintrag, kein Vorgangscode in TBD52/TEDE2
• Das Feld ABART kommt in keinem DELFOR-Segment vor ← MESSERGEBNISSE, Randnotiz Nachrichtenarten Punkt 2: DD03L über alle ‚E1*‘-Segmente mit FIELDNAME ‚ABART‘ liefert nur E1KSJCL und fachfremde Segmente
• SEQJIT01/02/03, verarbeitet von IDOC_INPUT_SEQJIT, Anwendungsobjekt JIT-Abruf ← WIDERLEGT — ‚Der JIT-Mengenabruf laeuft unter derselben Nachrichtenart wie der Sequenzabruf‘: EDIFCT, DIRECT ‚2‘, OBJNAM BUS2150
• Zwei Nachrichtenarten auf denselben Basistypen: SEQJIT für den sequenzierten, PAB_ORDERS für den Mengenabruf ← WIDERLEGT — ‚Der JIT-Mengenabruf laeuft unter derselben Nachrichtenart wie der Sequenzabruf‘ (EDIMSG) und BESTAETIGT — KRITIK wissen, Fachfehler 1
• Abruftyp im Kopfsegment E1KSJCL, Feld ABTYP, Werte S/D/I; persistent in JITHD-ABTYP ← BESTAETIGT — ‚Der Abruftyp … steckt im IDoc selbst‘ und WIDERLEGT — ‚Der Mengenabruf ist die gleichrangige zweite Abrufart‘ (drei Festwerte der Domäne JIT_ABTYP)
• Der JIT-Kundenstamm liefert nur einen Vorschlagswert für den Abruftyp ← WIDERLEGT — ‚Der Abruftyp wird ueber ein Feld im JIT-Kundenstamm gesteuert‘ und BESTAETIGT — KRITIK automotive-prozesskette, Fachfehler 5: JITCU-VATYP = ‚Vorschlag Abruftyp‘
• Transaktion JITH, Programm RJITLAB001, erzeugt Feinabrufe innerhalb des Feinabrufhorizonts, wahlweise per Batch-Input oder erzeugtem IDoc ← FAKTEN-GEMESSEN, Abschnitt ‚Feinabruf: Herkunft entscheidet‘: TSTC/TSTCT, PERFORM batch_fab_gen, Parameter JIT_FAB_GEN, VBLB-ABHOR zu ABART ‚2‘
• BAdI JIT_JITH, Methode HANDLE_CHANGE, greift vor der Erzeugung ← FAKTEN-GEMESSEN: ‚Erweiterung: BAdI JIT_JITH, Methode HANDLE_CHANGE — bekommt Master-, Slave- und VBLB-Tabellen vor der Erzeugung zur Änderung‘
• JITIT = Teilegruppe, JITCO = Abrufkomponenten, JITHD = Abrufumfang ← BESTAETIGT — ‚Die JIT-Tabellen JITHD, JITIT und JITCO tragen Abruf, Teilegruppe und Komponenten‘ (DD02T: JITHD deutsch ‚Abrufumfang‘)
• Externer Status und interner Bearbeitungsstand; ‚interner Status‘ ist keine SAP-Bezeichnung ← WIDERLEGT — ‚Die Statusobjekte heissen interner Status und externer Status‘: CJIT02 ‚externer Status‘, CJIT04 ‚interner Bearbeitungsstand‘
• Aktionsnetz über Transaktion JITQ, je Abrufsteuerung ← BESTAETIGT — ‚Aktionsnetz ist ein echtes SAP-Objekt‘ (TSTCT JITQ ‚Aktionsnetz anzeigen‘, CJIT06/CJIT07 mit CNRTL im Schlüssel) und BESTAETIGT — ‚Abrufsteuerung … steuert das Aktionsnetz‘ (CJIT01)
• TVEP (VOV6) führt LFREL, BEDSD und ATPPR als drei getrennte Ankreuzfelder ← BESTAETIGT — ‚Lieferrelevanz und Bedarfsuebergabe des Einteilungstyps werden in Tabelle TVEP gesteuert‘
• Fehlendes LFREL: nicht im Lieferfälligkeitsindex, nicht in VL10; fehlendes BEDSD: kein Bedarfssatz ← WIDERLEGT — ‚VL10 findet die Einteilung nicht und es entsteht kein Bedarf sind dasselbe Symptom‘: VEPVG gegen VBBE
• Alle vier Kombinationen der beiden Kennzeichen sind im Standard produktiv belegt ← WIDERLEGT — dieselbe Fundstelle: Aufzählung der vier Quadranten (CP/CV…, CN/C0…, AQ/BP…, BN/BV…)
• CN und BN übergeben beide keinen Bedarf; CN ist lieferrelevant mit Bewegungsart 601, BN nicht; Gegensatzpaar ist CN gegen CP ← WIDERLEGT — ‚Die Einteilungstypen CN und BN unterscheiden sich in der Bedarfsuebergabe‘: TVEP-Vollsatz beider Einträge
• Eine gefüllte Bedarfsart erzeugt keinen Bedarf; das entscheidet allein BEDSD ← WIDERLEGT — ‚Eine gefuellte Bedarfsart im Einteilungstyp bedeutet, dass ein Bedarf uebergeben wird‘: CN mit BDART ’01‘ und BEDSD leer, null VBBE-Sätze
• Lieferrelevanz auf zwei Ebenen: Positionstyp für Positionen ohne Einteilungen, Einteilungstyp für alles mit Terminen ← WIDERLEGT — ‚Die Lieferrelevanz haengt nur am Einteilungstyp‘: TVAP-LFREL gegen TVEP-LFREL
• Lieferplan mit Abruf: Belegart LZ, Positionstyp LZN; Einteilungstyp über das Dispomerkmal (CP / CN bei ND / CV bei verbrauchsgesteuert), Findung in VOV5 (TVEPZ) ← BESTAETIGT — ‚Bei Lieferplaenen mit Abrufen sind bestimmte Einteilungstypen typisch im Einsatz‘: TVAKT LZ, TVAPT LZN, TVEPZ-Findung über MARC-DISMM
• Packmittelart MARA-VHART und TVTY-NRVERG entscheiden über die NVE; A = SSCC18 beim Anlegen der HU, B = Nummer aus HU_VEKP ohne NVE, leer = keine HU-Funktionalität ← BESTAETIGT — ‚Am Verpackungsmaterial steht, ob ueberhaupt eine NVE vergeben wird‘ samt Randnotiz 4 (‚bei NRVERG = B bekommt die HU eine Nummer aus HU_VEKP und gar keine NVE‘)
• TVTY-SSCC18 liefert die HU-Art als erste Stelle der NVE ← BESTAETIGT — dieselbe Fundstelle: ‚TVTY-SSCC18 … liefert die erste Stelle der NVE‘
• MARA-MAGRV (TVEGR) steuert erlaubte Packmittel und Packvorschriftsfindung, nicht die Nummernvergabe ← BESTAETIGT — dieselbe Fundstelle und Randnotiz 2: ‚Nur VHART/TVTY steuert die NVE-Vergabe‘
• Kaskade der ILN-Basisnummer: T313Y (Werk+Lagerort) → T313Z (Lagernummer) → T313Y ohne Lagerort → T313Y auf Mandantenebene ← BESTAETIGT — ‚Die Ermittlung der NVE-Basisnummer laeuft als Kaskade‘ (Quelltext LE_SSCC_GENERATE)
• T313Y ist Werk-/Lagerortebene, T313Z Lagernummerebene ← WIDERLEGT — ‚T313Y und T313Z haengen beide an Werk und Lagerort‘ (DD03L-Schlüssel, DD02T-Kurztexte)
• Gesperrte Sätze werden übersprungen; das Sperrkennzeichen setzt sich automatisch, wenn das Nummernkreisintervall die letzte Nummer ausgegeben hat ← BESTAETIGT — ‚Die Ermittlung der NVE-Basisnummer laeuft als Kaskade‘: DONT_USE = ‚X‘ wird ignoriert und automatisch gesetzt
• Abbruch mit Hinweis auf fehlende ILN-Basisnummer und fehlendes Nummernkreisobjekt ← BESTAETIGT — dieselbe Fundstelle: MESSAGE E022 ‚Keine ILN-Basisnummer und Nummernkreisobjekt gefunden‘ / Exception ILN_NOT_FOUND
• Aufbau der 18-stelligen NVE: HU-Art, ILN-Basisnummer, laufende Nummer, Modulo-10-Prüfziffer ← BESTAETIGT — ‚Der Aufbau der NVE/SSCC im SAP-Standard‘ (FORM SSCC_CONCATENATE, LE_CHECK_DIGIT_CALCULATION mit Methode A)
• Ergebnis in VEKP-EXIDV, Herkunft in VEKP-EXIDA (C generierte SSCC18, E externer HU-Nummernkreis, A interne Nummer) ← MESSERGEBNISSE, Randnotiz Verpackung Punkt 5: ‚Das ist ein gutes Pruefkriterium in Kundenprojekten‘
• Im Lieferavis (DELVRY03) hängt unter dem Packstückkopf E1EDL37 genau ein E1EDL38 mit Bezeichnungstexten zum Packmittel, keine Merkmale ← WIDERLEGT — ‚E1EDL38 im Lieferavis enthaelt Merkmale‘: DD02T, EDSAPPL (VEGR1_BEZ bis VEGR5_BEZ, VHART_BEZ, MAGRV_BEZ, VEBEZ), IDOCSYN-Hierarchie
• ERP: Packvorschrift (PIKP/PIPO, POP1 bis POP3); EWM: Packspezifikation; Verteilung über CIF ← BESTAETIGT — ‚Im ERP heisst es Packvorschrift, im EWM Packspezifikation‘
• PACKKP/PACKPO sind das Packobjekt, nicht die Packvorschrift ← BESTAETIGT — dieselbe Fundstelle und Randnotiz 1: ‚Fallstrick Packobjekt‘