Lieferabruf (LAB) und Feinabruf (FAB) teilen sich im SAP-Standard einen Eingang. Der Feinabruf gehört dabei nicht zum JIT-Strang — er kommt über dieselbe Strecke herein wie der Lieferabruf und landet in derselben Lieferplaneinteilung. Diese Seite beschreibt, wie dieser Eingang aufgebaut ist: welcher Baustein wirklich der Einstiegspunkt ist, woran das System Lieferabruf und Feinabruf unterscheidet und welche Felder im IDoc die Verarbeitung tragen.
Nachrichtenart, Basistyp, Vorgangscode
Im SAP stehen Nachrichtenarten, Basistypen und Vorgangscodes, keine VDA-Nummern. Auf der Abrufseite hängen die Nachrichtenarten DELINS, DELFOR und DELJIT an den Basistypen DELFOR01 und DELFOR02. Den Eingang trägt im Standard die Nachrichtenart DELINS: Vorgangscode DELI, Baustein IDOC_INPUT_DELINS_START, Anwendungsobjekt BUS2035 (Lieferplan). Kommt ein Abruf als DELFOR oder DELJIT herein, lohnt der erste Blick in die Bausteinzuordnung — dort steht dann in aller Regel ein Add-on-Baustein und nicht der Standard.
| Ebene | Wert |
|---|---|
| Nachrichtenart | DELINS, DELFOR, DELJIT |
| Basistyp | DELFOR01, DELFOR02 |
| Vorgangscode Eingang | DELI |
| Anwendungsobjekt | BUS2035 (Lieferplan) |
Nachrichtenart und Basistyp sind verschiedene Ebenen, und die Begriffe werden in Guidelines und Tickets regelmäßig vermischt. DELINS ist die Nachrichtenart, DELFOR01 und DELFOR02 sind die Basistypen — einen Basistyp DELINS gibt es nicht.
Der Einstiegspunkt heißt IDOC_INPUT_DELINS_START
Der Vorgangscode DELI ruft IDOC_INPUT_DELINS_START. Dieser Baustein übergibt eine lokale Kopie der IDoc-Daten an IDOC_INPUT_DELINS und übernimmt danach Workflow-Ergebnis und Kunden-Exit. Als ALE-Eingangsbaustein registriert ist nur der Start-Baustein.
Eine Suche allein nach IDOC_INPUT_DELINS führt am Einstiegspunkt vorbei. Wer dort einen Breakpoint setzt, sieht die Verarbeitung, aber nicht die Stelle, an der sie beginnt.
Lieferabruf oder Feinabruf: das Feld SCREL entscheidet
Ob ein Abruf als Lieferabruf oder als Feinabruf verbucht wird, entscheidet das Positionssegment: Feld SCREL in E1EDP10. Der gebuchte Wert steht anschließend im Abruf als VBLB-ABART.
| E1EDP10-SCREL | Ergebnis | VBLB-ABART |
|---|---|---|
| 02 | Feinabruf | 2 |
| 03 | Lieferabruf | 1 |
| 04 | Lieferabruf | 1 |
| jeder andere Wert | Abbruch: ungültige Abrufart | – |
Die Domäne von SCREL hat keine Festwerte; die gültigen Werte stehen im ABAP-Coding. Das ist der Grund, warum die Frage nach der erlaubten Belegung eines Mappings sich nicht aus dem Data Dictionary beantworten lässt.
Kopf, Position, Einteilung
Der Kopf E1EDK09 kommt genau einmal, darunter bis zu 9999 Positionen E1EDP10. Im Kopf stehen die kaufmännischen Rahmendaten des Abrufs:
- ABRVW — Verwendungskennzeichen
- LABNK — Lieferabruf-/Feinabrufnummer des Kunden
- CYDAT — Datum der Nullstellung der Eingangsfortschrittszahl
- CYEFZ — die dazu erreichte Fortschrittszahl
- BSTDK — Bestelldatum des Kunden; das ist das Datum, mit dem der Inbound als Abrufdatum rechnet
In der Position liegen die operativen Fortschrittszahlen AKUEM, SOLLFZ und FZDIF, dazu Kundenmaterial (IDNKD), Kundenwerk (KWERK), Abladestelle, Gültigkeitszeitraum (ABRAB, ABRBI), Nullstellungsdatum NULDT und Feinabrufhorizont (ABHOR).
Die Einteilungen kommen in E1EDP16. Das Bis-Datum EDATUB wertet der Standard in jedem Datumstyp aus, auch im taggenauen Zweig.
Feinabruf auch ohne EDI
Den Feinabruf gibt es außerdem systemintern, ohne Nachricht des Kunden: JITH („Abgleich JIT-Abrufe mit LAB/FAB“, Programm RJITLAB001) erzeugt Feinabrufe, sofern das Ladedatum innerhalb des Feinabrufhorizonts VBLB-ABHOR zur Abrufart 2 liegt. Eingreifen kann man über den BAdI JIT_JITH, Methode HANDLE_CHANGE.
Wichtig für die Fehlersuche: Der Standardweg schreibt dazu selbst ein Eingangs-IDoc — Basistyp DELFOR01, Nachrichtenart DELINS, im Positionssegment SCREL = 02 — und schickt es über die Partnervereinbarung durch denselben Eingang wie einen echten Kundenabruf. Ein IDoc ist also da, nur kein Absender außerhalb. Ganz ohne IDoc arbeitet nur der Batch-Input-Zweig, den der Benutzerparameter JIT_FAB_GEN mit dem Wert NOIDOC einschaltet.
Zwei Symptome und ihre Stelle
| Gemeldetes Symptom | Wo ich zuerst nachsehe |
|---|---|
| Ungültige Abrufart | E1EDP10-SCREL |
| Im Dialog grün, im Nachtlauf bleibt er stehen | Nachrichtenversion MSGVS in T663A |
Ich fange am Beleg an. Partnervereinbarung, Vorgangscode und Nachrichtensteuerung werden am konkreten IDoc nachvollzogen, und ein Fehlerbild wird an einem funktionierenden Beleg gespiegelt: Was steht in der grünen Strecke anders als in der roten. Getestet wird über den echten Weg — Abrufe entstehen als IDoc über die Partnervereinbarung, kein Direktschreiben in die Abruftabellen.
Bleibt ein Abruf trotz sauberem Segmentaufbau stehen, sitzt die Ursache meist eine Stufe weiter: in der Lieferplanfindung. Was aus einem verbuchten Abruf eine Lieferung oder einen Bedarf macht, steht unter Einteilungen.
Kommen Sie an dieser Stelle nicht weiter: Nennen Sie mir Nachrichtenart, IDoc-Status und Meldungsnummer sowie den betroffenen Beleg. Damit lässt sich im Telefonat einordnen, wo es hängt und was zu prüfen ist.