Sie sind auf Seite 1von 234

IDoc-Schnittstelle: EDI-

Szenarien der Anwendung (BC-


SRV-EDI)

HELP.BCSRVEDISC

Release 4.6C
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG

Copyright

© Copyright 2001 SAP AG. Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem
Zweck und in welcher Form
auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In
dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert
werden.

Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können Software-
Komponenten auch anderer Software-Hersteller enthalten.
® ® ® ® ® ® ®
Microsoft , WINDOWS , NT , EXCEL , Word , PowerPoint und SQL Server sind eingetragene
Marken der
Microsoft Corporation.
® ® ® ® ® ® ® ® ®
IBM , DB2 , OS/2 , DB2/6000 , Parallel Sysplex , MVS/ESA , RS/6000 , AIX , S/390 ,
® ® ®
AS/400 , OS/390 und OS/400 sind eingetragene Marken der IBM Corporation.
®
ORACLE ist eine eingetragene Marke der ORACLE Corporation.

® ® TM
INFORMIX -OnLine for SAP und Informix Dynamic Server sind eingetragene Marken der
Informix Software Incorporated.
® ® ® ®
UNIX , X/Open , OSF/1 und Motif sind eingetragene Marken der Open Group.
®
HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C , World Wide
Web Consortium,
Massachusetts Institute of Technology.
®
JAVA ist eine eingetragene Marke der Sun Microsystems, Inc.
®
JAVASCRIPT ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der
Lizenz der von Netscape entwickelten und implementierten Technologie.

SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow,
SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo und mySAP.com
sind Marken oder eingetragene Marken der SAP AG in Deutschland und vielen anderen Ländern
weltweit. Alle anderen Produkte sind Marken oder eingetragene Marken der jeweiligen Firmen.

2 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)

Symbole

Symbol Bedeutung
Achtung

Beispiel

Empfehlung

Hinweis

Syntax

Tip

April 2001 3
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG

Inhalt

IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) ............................ 7


Technische Realisierung der Szenarien ....................................................................................................8
Allgemeine Beispieldaten............................................................................................................................9
Anfrage (MM-PUR-RFQ).............................................................................................................................13
EDI-Ausgang einer Anfrage (MM-PUR-RFQ) .......................................................................... 14
Angebot (SD-LS).........................................................................................................................................16
EDI-Versand eines Angebots (SD-SLS) .................................................................................. 17
Bestellung/Auftrag (MM-PUR-PO, SD-SLS-SO).......................................................................................19
EDI-Versand einer Bestellung (MM-PUR-PO) ......................................................................... 20
EDI-Eingang des Auftrags (SDS-SLS-SO) .............................................................................. 22
Auftragsbestätigung (SD-SLS, MM-PUR-GF-CON) ................................................................................23
EDI-Versand einer Bestellbestätigung (SD-SLS) ................................................................... 24
EDI-Eingang einer Auftragsbestätigung (MM-PUR-GF-CON) ............................................... 26
Bestelländerung (MM-PUR-PO).................................................................................................................28
EDI-Ausgang einer Bestelländerung (MM-PUR-PO) .............................................................. 29
EDI-Eingang der Bestelländerung (SD-SLS) .......................................................................... 31
Lieferabruf (MM-PUR-OA-SCH, SD-SLS-OA-SCH) ..................................................................................33
EDI-Versand eines Lieferabrufs (MM-PUR-OA-SCH) ............................................................. 34
EDI-Eingang eines Lieferabrufs (SD-SLS-OA-SCH).............................................................. 37
Beispieldaten (SD-SLS-OA-SCH) ...........................................................................................................39
Lieferavis zum Lieferplan (SD-SHP-DL, MM-PUR-GF-CON)...................................................................40
EDI-Versand eines Lieferavis (SD-SHP-DL)............................................................................ 42
Beispieldaten (SD-SHP-DL)....................................................................................................................44
EDI-Eingang eines Lieferavis (MM-PUR-GF-CON) ................................................................. 45
Beispieldaten (MM-PUR-GF-CON).........................................................................................................47
Versandauftrag (SD-EDI-OM) ....................................................................................................................48
Versandbestätigung (SD-EDI-IM)..............................................................................................................49
Transport (LE-TRA-TP) ..............................................................................................................................50
EDI-Versand eines Transportbelegs (LE-TRA-TP) ................................................................. 52
EDI-Eingang eines Transportbelegs (LE-TRA-TP) ................................................................. 55
Rechnungsprüfung (MM-IV) ......................................................................................................................57
EDI-Eingang einer Rechnung (MM-IV)..................................................................................... 58
Gutschriftsverfahren bei Lieferplänen (MM-IV-LIV, SD-SLS-OA-SCH) .................................................60
EDI-Versand eines ERS-Belegs (MM-IV-LIV) .......................................................................... 62
EDI-Eingang der externen Rechnung (SD-SLS-OA-SCH) ..................................................... 65
Zahlungsavis (FI-AP-AP-PT, FI-AP-AP-P) ................................................................................................67
EDI-Versand eines Zahlungsavis (FI-AP-AP-PT).................................................................... 68
EDI-Eingang eines Zahlungsavis (FI-AR-AR-P)...................................................................... 70
Beispieldaten (FI-AR-AR-P) ....................................................................................................................72
EDI-Eingang eines Kontoauszugs (FI-BL-PT-BS) ...................................................................................73
EDI-Eingang von Lockbox-Daten (FI-BL-PT-LB) .....................................................................................77
EDI-Versand von Zahlungen (FI-AP-AP-PT) ............................................................................................80

4 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)

Qualitätszeugnis (QM-CA) .........................................................................................................................83


EDI-Versand eines Qualitätszeugnisses im PDF-Format (QM-CA) ...................................... 84
EDI-Eingang eines Qualitätszeugnisses im PDF-Format (QM-CA) ...................................... 86
EDI-Versand eines Qualitätszeugnisses mit Datenzugriff (QM-CA)..................................... 88
EDI-Eingang eines Qualitätszeugnisses mit Datenzugriff (QM-CA)..................................... 93
Vendor-Managed-Inventory (VMI).............................................................................................................96
VMI: Senden von Bestands- und Abverkaufsdaten ............................................................... 99
VMI: Empfangen von Bestands- und Abverkaufsdaten ...................................................... 100
VMI: Nachschubplanung für Kunden .................................................................................... 102
Nachschub: Artikelstammdaten für externe Kunden.............................................................................104
VMI: Generieren Bestellung zu EDI-Bestellbestätigung...................................................... 106
MM MM-MOB- und WM-LSR-Schnittstellen ...........................................................................................108
Schnittstelle zwischen Fremdsystem und SAP-Logistikmodul ......................................... 109
Funktionen.............................................................................................................................................110
Partnerkonzept......................................................................................................................................111
Technik..................................................................................................................................................112
Zertifizierungsanforderung ....................................................................................................................113
Schnittstelle WM-LSR - Minimalvoraussetzung ....................................................................................114
Schnittstelle MM-MOB - Minimalvoraussetzung ...................................................................................115
Zuordnung von IDoc zu Schnittstelle ....................................................................................................116
Szenarios: Mobile Datenerfassung in der Lagerlogistik ..................................................... 117
Wareneingang Fremdsystem in Bestandsführung................................................................................118
Einlagerung aus Produktion in die Bestandsführung............................................................................119
Einlagerung aus Produktion in die Lagerverwaltung ............................................................................120
Einlagerung im WM mit manueller Lagerplatzvergabe .........................................................................121
Nachschub-TA für die Produktion .........................................................................................................122
Erfassen von Inventurzähldaten ohne WM (offline) ..............................................................................123
Erfassen von Inventurzähldaten mit dem WM ......................................................................................124
Rückmelden Verpackungen an SD.......................................................................................................125
Anbinden von Kommissioniersystemen ................................................................................................126
Buchen von Wareneingängen und Warenausgängen mit Wiegemengen............................................127
Szenarios: Lagersteuerrechner Anbindung ......................................................................... 128
Manuelles Lager: Szenario 1 ................................................................................................................131
Halbautomatisches Lager: Szenario 2 ..................................................................................................133
Vollautomatisches Lager: Szenario 3 ...................................................................................................135
Vollautomatisches Lager - Blackbox: Szenario 4..................................................................................139
Schnittstelle zu einem WM-Fremdsystem Szenario 5 ..........................................................................142
WM-Schnittstelle zu Nicht-Lagersystemen ...........................................................................................144
Datenfluß: Technische Beschreibungen .............................................................................. 145
Senden von Transportaufträgen ...........................................................................................................146
Empfangen von Transportaufträgen .....................................................................................................149
Programmtechnische Realisierung .......................................................................................................151
Senden von IDocs an ein Fremdsystem..........................................................................................152
TCP/IP-Einstellungen.......................................................................................................................154
Senden von IDocs vom Fremdsystem an SAP................................................................................155
Verwaltung von Transaktionsidentifikatoren (TID)...........................................................................157
Datenaufbereitung.................................................................................................................................159
Übergabe-Formate der Daten ...............................................................................................................163
Beschreibung der IDocs ......................................................................................................... 164

April 2001 5
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG

Warenbewegungen ...............................................................................................................................166
Rückmeldung von Versandelementdaten .............................................................................................174
Beispiel: Struktur für Rückmeldungen .............................................................................................177
Senden von Kommissionieraufträgen ...................................................................................................180
Rückmeldung Kommissionierauftrag an Lieferung ...............................................................................183
Beispiel: Verpackung .......................................................................................................................185
Transportaufträge..................................................................................................................................187
Quittieren von Transportaufträgen...................................................................................................193
Stornieren von Transportaufträgen..................................................................................................199
Freigabe von Gruppen .....................................................................................................................202
Sperren von Lagerplätzen................................................................................................................203
Erzeugen / Stornieren von Transportbedarfen......................................................................................205
Erzeugen von Transportbedarfen ....................................................................................................208
Stornieren von Transportbedarfen...................................................................................................209
Bewegen von Lagereinheiten................................................................................................................210
Inventur in der Lagerverwaltung............................................................................................................212
Allgemeine Informationstexte................................................................................................................214
SAP-Systemeinstellungen und Modifikationskonzept ........................................................ 215
Aktivieren der Fehlerbearbeitung..........................................................................................................217
Eingangskorb darstellen........................................................................................................................220
Fehleranalyse........................................................................................................................................221
Technische Fehler in der ALE-Serviceschicht .................................................................................222
Logische Fehler in der Anwendung .................................................................................................225
Modifikationskonzept.............................................................................................................................227
Eingang (Empfangen von IDocs vom Fremdsystem) ......................................................................228
Ausgang (Senden von IDocs an ein Fremdsystem) ........................................................................231
SAP-Customer-Exits ........................................................................................................................233
Senden von Belegen an ein Fremdsystem ...........................................................................................234

6 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)

IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-


SRV-EDI)
Einsatzmöglichkeiten
Die Anwendungsszenarien beschreiben Geschäftsprozesse, bei denen EDI eingesetzt wird.
Definitionsgemäß handelt es sich also um Prozesse, bei denen zwei Partner beteiligt sind: Der
Sender und der Empfänger der EDI-Nachricht.
Die Szenarien sollen einen Geschäftsprozeß so einfach wie möglich und dennoch realistisch
beschreiben. Sie können damit als Vorlage oder Ausgangspunkt für von Ihnen einzurichtende
Geschäftsprozesse gelten, aber niemals Abbild Ihres speziellen Prozesses sein.

Integration
Die Prozesse verwenden immer mehrere Komponenten: Die jeweilige Anwendungskomponente
wird im Titel des Prozesses genannt. SD und MM verwenden immer die Nachrichtensteuerung
[Extern] als dritte Komponente. Die Daten werden immer über die IDoc-Schnittstelle [Extern]
ausgetauscht (Komponente CA-EDI-PRC).

Funktionsumfang
Allgemeines
Technische Realisierung der Szenarien [Seite 8]
Dieser Abschnitt befaßt sich mit den Programmtechniken, die allen Szenarien gemein sind.
Allgemeine Beispieldaten [Seite 9]
Dieser Abschnitt beschreibt die Beispieldaten, mit denen man Szenarien durchspielen kann.

Szenarien
Die Geschäftsprozesse werden möglichst nach folgendem Schema dargestellt: Es werden
Voreinstellungen und Bedienung auf Versand-, dann auf Empfangsseite gezeigt. Mit dem
Testwerkzeug [Extern] der IDoc-Schnittstelle kann man die Prozesse in einem System testen,
indem man die Ausgangsnachricht (das Ausgangs-IDoc) in eine Eingangsnachricht (das
Eingangs-IDoc) verwandelt. Dazu muß man insbesondere Absender und Empfänger im
Kontrollsatz vertauschen. Mit der IDoc-Anzeige [Extern] kann man sich die entstandenen IDocs
im System anschauen.
Im Verzeichnis links finden Sie die Geschäftsprozesse.

Einschränkungen
Die Szenarien gehen nicht auf die Konvertierung des IDoc-Standards in einen EDI-Standard
(etwa EDIFACT, ODETTE oder ANSI X.12) ein. Diese Konvertierung wird von einem externen
EDI-Subsystem geleistet. Beim Testen der Szenarien verläßt man also nicht den IDoc-Standard.
Die Szenarien beinhalten keine ALE-Integrationsszenarien, also auch keine Szenarien, in denen
das R/3-System mit Fremdsystemen innerhalb des eigenen Unternehmens zusammenarbeitet.
Dazu sei auf die folgende Dokumentation verwiesen:
ALE-Geschäftsprozess-Bibliothek [Extern]

April 2001 7
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Technische Realisierung der Szenarien

Technische Realisierung der Szenarien


Verwendung
Technisch gesehen laufen die Szenarien immer gleich ab: Nachdem der zu verschickende Beleg
von der Anwendung gebucht wird, erzeugt die Anwendung entweder selbst ein IDoc, oder es
wird eine Nachricht durch das Modul der Nachrichtensteuerung erzeugt. Aus dieser Nachricht
und dem Anwendungsbeleg wird ein Ausgangs-IDoc durch die IDoc-Schnittstelle erzeugt.
Auf Empfängerseite wird ein Eingangs-IDoc an die IDoc-Schnittstelle übergeben und von dieser
auf der Datenbank erzeugt. Auf welchem Weg das Eingangs-IDoc ins R/3-System gelangt, wird
hier nicht betrachtet. Um das Szenario zu testen, kann man über das Testwerkzeug [Extern] aus
dem Ausgangs-IDoc ein Eingangs-IDoc im gleichen System und Mandanten erzeugen.
Aus dem Eingangs-IDoc werden dann die Daten in die jeweiligen Anwendungstabellen überführt
und der Anwendungsbeleg gebucht.

Voraussetzungen
Der Ablauf der Szenarien erfordert folgende Voreinstellungen (sowohl für Absender als auch für
den Empfänger):
· Customizing der Anwendung, auch speziell für EDI – Insbesondere werden im
Customizing die Konditionselemente der Nachrichtensteuerung gepflegt, falls die
Anwendung dieses Modul verwendet (immer im SD und im MM).
· Eventuell weitere EDI-spezifische Voreinstellungen in den Stammdaten der Anwendung
· Partnervereinbarungen [Extern] und Portbeschreibung [Extern] der IDoc-Schnittstelle.

Aktivitäten
Der Absender bucht den Beleg, den er verschicken will. Beim Ausgang unter
Nachrichtensteuerung kann er sich vor dem Buchen die von der Nachrichtensteuerung
gefundene Nachricht anzeigen lassen und bei Bedarf bearbeiten.
Auf Empfängerseite läuft der Eingang des IDocs normalerweise automatisch, d.h. der Beleg wird
nach Eingang des IDocs gebucht. Dieser Vorgang kann an mehreren Stellen kontrolliert werden,
z.B. über die Anzeige der IDocs oder der entsprechenden Anwendungsbelege.
Wenn bei der IDoc-Verarbeitung ein Fehler passiert ist, setzt die Ausnahmebehandlung per
Workflow ein. Erst dann wird ein aktives Eingreifen des Sachbearbeiters nötig.

Eine gute Möglichkeiten, Fehler in der Eingangsverarbeitung aufzuspüren, bietet das


Testwerkzeug der IDoc-Schnittstelle [Extern]: Bestimmen Sie den hinter dem
Eingangs-Vorgangscode [Extern] stehenden ALE-Eingangsfunktionsbaustein und
rufen Sie ihn im Einganstest direkt auf. Wählen Sie zusätzlich die Option hell ab
Fehler aus. Sie gelangen damit auf das Bildschirmbild, auf dem der Eingangsfehler
passiert.

8 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Allgemeine Beispieldaten

Allgemeine Beispieldaten

Parameter im MM

Parameter Wert IDES?


Materialstamm ja
Material SH-100 ja
Branche C (Chemie)
Materialart HAWA (Handelsware)
Werk 1100 (Berlin) ja
Grunddaten
Mengeneinheit (Basis-ME =Alternativ-ME) kg (Kilogramm)
Warengruppe 001 (Metallverarbeitung)
Materialkurztext MDH
Einkauf
Einkäufergruppe 001 (B. Dietl) ja
Buchhaltung
Bewertungsklasse 3100 (Handelsware)
Preiseinheit 1
Preissteuerung V (gleitender Durchschnittspreis)
Gleitender Preis 1
Material-Infosatz
Planlieferzeit 10 Tage
Nettopreis 1 DEM/Stück
Material beim Lieferanten SD-EDIMAT ja
Kreditor (zentral) Wert
Kreditor 1014 (Herrmann & Riemer) ja
Buchungskreis 1000 (IDES Germany) ja
Einkaufsorganisation 1000 (IDES Germany) ja
Kontengruppe 0001
Anschrift
Suchbegriff EDI

April 2001 9
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Allgemeine Beispieldaten

Land DE (Deutschland)
Sprache DE (deutsch)
Korrespondenz
Debitor (Konto bei Kreditor) SD-EDI (Die „Nummer“, unter der ja
der Kunde im System des
Lieferanten geführt wird)
Zahlungsverkehr (allgemeine Daten)
Land DE (Deutschland)
Bankschlüssel 11345678
Bankkonto 12345678
Kontoführung
Abstimmkonto (F4-Hilfe)
Einkaufsdaten
Bestellwährung DEM (deutsche Mark)
Zahlungsbedingungen ZB01 (Skonto)
Incoterms CFR (Kosten und Fracht)

Parameter im SD

Parameter Wert IDES?


Materialstamm
Material SD-EDIMAT ja
Branche C (Chemie)
Materialart HAWA (Handelsware)
Werk 1000 (Hamburg) ja
Verkaufsorganisation 1000 (Frankfurt) ja
Vertriebsweg 10 (Endkundenverkauf)
Sparte 00 (spartenübergreifend)
Vertrieb/Verkaufsorganisation
Steuerklassifikation 0 (keine Steuern)
Vertrieb/allgemeine Werksdaten
Transportgruppe 0001 (auf Paletten)
Ladegruppe 0001 (Kran)

10 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Allgemeine Beispieldaten

Lagerortbestand
Lagerort 0001 (Auslieferungslager) ja
Lagerortbestände laufende Periode 100 frei verfügbar ja
Debitor (Stammdaten Vertrieb) Wert
Debitor TESTKUND
Buchungskreis 1000 (IDES AG)
Kontengruppe KUNA
Anschrift
Suchbegriff EDI
Land DE (Deutschland)
Sprache DE (deutsch)
Kontoführung
Abstimmkonto 140000 (Debitorenforderungen
Inland)
Korrespondenz Buchhaltung
Konto bei Debitor (Die „Nummer“, unter der 1014 (Herrmann & Riemer ja
der Lieferant im System des Kunden geführt
wird)
Verkauf Vertriebsbereich
Konto bei Debitor 1014 (Herrmann & Riemer) ja
Kundenbezirk 000001 (Bezirk Nord)
Preisgruppe 01 (Großabnehmer)
Währung DEM
Kundenschema 1 (Standard)
Auftragswahrscheinlichkeit 100 (Prozent)
Fakturierung Vertriebsbereich
Zahlungsbedingungen ZB01 (Skonto)
Steuerklassifikation 0 (keine Steuern)
Incoterms CFR (Kosten und Fracht)
Versand Vertriebsbereich
Auftragszusammenführung leer (keine
Auftragszusammenführung)
Partnerrollen Vertriebsbereich

April 2001 11
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Allgemeine Beispieldaten

Partnerbezeichnung 1100 für Partnerrolle WE


(kundeneigene Bezeichnung für
das Werk, an das geliefert
werden soll: s. „Parameter im
MM“)
Materialpreis Lieferant Wert
Material SD-EDIMAT ja
Preis („Nachrichtenart“ PR00 für 1 (DEM/Stück)
Preisfindung)

Parameter der IDoc-Schnittstelle

Bei der Portbeschreibung verwenden Sie im Verzeichnisnamen die Ihre System-ID.


In den Beispieldaten führt das System den Namen C11.

Parameter Wert IDES?


Portbeschreibung
Port Subsystem ja
Version 3 ja
Kommandodatei
Log. Destination SERVER_EXEC
Verzeichnis /usr/sap/C11/SYS/global nein
test.script
Ausgangsdatei
Verzeichnis /usr/sap/C11/SYS/global nein
Funktionsbaustein EDI_PATH_CREATE_USERNAME ja
Eingangsdatei
Verzeichnis /usr/sap/C11/SYS/global nein
Eingangsdatei inbound.file ja
Statusdatei
Verzeichnis /usr/sap/C11/SYS/global nein
Statusdatei status.file ja

12 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Anfrage (MM-PUR-RFQ)

Anfrage (MM-PUR-RFQ)
Einsatzmöglichkeiten
Um sich schnell über Lieferantenpreise zu informieren, verwenden Sie Anfragen per EDI.

Ablauf
Versand
Sie erzeugen das Anfrage-IDoc aus dem Einkauf.
EDI-Ausgang einer Anfrage (MM-PUR-RFQ) [Seite 14]

April 2001 13
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Ausgang einer Anfrage (MM-PUR-RFQ)

EDI-Ausgang einer Anfrage (MM-PUR-RFQ)


Verwendung
Sie können Anfragen per EDI versenden, um sich papierlos über Preise eines Materials bei
verschiedenen Lieferanten zu informieren.
Wenn Sie die Anfrage per EDI an den Lieferanten versenden, werden auch druckrelevante Texte
sowie die Anfragenummer übermittelt.

Voraussetzungen
Um Anfragen per EDI zu versenden, müssen Sie folgende Einstellungen vornehmen:

Nachrichtensteuerung
Sie müssen im Einkaufsmenü Nachrichtensätze für Ihre EDI-Lieferanten anlegen (Einkauf ®
Stammdaten ® Nachrichten ® Anfrage ® Anlegen).
Zum Versenden von Anfragen müssen Sie die Nachrichtenart NEU verwenden.

IDoc-Schnittstelle
Im Customizing des Einkaufs (Einkauf ® Nachrichten ® EDI ® Partnervereinbarung einstellen)
müssen Sie die folgende Einstellungen für Ihre EDI-Lieferanten pflegen:

Ausgangsparameter
Feld Wert
Partnerart LI (Lieferant)
Partnerrolle LF (Lieferant)
Nachrichtentyp REQOTE
Empfängerport gewünschter Port
Ausgabemodus IDoc sofort übergeben oder IDoc sammeln
Basistyp ORDERS01

Nachrichtensteuerung
Feld Wert
Applikation EA (Einkauf Anfrage)
Nachrichtenart NEU (Anfrage)
Nachrichtentyp REQOTE
Vorgangscode ME 12 (REQOTE Anfrage)

14 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Ausgang einer Anfrage (MM-PUR-RFQ)

Aktivitäten
Wählen Sie Einkauf ® Anfrage/Angebot ® Anfrage ® Anlegen. Geben Sie die erforderlichen
Daten ein. Wählen Sie aus der Positionsübersicht Kopf ® Lieferantenanschrift. Geben Sie den
gewünschten Lieferanten ein und sichern Sie Ihre Anfrage.

Weitere Informationen zur Anfrage finden Sie in der Dokumentation MM - Einkauf unter Anfrage
manuell anlegen [Extern].

April 2001 15
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Angebot (SD-LS)

Angebot (SD-LS)
Einsatzmöglichkeiten
Es wird nur der EDI-Versand betrachtet.

Ablauf
EDI-Versand eines Angebots (SD-SLS) [Seite 17]

16 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines Angebots (SD-SLS)

EDI-Versand eines Angebots (SD-SLS)


Verwendung
Im EDI-Szenario versenden Sie ein Angebot an Ihren Kunden. Diese Methode ist schnell und
spart Papier.

Voraussetzungen
Anwendung
Untenstehende Einstellungen zur Nachrichtensteuerung machen Sie im Customizing des
Vertriebs.

Nachrichtensteuerung
Im Standard legen Sie folgende Konditionselemente fest:
Konditionselement Wert

Verkaufsbelegsart AG (Angebot)

Schema V06000
Nachrichtenart AN00
Sendemedium 6 (EDI)

Zugriffsfolge 0001
Verarbeitungsprogramm Programm RSNASTED, Formroutine EDI_PROCESSING

Partnerrolle AG (Auftraggeber)

Anwendung V1

Wählen Sie dazu im Customizing des Vertriebs Grundfunktionen ® Nachrichtensteuerung ®


Nachrichtenfindung ® Nachrichtenfindung über Konditionstechnik ® Nachrichtenfindung für
Verkaufsbelege pflegen.
Partnerrolle und Sendemedium definieren Sie als Nachricht in einem Konditionssatz. Dazu
wählen Sie aus dem R/3-Einstiegsbild Logistik ® Vertrieb ® Stammdaten, Nachrichten ®
Verkaufsbeleg ® anlegen. Auf die entsprechende Konditionstabelle wird im Standard mit dem
Schlüssel „Verkaufsbelegsart“ zugegriffen.

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:
Feld Wert
Nachrichtentyp QUOTES
Partnerart KU (Kunde)

April 2001 17
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Angebots (SD-SLS)

Partnerrolle AG (Auftraggeber)

Empfängerport z.B. SUBSYSTEM

Ausgabemodus z.B. IDocs sofort übergeben


Basistyp ORDERS04
Vorgangscode SD12

Aktivitäten
Erzeugen Sie ein Angebot [Extern]. Wenn Sie im Konditionssatz den Verarbeitungszeitpunkt 4
(sofort versenden) festgelegt haben, wird ein IDoc erzeugt, das Ihre Anwendungsdaten enthält.
Um vor der Verbuchung die Nachricht zu editieren, wählen Sie Zusätze ® Nachrichten ® Kopf.

18 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Bestellung/Auftrag (MM-PUR-PO, SD-SLS-SO)

Bestellung/Auftrag (MM-PUR-PO, SD-SLS-SO)


Einsatzmöglichkeiten
Im EDI-Szenario werden Bestellungen und die entsprechenden Aufträge papierlos erfaßt und
übermittelt.

Ablauf
Versand
Auf MM-Seite wird eine Bestellung angelegt und übermittelt. Beim Sichern der Bestellung
erzeugt die Nachrichtensteuerung sofort eine Nachricht (Versandzeitpunkt 4), die per EDI
verschickt wird.

Eingang
Auf SD-Seite wird die Kundenbestellung per EDI empfangen und als Terminauftrag verbucht. Bei
fehlerhaften Daten oder Einstellungen können von Hand Änderungen vorgenommen werden.

R/3
R/3 (Kunde)
(Kunde)

Einkauf
Einkauf

Bestellung

Terminauftrag

Verkauf
Verkauf

Buchhaltungs-
Buchhaltungs-
beleg
beleg

R/3
R/3 (Lieferant)
(Lieferant)

April 2001 19
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand einer Bestellung (MM-PUR-PO)

EDI-Versand einer Bestellung (MM-PUR-PO)


Verwendung
Im EDI-Szenario versenden Sie eine Normalbestellung per EDI an Ihren Lieferanten.

Voraussetzungen
Anwendung
Folgende Punkte sind für den Empfänger zur Identifizierung wichtig:
· Sie haben in den Stammdaten Ihr Konto beim Lieferanten (Sicht Korrespondenz
Buchhaltung) gepflegt, das Sie als seinen Partner identifiziert (Feld LFB1-EIKTO).
· Sie haben einen Materialinfosatz angelegt, in dem Sie die Materialnummer des Kunden
der Materialnummer in Ihrem R/3-System zuordnen (Transaktion ME11).

Nachrichtensteuerung
Folgende Konditionselemente müssen gepflegt sein:
Konditionselement Wert
“Exklusiv” markieren
Nachrichtenart NEU (Neubestellung)
Schema RMBEF1 (Einkauf Bestellung Kopf),
Applikation EF (Einkauf)
Verarbeitungsroutine Programm RSNASTED, Formroutine EDI-PROCESSING
Zeitpunkt z.B. 4 (sofort, IDoc wird unmittelbar nach Buchen
des Belegs erzeugt)
Sendemedium 6
Partnerrolle LF
Zum Anlegen eines Konditions- oder Nachrichtensatzes lesen Sie den Abschnitt Nachrichtensatz
[Extern].

IDoc-Schnittstelle
Um eine Bestellung zu übermitteln, müssen folgende Vorraussetzungen erfüllt sein:
· Wenn Sie Konditionen oder Texte der Bestellung per IDoc an Ihren Lieferanten übermitteln
möchten, dann müssen Sie eine IDoc-Sicht [Extern] anlegen (Wählen Sie IDoc ® IDoc-
Basis ® Entwicklung ® IDoc-Sichten).
Diese IDoc-Sicht müssen Sie in den Partnervereinbarungen Ihres Lieferanten
hinterlegen.
- Wenn Sie Konditionen übermitteln möchten, dann nehmen Sie die Segmente E1EDK05
(Kopfkonditionen) und E1EDP05 (Positionskonditionen) in die Sicht auf.

20 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand einer Bestellung (MM-PUR-PO)

- Wenn Sie Texte übermitteln möchten, dann nehmen Sie die Segmente der Kopftexte
(E1EDKT1 und E1EDKT2) und Positionstexte (E1EDPT1 und E1EDPT2) in die Sicht auf.

Wenn Sie die Segmente für Texte nicht in die Sicht aufnehmen, dann werden keine
Texte übermittelt.
· Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:
Feld Wert
Nachrichtentyp ORDERS
Partnerart LI (Lieferant/Kreditor)
Partnerrolle LF (Lieferant)
Port z.B. SUBSYSTEM
Ausgabemodus z.B. IDocs sammeln
Basistyp ORDERS01 – ORDERS05
eventuell: Sicht (nur für Konditionen und Texte) z.B. MEINESICHT
Paketgröße 1
Applikation EF
Nachrichtenart NEU
Vorgangscode ME10

Aktivitäten
Sie legen eine Bestellung aus dem Einkaufsmenü über Bestellung ® Anlegen ® Lieferant
bekannt an.
Geben Sie Ihren Lieferanten, die Bestellart NB (Neubestellung) und Ihre Organisationsdaten ein.
Überprüfen Sie vor dem Sichern, daß der Nachrichtenvorschlag gemäß der von Ihnen
vorgenommenen Einstellungen erfolgt ist (Kopf ® Nachricht).
Ist der Vorschlag korrekt, so sichern Sie die Bestellung.

Wenn nicht die richtige Nachricht oder keine Nachricht vorgeschlagen wurde, obwohl
der Konditionssatz wie oben aussieht, dann sind möglicherweise die
Partnervereinbarungen nicht vollständig gepflegt.
Nutzen Sie in diesem Fall die Findungsanalyse der Nachrichtensteuerung, die Sie
aus dem Nachrichtenkopf über Springen ® Findungsanalyse aufrufen können.
Das System erzeugt ein IDoc vom Typ ORDERS01, das aber noch nicht an den Port übergeben
wird (Ausgabemodus „IDocs sammeln“).

April 2001 21
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang des Auftrags (SDS-SLS-SO)

EDI-Eingang des Auftrags (SDS-SLS-SO)


Verwendung
Im EDI-Szenario empfangen Sie einen Terminauftrag von Ihrem Kunden. Das System bucht den
Terminauftrag automatisch.

Voraussetzungen
Anwendung
· Es müssen Segmente E1EDKA1 mit Partnerrolle AG (Auftraggeber) bzw. LF (Lieferant)
im IDoc existieren. Daraus bestimmt das System Kunde und Lieferant.
· Falls das externe System nicht die Zuordnung von Kunde, Lieferant und
Verkaufsorganisation über Segmente des Typs E1EDK14 (Belegkopf
Organisationsdaten) vornimmt, müssen Sie diese Zuordnung selbst im Customizing
Vertrieb vornehmen (Transaktion VOE2).
· Die in Ihrem System gepflegte Materialnummer muß im IDoc in einem Segment vom Typ
E1EDP19, Qualifier 002 (Material beim Kreditor) übermittelt werden.

IDoc-Schnittstelle
· Eine Eingangs-IDoc vom Typ ORDERS01 (bzw. ORDERS02 oder 03) liegt vor, das von
einem in den Partnervereinbarungen eingetragenen Partner stammt. Sie können sich
über das Testwerkzeug künstlich ein Eingangs-IDoc aus einem Ausgangs-IDoc
erzeugen, das im MM gemäß EDI-Versand einer Bestellung [Seite 20] erzeugt wurde.
· In den Partnervereinbarungen (Eingangsparameter) sind folgende Felder gepflegt:
Feld Wert
Nachrichtentyp ORDERS (Bestellung/Auftrag)
Partnerart KU (Kunde/Debitor). Im Testfall (IDoc kommt per tRFC vom R/3-
System): LS (logisches System)
Vorgangscode ORDE
Verarbeitung z.B. sofortige Verarbeitung
Erlaubter Bearbeiter Organisationseinheit (z.B. ein R/3-Benutzer)

Aktivitäten
Eingangsverarbeitung
Die IDoc-Schnittstelle bucht das IDoc auf der Datenbank und stößt die Eingangsverarbeitung an.
Wenn keine Fehler auftreten, verbucht das System den Terminauftrag automatisch.

Ausnahmebehandlung
Im Fehlerfall erhalten die in den Partnervereinbarungen eingetragenen Bearbeiter ein Workitem
in ihren integrierten Eingangskorb. Einer der Bearbeiter nimmt das Workitem auf und nimmt
Korrekturen vor oder setzt das Löschkennzeichen für das IDoc.

22 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Auftragsbestätigung (SD-SLS, MM-PUR-GF-CON)

Auftragsbestätigung (SD-SLS, MM-PUR-GF-CON)


Einsatzmöglichkeiten
Auftragsbestätigungen per EDI können beim Empfänger automatisch weiterverarbeitet werden.
Folgeprozesse können sich anschließen.

Ablauf
Versand
EDI-Versand einer Auftragsbestätigung (SD-SLS) [Seite 24]

Eingang
EDI-Eingang einer Auftragsbestätigung (MM-PUR-GF-CON) [Seite 26]

April 2001 23
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand einer Bestellbestätigung (SD-SLS)

EDI-Versand einer Bestellbestätigung (SD-SLS)


Verwendung
Im EDI-Szenario legen Sie Bestellbestätigungen an und versenden sie per EDI an Ihren
Auftraggeber. Das spart Zeit und Papier.

Voraussetzungen
Anwendung
Untenstehende Einstellungen zur Nachrichtensteuerung machen Sie im Customizing des
Vertriebs.

Nachrichtensteuerung
Im Standard legen Sie folgende Konditionselemente fest:
Konditionselement Wert

Verkaufsbelegtyp AA
Schema V10000
Nachrichtenart BA00
Sendemedium 6 (EDI)
Zugriffsfolge 0001
Verarbeitungsprogramm Program RSNASTED, Formroutine EDI_PROCESSING
Partnerrolle AG (Auftraggeber)
Anwendung V1 (Verkauf)

Wählen Sie dazu im Customizing des Vertriebs Grundfunktionen ® Nachrichtensteuerung ®


Nachrichtenfindung ® Nachrichtenfindung über Konditionstechnik ® Nachrichtenfindung für
Verkaufsbelege pflegen.
Partnerrolle und Sendemedium definieren Sie als Nachricht in einem Konditionssatz. Dazu
wählen Sie aus dem R/3-Einstiegsbild Logistik ® Vertrieb ® Stammdaten, Nachrichten ®
Verkaufsbeleg ® anlegen. Auf die entsprechende Konditionstabelle wird im Standard mit dem
Schlüssel „Verkaufsorganisation“ zugegriffen.

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:
Feld Wert
Nachrichtentyp ORDRSP
Partnerart KU (Kunde)

24 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand einer Bestellbestätigung (SD-SLS)

Partnerrolle AG (Auftraggeber)

Port z.B. SUBSYSTEM

Basistyp ORDERS04
Vorgangscode SD10

Aktivitäten
Legen Sie einen Auftrag [Extern] an. Beim Sichern findet die Nachrichtensteuerung den
entsprechenden Konditionssatz zur Bestellbestätigung und gibt die Nachricht an die IDoc-
Schnittstelle weiter, die den weiteren Versand per EDI übernimmt. Die gefundenen
Konditionssätze können Sie sich aus dem Beleg über Zusätze ® Nachrichten ® Kopf anzeigen
lassen.

April 2001 25
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang einer Auftragsbestätigung (MM-PUR-GF-CON)

EDI-Eingang einer Auftragsbestätigung (MM-PUR-GF-


CON)
Verwendung
Sie haben mit Ihrem Lieferanten vereinbart, daß er Ihnen Auftragsbestätigungen zu Bestellungen
oder Rahmenverträgen schickt.
Sie können ausschließlich mit Auftragsbestätigungen arbeiten. Die Bestätigung hat dann
informativen Charakter, da nur die Bestätigungsnummer im System erfaßt wird.
Wenn Sie verschiedene Bestätigungen, wie Auftragsbestätigung und Lieferavis von Ihrem
Lieferanten empfangen möchten, dann können Mengen und Termine automatisch im System
erfaßt werden.
Weitere Informationen finden Sie in der Dokumentation MM - Einkauf im Abschnitt Bestätigungen
aus Sicht des Einkaufs [Extern] und Bestätigungen über EDI empfangen [Extern].

Voraussetzungen
Anwendung
Wenn Sie mit mehreren Bestätigungstypen arbeiten möchten, dann müssen Sie
· im Positionsdetailbild einen Bestätigungssteuerschlüssel eingeben
· im Customizing des Einkaufs die Bestätigungssteuerung einstellen (Einkauf ®
Bestätigungen ® Bestätigungssteuerung einstellen). Dort können Sie u.a. festlegen, in
welcher Reihenfolge Sie Bestätigungen von Ihrem Lieferanten erwarten.
Unter Bestätigungsreihenfolge können Sie:
- Toleranzen für die Termin- und Preisprüfung festlegen
- Lieferantenmaterialänderungen zulassen (Kennzeichen LMat)
- Preisänderungen durch den Lieferanten übernehmen (Kennzeichen Preis)

Wenn Sie ausschließlich mit Auftragsbestätigungen arbeiten, dann verwenden Sie


keinen Bestätigungssteuerschlüssel.

IDoc-Schnittstelle
Im Customizing des Einkaufs (Einkauf ® Nachrichten ® EDI ® Partnervereinbarung einstellen)
haben Sie folgende Einstellungen für Ihre EDI-Lieferanten gepflegt:

Eingangsparameter
Feld Wert
Partnerart LI
Partnerrolle LF
Nachrichtentyp ORDRSP

26 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang einer Auftragsbestätigung (MM-PUR-GF-CON)

Vorgangscode ORDR
Verarbeitung Anstoß sofort oder durch Hintergrundprogramm

Aktivitäten
Beim EDI-Eingang einer Auftragsbestätigung prüft das System, ob in der Bestellung oder im
Rahmenvertrag ein Bestätigungssteuerschlüssel vorhanden ist.
· Wenn kein Bestätigungssteuerschlüssel vorhanden ist, wird nur die Bestätigungsnummer auf
dem Positionsdetailbild erfaßt.
· Wenn ein Bestätigungssteuerschlüssel vorhanden ist, dann aktualisiert das System die
Übersicht der Bestätigungen, d.h. es werden die in der Auftragsbestätigung übermittelten
Mengen und Termine erfaßt. Wenn Sie eingegangene Bestätigungen sehen möchten, dann
wählen Sie aus der Positionsübersicht Position ® Bestätigungen ® Übersicht. In der Spalte
E (Erstellungskennzeichen) steht der Wert 3, dies bedeutet, daß die Bestätigung per EDI
eingegangen ist. Außerdem trägt das System die IDoc-Nummer in die Spalte Externer Beleg
ein.

Ein IDoc kann immer nur eine Bestellung bestätigen. Die Bestätigung bezieht sich
auf die Bestellposition und nicht auf einzelne Einteilungen.

Ausnahmen
Beim EDI-Eingang einer Auftragsbestätigung findet eine Mengen-, Preis- und Terminprüfung
statt. Zur Mengenprüfung werden die Unter- und Überlieferungstoleranzen der Position
herangezogen. Toleranzen für Preise und Termine können Sie im Customizing des Einkaufs
unter Bestätigungssteuerung einstellen definieren.
Die eingestellten Toleranzen gelten für alle Lieferanten. Über die Erweiterung MM06E001, die
SAP zur Verfügung stellt, können Sie festlegen, daß die Toleranzen für bestimmte Lieferanten
nicht gelten.
Wenn die bestätigten Mengen, Preise und Termine abweichen, dann gibt das System eine
Warnung aus. Der Einkaufsbeleg wird dann nicht aktualisiert.
Weitere Informationen finden Sie in der Dokumentation MM - Einkauf unter Fehlerkorrektur beim
Eingang von Bestätigungen über EDI [Extern].

April 2001 27
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Bestelländerung (MM-PUR-PO)

Bestelländerung (MM-PUR-PO)
Einsatzmöglichkeiten
Wie Bestellungen können auch Bestelländerungen per EDI versandt werden. Sie werden beim
Empfänger automatisch im Beleg erfaßt.

Ablauf
EDI-Ausgang einer Bestelländerung (MM-PUR-PO) [Seite 29]
EDI-Eingang der Bestelländerung (SD-SLS) [Seite 31]

28 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Ausgang einer Bestelländerung (MM-PUR-PO)

EDI-Ausgang einer Bestelländerung (MM-PUR-PO)


Verwendung
Im diesem Abschnitt wird beschrieben, wie Sie im Einkauf die Änderung einer bereits an Ihren
Lieferanten übermittelten Bestellung versenden.
Die Funktion entspricht dem EDI-Versand einer Bestellung.

Voraussetzungen
Anwendung
Sie haben die Bestellung bereits per EDI erfolgreich an Ihren Lieferanten übermittelt.

Nachrichtensteuerung
Sie haben Nachrichtenkonditionssätze für Ihre EDI Lieferanten angelegt (Einkauf ® Stammdaten
® Nachrichten ® Bestellung ® Anlegen)
Zum Versenden von geänderten Bestellungen müssen Sie die Nachrichtenart NEU verwenden.

IDoc-Schnittstelle
Im Customizing des Einkaufs (Einkauf ® Nachrichten ® Partnervereinbarung einstellen) haben
Sie folgende Einstellungen für Ihre EDI-Lieferanten gepflegt:

Ausgangsparameter
Feld Wert
Applikation EF (Einkauf Bestellung)
Nachrichtentyp ORDCHG
IDoc-Typ ORDERS02 oder ORDERS04
Vorgangscode ME 11 (ORDCHG: Bestelländerung)

Wenn Sie Konditionen oder Texte der Bestellung per IDoc an Ihren Lieferanten übermitteln
möchten, dann müssen Sie eine IDoc-Sicht anlegen. Weitere Informationen hierzu finden Sie im
Abschnitt EDI-Versand einer Bestellung [Seite 20].

Aktivitäten
Ändern Sie eine vorhandene Bestellung über Einkauf ® Bestellung ® Ändern. Nehmen Sie die
erforderlichen Änderungen vor und sichern Sie die Bestellung.
Die neue Nachricht wird mit der letzten erfolgreich übermittelten Nachricht verglichen. Bei
Bestelländerungen wird übermittelt, ob eine neue Position hinzugefügt, oder ob eine bereits
übermittelte Position geändert wurde.
Beim Versenden der Nachricht werden nur Änderungen übermittelt, die gleichzeitig neu und
druckrelevant sind. Für die neue Nachricht setzt das System das Änderungskennzeichen. Wenn

April 2001 29
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Ausgang einer Bestelländerung (MM-PUR-PO)

Sie das Änderungskennzeichen überprüfen wollen, wählen Sie in der Positionsübersicht der
Bestellung Kopf ® Nachrichten.

Siehe auch:
MM - Einkauf: Anlegen einer Bestellung [Extern]
Anwendungsübergreifende Komponenten:
Customizing der Nachrichtensteuerung im Einkauf (MM): Beispiel Bestellung [Extern]

30 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang der Bestelländerung (SD-SLS)

EDI-Eingang der Bestelländerung (SD-SLS)


Verwendung
Im EDI-Szenario erhalten Sie die Aufforderung, einen bereits angelegten Auftrag zu ändern. Der
Auftrag wurde Ihnen ebenfalls als Bestellung per EDI übermittelt.

Voraussetzungen
Anwendung
· Ein Auftrag ist bereits angelegt
· Untenstehender Konditionssatz der Nachrichtensteuerung ist als Nachricht in den
Vertriebsstammdaten angelegt

IDoc-Schnittstelle
In den Partnervereinbarungen (Eingangsparameter) sind folgende Werte gepflegt:

Parameter Wert
Partnerart KU (Kunde); Im ALE-Szenario (IDoc kommt per tRFC vom R/3-System):
LS (Logisches System)
Nachrichtentyp ORDCHG
Vorgangscode ORDC
Verarbeitung z.B. Anstoß sofort
Erlaubter Bearbeiter Organisationseinheit, z.B. ein R/3-Benutzer

April 2001 31
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang der Bestelländerung (SD-SLS)

Aktivitäten
R/3 Einkauf

IDoc

EDI-Subsystem
R/3
IDoc

Warnung R/3 Vertrieb (SD)


Fehler
OK
Mail Mail
Order
Warnung Online
Ändern!
anzeigen verarbeiten

Eingangsverarbeitung
Die IDoc-Schnittstelle empfängt ein IDoc und liest dessen Kontrollsatz. Daraus bestimmt sie die
Partnervereinbarung und daraus den Funktionsbaustein IDOC_INPUT_ORDCHG des Vertriebs.
Die ALE-Dienste werden aufgerufen.
Das System verarbeitet das IDoc im Hintergrund. Aus den Datensätzen bestimmt sie den zu
ändernden Auftrag.
Bei erfolgreicher Verarbeitung wird die Bestellung geändert. Das IDoc wird an die IDoc-
Schnittstelle zurückgegeben, die den Status 51 („erfolgreich verarbeitet“) schreibt.

Ausnahmebehandlung
Falls das System nicht den zugrundeliegenden Auftrag findet oder sonst ein Fehler in der
Anwendung passiert, bestimmt das System die Bearbeiter, die ein Workitem zur
Ausnahmebehandlung in ihren integrierten Eingangskorb erhalten. Ein Bearbeiter kann das
Workitem ausführen, um das IDoc eventuell zu ändern und nochmal der Bearbeitung zuzuführen
oder um einfach die Verarbeitung dieses IDocs zu beenden.
Um aus dem Auftragsbeleg auf die verknüpften IDocs zu verzweigen, wählen Sie dort Umfeld ®
Originale anzeigen. Sie gelangen auf ein Auswahlfenster, auf dem Sie Verknüpfte IDocs wählen.

32 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Lieferabruf (MM-PUR-OA-SCH, SD-SLS-OA-SCH)

Lieferabruf (MM-PUR-OA-SCH, SD-SLS-OA-SCH)


Einsatzmöglichkeiten
Zu einem SD-Lieferplan schickt ein Kunde einen Lieferabruf, in dem er einzelne Einteilungen
anfordert. Auf SD-Seite kann daraufhin automatisch eine Lieferung angelegt werden.

Voraussetzungen
Ein Lieferplan liegt sowohl auf MM als auch auf SD-Seite vor. Beachten Sie dazu die
entsprechenden Teilszenarien.

Ablauf
Versand
Auf MM-Seite erzeugen Sie den Lieferabruf oder Feinabruf und verschicken ihn über die
Nachrichtensteuerung per EDI an den Lieferanten.

Eingang
Auf SD-Seite wird der Lieferabruf automatisch verbucht. Wenn er als dispositionsrelevant
eingestuft ist, werden die abgerufenen Einteilungen für die Disposition bedarfswirksam.
Entsprechend kann der Lieferabruf auch als versandrelevant gekennzeichnet sein.

R/3
R/3 (Kunde)
(Kunde)

Lieferplan
Lieferplan

Einkauf
Einkauf

Lieferabruf (Ausgang)

Lieferabruf (Eingang)
Lieferplan
Lieferplan

Verkauf
Verkauf

Materialdisposition,
Materialdisposition, Versand
Versand

R/3
R/3 (Lieferant)
(Lieferant)

April 2001 33
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Lieferabrufs (MM-PUR-OA-SCH)

EDI-Versand eines Lieferabrufs (MM-PUR-OA-SCH)


Verwendung
Im EDI-Szenario übermitteln Sie Lieferabrufe aus der Komponente Einkauf in die Komponente
Vertrieb eines anderen R/3-Systems.

Voraussetzungen
Anwendung
· Der verwendeten Einkaufsbelegsart LPA (Lieferplan mit Abruf) muß ein Partnerschema
zugeordnet sein, damit im Lieferplankopf die erforderlichen Partner gepflegt werden
können. Die Zuordnung machen Sie im Einkaufs-Customizing unter Partnerfindung ®
Partnereinstellung in Einkaufsbelegen ® Partnerschemata Belegarten zuordnen
(Transaktion OMZ7).
· Für die Einkaufsbelegsart LPA muß das Flag „Zeitabhängige Konditionen“ gesetzt sein.
Das Flag setzen Sie im Einkaufs-Customizing unter Lieferplan ® Belegarten einstellen
(Transaktion OMED), Navigation Belegarten.
· Es liegt ein Lieferplan mit Einteilungen vor. Die Lieferplaneinteilungen können entweder
manuell angelegt [Extern] oder von der Bedarfsplanung erzeugt worden sein. Zum
Anlegen eines Lieferplans wählen Sie aus dem Einkauf Rahmenvertrag ® Lieferplan ®
anlegen ® Lieferant bekannt (Transaktion ME31L) und beachten Sie dort die Hilfe zur
Anwendung.

Abruferstellungsprofil für Lieferplan


Wenn Sie Lieferabrufe bzw. Feinabrufe periodisch erstellen wollen, können Sie ein
Erstellungsprofil festlegen, mit dem die Aggregation der Lieferplaneinteilungen zu Abrufen und
die periodische Erstellung der Abrufe steuern. Das Erstellungsprofil ordnen Sie der
Lieferplanposition zu (in den Zusatzdaten der Positionsdetails).
Sie können dann im Einkaufsmenü über Rahmenvertrag ® Lieferplan ® Abruf erzeugen Fein-
oder Lieferabrufe periodisch erzeugen.

Nachrichtensteuerung
· Nachrichtenart
Die Nachrichtenart für Lieferabrufe, die über EDI übermittelt werden, ist im Standard
LPH1.
Die Konditionselemente insgesamt sind:
Konditionselement Wert
Zuriffsfolge 0001
Schema RMBEL1
Applikation EL
Nachrichtenart LPH1
Verarbeitungsroutine Programm RSNASTED, Formroutine EDI_PROCESSING

34 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines Lieferabrufs (MM-PUR-OA-SCH)

Allgemeine Daten Konditionszugriff markieren


Zeitpunkt 3 (manuelle Ausgabe über das Einkaufsmenü)
Sendemedium 6 (EDI)
Partnerrolle LF (Lieferant)

Sie legen Nachrichtensätze zu Lieferplänen (= „Konditionssätze“ in der Terminologie der


Nachrichtensteuerung) im Einkaufsmenü unter Stammdaten ® Nachrichten ®
Lieferplaneinteilung ® anlegen an.

· Feinsteuerung der Nachrichtenart


Für die Nachrichtenart LPH1 muß ein Eintrag zum Vorgang 9 vorhanden und das
Kennzeichen A gesetzt sein. Das Kennzeichen steuert, daß bei der Ausgabe dieser
Nachrichtenart druckerabhängige Daten im Abrufkopf aktualisiert werden, z.B. das
Datum des Abrufs. Beachten Sie, daß das Kennzeichen pro Vorgang nur einmal gesetzt
werden kann, d.h., daß Sie sich für eine Hauptnachrichtenart entscheiden müssen.

IDoc-Schnittstelle
Sie müssen für den gewünschten Partner sowohl die Ausgangspartnervereinbarungen als auch
die zusätzlichen Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit
folgenden Werten pflegen:

Feld Wert
Nachrichtentyp DELINS
Partnerart LI
Partnerrolle LF
Empfängerport SUBSYSTEM
Ausgabemodus IDoc sofort übergeben
Basistyp DELFOR01
Paketgröße 1
Applikation EL
Nachrichtenart LPH1
Vorgangscode ME14 (Lieferabruf) oder
ME13 (Feinabruf)
Port Port, der für den Austausch von EDI-Nachrichten im Mandanten definiert
wurde

April 2001 35
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Lieferabrufs (MM-PUR-OA-SCH)

Aktivitäten
1. Sie erzeugen den Lieferabruf oder Feinabruf [Extern]. Im Customizing können Sie
einstellen, ob die Nachricht bearbeitbar sein soll oder nicht. Im letzteren Fall erhalten Sie
keinen Nachrichtenvorschlag, wenn Sie in der Transaktion Kopf ® Nachrichten wählen.
2. Der erstellte Abruf wird mit Hilfe der Nachrichtensteuerung über die IDoc-Schnittstelle in
die Komponente Vertrieb des anderen Systems übermittelt. Das System sollte dabei stets
eine neue Nachricht erzeugen, keine Änderungsnachricht.
Beim Versenden des Abrufs werden alle noch nicht belieferten (offenen) und in der
Zukunft liegenden Einteilungen übermittelt (wie im Abruferstellungsprofil definiert).
Lieferplaneinteilungen, deren Lieferdatum in der Vergangenheit liegt und die vollständig
beliefert wurde, werden nicht in Abrufe übernommen.

36 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Lieferabrufs (SD-SLS-OA-SCH)

EDI-Eingang eines Lieferabrufs (SD-SLS-OA-SCH)


Verwendung
Im EDI-Szenario empfangen und verarbeiten Sie einen Lieferabruf, der von einem Kunden-R/3-
System an Sie verschickt wurde.

Voraussetzungen
Anwendung
Allgemein
Lieferabrufe können nur auf Basis eines existierenden Lieferplans [Extern] erstellt werden.
Ein Lieferabruf kann nicht empfangen werden, wenn Sie gerade den entsprechenden Lieferplan
ändern.

Customizing
Spezielle EDI-spezifische Einstellungen für Lieferabrufe müssen im Customizing [Extern] getätigt
werden:
· Zuordnung des Auftraggebers [Extern]
Hier leiten Sie aus den vom Kunden gesandten Daten seine Kundennummer ab, wie sie
in Ihrem SAP-System gepflegt ist.
· Besonderheiten für Abrufe [Extern]
Sie müssen pro Auftraggeber bzw. pro Auftraggeber/Abladestelle definieren, ob und
welche speziellen Daten aus dem IDoc übernommen werden sollen. Wenn es für einen
Auftraggeber keine Definition findet, gibt das System eine Fehlermeldung aus und stoppt
die Verarbeitung des IDocs (Status 51, Ausnahmebehandlung).
Markieren Sie hier nicht Testlauf! Sonst verarbeitet das System nicht die Lieferabrufe,
sondern sendet sie per Workflow direkt an zuständige Bearbeiter, die sie dann manuell
weiterverarbeiten müssen.
Viele Fehler beim EDI-Eingang von Lieferabrufen passieren wegen inkorrekter Einstellungen in
diesen beiden Customizing-Aktivitäten.

IDoc Schnittstelle
In den Partnervereinbarungen Eingang sind folgende Felder gepflegt:

Parameter Wert
Partnerart KU (Kunde); Im ALE-Szenario (IDoc wird aus R/3-System über tRFC
übermittelt): LS (Logisches System)
Nachrichtentyp DELINS
Vorgangscode DELI
Verarbeitung z.B. sofortige Verarbeitung

April 2001 37
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Lieferabrufs (SD-SLS-OA-SCH)

Erlaubte Bearbeiter Organisationseinheit (z.B. R/3-Benutzer)

Aktivitäten
R/3 Einkauf

IDoc
mat 1

EDI Subsystem
R/3
IDoc
mat 1

Warnung R/3 SD
Fehler
OK
Mail Mail
Lieferplan

Warnung Online
ausgeben Abruf verarbeiten

Eingangsverarbeitung
Die IDoc-Schnittstelle empfängt das IDoc und leitet aus dem Kontrollsatz und den
entsprechenden Partnerverarbeitungen die Verarbeitung über den Funktionsbaustein
IDOC_INPUT_DELINS_START ab. Die ALE-Dienste werden aufgerufen.
Das System verarbeitet das IDoc im Hintergrund. Aus den IDoc-Datensätzen leitet es den
Auftraggeber und danach den Lieferplan ab.
Bei erfolgreicher Verarbeitung wird der Lieferabruf erzeugt oder aktualisiert. Danach erhält das
IDoc in der IDoc-Schnittstelle den neuen Status 53 („Anwendungsbeleg gebucht“).

Ausnahmebehandlung
Falls das System keinen Lieferplan findet oder sonst ein Verarbeitungsfehler in den
Anwendungen passiert, dann erzeugt das System ein Workitem und ermittelt Bearbeiter dieses
Workitems (zuerst belegspezifisch [Extern]; falls das nicht funktioniert, dann nach
Standardmethode der IDoc-Schnittstelle [Extern]). Das IDoc erhält den Status 51
(„Anwendungsbeleg nicht gebucht“). Es kann manuell weiterverarbeitet werden, oder die
Bearbeitung kann gestoppt werden.
Um IDocs aus dem Lieferplan heraus anzuzeigen, wählen Sie System ® Verknüpfungen
anzeigen ® IDocs.

38 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Beispieldaten (SD-SLS-OA-SCH)

Beispieldaten (SD-SLS-OA-SCH)
Im Beispiel ist im Kundenstamm für den Warenempfänger (Partnerrolle WE) das Werk 1100 als
Partnerbezeichnung gepflegt, also als Werk, wie es in den Stammdaten im R/3-System des
Kunden („Werk Berlin“) gepflegt ist.
Diese Partnerbezeichung wird dann auch für die Position des Materials SD-EDIMAT verwendet.
Daraus, dem Auftraggeber (Partnerrolle AG) und der Materialnummer des Kunden SH-100 wird
dann der Lieferplan bestimmt (s. Graphik).

DELFOR01
Werk:
Werk: 1100
1100
Kunde:
Kunde: SD-EDI
SD-EDI
Material:
Material: SH-100
SH-100

Verkauf
Verkauf
Ermittlung
des Lieferplans

Lieferplan

Partnerbezeichung:
Partnerbezeichung: 1100
1100
Auftraggeber:
Auftraggeber: SD-EDI
SD-EDI
Kundenmaterial:
Kundenmaterial: SH-100
SH-100

weitere
Bearbeitung

R/3
R/3 (Lieferant)
(Lieferant)

April 2001 39
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Lieferavis zum Lieferplan (SD-SHP-DL, MM-PUR-GF-CON)

Lieferavis zum Lieferplan (SD-SHP-DL, MM-PUR-GF-


CON)
Einsatzmöglichkeiten
Zu einem SD-Lieferplan werden Lieferungen angelegt. Die geplanten Liefertermine und Mengen
können dem Kunden in Form von Lieferavisen mitgeteilt werden. Die Lieferungen können vom
Kunden durch Lieferabrufe veranlaßt werden.
Der Warenempfänger erhält durch ein Lieferavis vorab Informationen über die geplanten
Lieferungstermine und kann den Wareneingang durch die Erfassung mit Bezug zum Lieferavis
vereinfachen.

Voraussetzungen
Ein Lieferplan liegt vor. Beachten Sie dazu das Szenario Lieferabruf [Seite 33].

Ablauf
Versand
Auf SD-Seite verbuchen Sie eine Lieferung und erzeugen über die Nachrichtensteuerung ein
Lieferavis, das per EDI an den Kunden verschickt wird.

Eingang
Auf MM-Seite wird das Lieferavis verarbeitet. Ist es als dispositionsrelevant eingestuft, dann fließt
die avisierte Menge in das Dispositionsverfahren mit ein.

R/3
R/3 (Lieferant)
(Lieferant)

Lieferplan
Lieferplan

Lieferabruf
Vertriebsabwicklung
Vertriebsabwicklung

Lieferavis (Ausgang)

Lieferavis (Eingang)

Bestandsführung
Bestandsführung

Buchhaltungs-
Buchhaltungs-
beleg
beleg

R/3
R/3 (Kunde)
(Kunde)

40 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Lieferavis zum Lieferplan (SD-SHP-DL, MM-PUR-GF-CON)

April 2001 41
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Lieferavis (SD-SHP-DL)

EDI-Versand eines Lieferavis (SD-SHP-DL)


Verwendung
Im EDI-Szenario legen Sie mit der Lieferung eine Nachricht an, die an den Kunden über EDI als
Lieferavis versandt wird. Die Lieferung ihrerseits kann durch einen Lieferabruf des Kunden
automatisch initiiert worden sein.
Im Szenario wird ein Lieferplan beliefert. Lieferavise können aber zu jeder Bestellung versandt
werden.

Voraussetzungen
Anwendung
· Der Lieferplan enthält von der Bestandsführung bestätigte (belieferbare) Positionen.
· Im Lieferplan ist als Bestellnummer die Lieferplannummer des Kunden eingetragen
· Im Lieferplan ist die Materialnummer des Kunden eingetragen

Nachrichtensteuerung
Im Szenario pflegen Sie folgende Konditionselemente:

Konditionselement Wert
Zugriffsfolge 0005 (Verkaufsorganisation/Kunde)
Bedingung 0 (keine Bedingung)
“Exklusiv” markieren
Nachrichtenart LAVA (Lieferavis Ausgang)
Schema V10000 (Versandnachrichten)
Applikation V2 (Versand)
Verarbeitungsroutine Programm RSNASTED, Formroutine EDI-PROCESSING
allgemeine Daten Konditionszugriff und Mehrfachversendung markieren, sonst Felder
freilassen
Zeitpunkt z.B. 4 (sofort, IDocs werden unmittelbar nach Buchen erzeugt)
Sendemedium 6
Partnerrolle WE
Sprache DE (deutsch)

Das Nachrichtenschema muß der verwendeten Belegart (der Lieferart) zugeordnet sein. Dies tun
Sie im Customizing Vertrieb über Grundfunktionen ® Nachrichtensteuerung ®
Nachrichtenfindung ® Nachrichtenfindung über Konditionstechnik ® Nachrichtenfindung für
Lieferungen pflegen ® Nachrichtenschema zuordnen (Transaktion V/71).

42 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines Lieferavis (SD-SHP-DL)

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:

Feld Wert
Nachrichtentyp DESADV
Partnerart KU (Kunde/Debitor)
Partnerrolle WE (Lieferant)
Port SUBSYSTEM
Ausgabemodus IDocs sammeln
Basistyp DELVRY01
Paketgröße 1
Applikation V2 (Versand)
Nachrichtenart LAVA
Vorgangscode DELV

Aktivitäten
Sie buchen die Lieferung über Logistik ® Vertrieb ® Versand, Lieferung ® anlegen
(Transaktion VL01). Dabei beziehen Sie sich
Über die Nachrichtensteuerung wird der Konditionssatz gefunden und das Lieveravis per EDI
(IDoc-Schnittstelle) an den Kunden geschickt. Dabei entscheidet der Versandzeitpunkt im
Konditionssatz, wann das entsprechende Ausgangs-IDoc erzeugt wird.

April 2001 43
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Beispieldaten (SD-SHP-DL)

Beispieldaten (SD-SHP-DL)
Parameter Wert IDES?
Lieferplan (Verkauf) Wert
Vertragsart LZ (Lieferplan mit Abruf)
Lieferplankopf
Auftragszusammenführung leer (keine Auftragszusammenführung)
Lieferplanübersicht
Auftraggeber SD-EDI
Bestellnummer
Material SD-EDIMAT
Übersicht Besteller
Bestellposition 10
Zielmenge 10
Kundenmaterial SH-100
Position - Versand
Versandstelle 1000 (IDES Germany)

44 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Lieferavis (MM-PUR-GF-CON)

EDI-Eingang eines Lieferavis (MM-PUR-GF-CON)


Verwendung
Lieferavise, die Sie per EDI von Ihrem Lieferanten empfangen, bestätigen Ihnen Mengen und
Termine zu Lieferplanabrufen oder Bestellungen.
Wenn ein Lieferavis Ihres Lieferanten per EDI eingeht, dann wird eine Anlieferung [Extern] zum
Lieferavis erzeugt.

Voraussetzungen
Customizing und Anwendung
· Für die Anlieferung müssen Sie im Customizing des Einkaufs unter Bestätigungen ®
Bestätigungssteuerung einstellen einen Bestätigungssteuerschlüssel definieren (Transaktion
OMGZ).
In der Bestätigungsreihenfolge sollten Sie folgende Kennzeichen setzen:
- Disporel.
- WE-relev.
- WE-Zuordnung
· Einer Lieferplan- oder Bestellposition müssen Sie im Positionsdetailbild den entsprechenden
Bestätigungssteuerschlüssel zugewiesen haben.

IDoc-Schnittstelle
· Für Lieferanten, von denen Sie Lieferavise empfangen wollen, müssen die
Partnervereinbarungen der IDoc-Schnittstelle gepflegt sein.
· In den Partnervereinbarungen (Einkauf ® Nachrichten ® EDI ® Partnervereinbarung
einstellen) haben Sie folgende Felder gepflegt:
Eingangsparameter
Feld Wert
Nachrichtentyp DESADV
Partnerart LI (Lieferant/Kreditor). Im ALE-Szenario (IDoc kommt per tRFC vom
SAP-System): LS (logisches System)
Vorgangscode DELS (ab Release 4.0, IDoc-Typ DELVRY01)
Verarbeitung Sofortige Verarbeitung
Erlaubter Bearbeiter Organisationseinheit (z.B. ein SAP-Benutzer)

Um Ihre Einstellungen zu überprüfen, können Sie sich über das Testwerkzeug [Extern]
ein Ausgangs-IDoc erzeugen, das Sie Ihrer Eingangsbearbeitung zuführen. Weitere
Informationen finden Sie im Abschnitt EDI-Versand eines Lieferavis [Seite 42].

April 2001 45
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Lieferavis (MM-PUR-GF-CON)

Aktivitäten
Das System legt beim EDI-Eingang eines Lieferavis eine Anlieferung mit eigenem
Anlieferungsbeleg an. Wurde die Anlieferung über den Bestätigungssteuerschlüssel als
dispositionsrelevant eingestuft, dann wird die avisierte Menge des Materials in das
Dispositionsverfahren mit einbezogen.

Automatisch erzeugte Anlieferungen zum Lieferavis können nicht manuell in der


Bestellung (bzw. im Lieferplan) geändert werden, sondern nur mit der Funktion
Anlieferung ändern.

Weitere Informationen zur Anlieferung aufgrund eines Lieferavis per EDI finden Sie in der
Dokumentation MM - Einkauf unter Bestätigungen aus der Sicht des Einkaufs [Extern] und
Bestätigungen über EDI empfangen [Extern].

46 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Beispieldaten (MM-PUR-GF-CON)

Beispieldaten (MM-PUR-GF-CON)

Parameter Wert IDES?


Lieferplan (Einkauf) nein
Lieferant 1014 (Herrmann & Riemer) ja
Vertragsart LPA
Einkaufsorganisation 1000 (IDES Germany) ja
Einkäufergruppe 001 (B. Dietl) ja
Bewegungsart 101 (Wareneingang zur
Bestellung)
Lieferplankopf
Laufzeitende 10.10.2010
Positionsübersicht
Material SH-100 ja
Zielmenge 100
Nettopreis 1 (DEM/Stück entspricht dem
Materialpreis beim Lieferanten)
Positionsdetail
Bestätigung Steuerung 0004 (Steuerschlüssel für
Lieferavis: dispositionsrelevant,
wareneingangsrelevant)
Steuerkennzeichen V0 (kein Steuervorgang)
Position - Zusatzdaten
Erstellungsprofil 0001
Position – Konditionen
Preis (PB00 = Nachrichtenart „Bruttopreis“) 1 (DEM/Stück, entspricht dem
Materialpreis beim Lieferanten)

April 2001 47
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Versandauftrag (SD-EDI-OM)

Versandauftrag (SD-EDI-OM)
Einsatzmöglichkeiten
Der Lieferant beauftragt einen externen Lagerhalter mit der Auslieferung der Ware.

Ablauf
Es wird nur der Ausgang betrachtet. Zur Integration in den Auslieferungsprozeß und zur
Dokumentation des verwendeten IDoc-Typs beachten Sie die folgende Dokumentation:
Lieferschnittstelle [Extern]

48 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Versandbestätigung (SD-EDI-IM)

Versandbestätigung (SD-EDI-IM)
Einsatzmöglichkeiten
Mit der Versandbestätigung teilt der Lagerhalter dem Lieferanten mit, daß ein vorangegangener
Versandauftrag bearbeitet wurde.

Voraussetzungen
Ein Versandauftrag muß vorliegen.

Ablauf
Es wird nur der Eingang betrachtet. Zur Integration in den Auslieferungsprozeß und zur
Dokumentation des verwendeten IDoc-Typs beachten Sie die folgende Dokumentation:
Lieferschnittstelle [Extern]

April 2001 49
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Transport (LE-TRA-TP)

Transport (LE-TRA-TP)
Einsatzmöglichkeiten
Der elektronische Austausch von Transportdaten gewinnt immer größere Bedeutung. Versender
(Verlader) übermitteln ihre Versandaufträge und Transportinformationen an ihre Dienstleister
(Spediteure, Reeder, Zollagenten). Letztere organisieren den Transport und sorgen für seine
reibungslose Durchführung. Oft findet der Transport entlang einer logistischen Transportkette
statt, an der mehrere Verkehrsträger und Dienstleister beteiligt sind. Gerade in diesem Fall
kommt es darauf an, die notwendigen Daten allen Beteiligten frühstmöglich bereitzustellen, um
Effizienz zu gewährleisten.

Ablauf
Ein möglicher Ablauf wäre zum Beispiel:

Versand Eingang
1. Der Versender übergibt dem Spediteur Der Spediteur empfängt die Transportbedarfe
einen teilweise oder vollständig und übernimmt die Feinplanung der Transporte
geplanten Transport (Transportauftrag).
2. Der Spediteur sendet Informationen Der Lieferant empfängt die vollständig
über die vollständig gesplanten geplanten Transporte vom Spediteur.
Transporte an den Versender zurück
3. Der Versender oder der Spediteur teilt Der Kunde empfängt Informationen über zu
dem Kunden Informationen über einen erwartende Transporte
zu erwartenden Transport mit
(Transportavis).

50 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Transport (LE-TRA-TP)

Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung R/3
R/3 (Spediteur)
(Spediteur)
oder

Grobplanung
R/3
R/3 (Versender)
(Versender)
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung Transportavis
Feinplanung

Transport
Transport oder
R/3
R/3 (Kunde)
(Kunde)
Transportavis

April 2001 51
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Transportbelegs (LE-TRA-TP)

EDI-Versand eines Transportbelegs (LE-TRA-TP)


Verwendung
Transportbelege werden generell im Rahmen zweier Szenarien versendet:
1. Der Versender übergibt dem Spediteur einen teilweise oder vollständig geplanten
Transport (Transportauftrag).
2. Der Versender oder der Spediteur teilt dem Kunden Informationen über einen zu
erwartenden Transport mit (Transportavis).

Voraussetzungen
Sie müssen eine Nachrichtenart anlegen, mit der der Transportbeleg per EDI verschickt werden
kann. Dazu steht die Nachrichtenart SEDI zur Verfügung, die Sie verwenden oder auch bei
Bedarf kopieren und dann verändern können. Das Sendemedium muß auf 6 (EDI) einstellt sein.
Folgende Konditionselemente müssen gepflegt werden:

Konditionselement Wert
Zugriffsfolge 0001
Nachrichtenart SEDI oder eine Kopie von SEDI
Schema z. B. V7STRA
Applikation V7
Verarbeitungsroutine Programm RSNASTED, Formroutine EDI-PROCESSING
allgemeine Daten Konditionszugriff und Mehrfachversendung markieren, sonst Felder
freilassen
Zeitpunkt z.B. 3 (explizite Anforderung)
Sendemedium 6
Partnerrolle CR (Carrier), bzw. WE (Warenempfänger)

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:

Feld Wert
Nachrichtentyp SHPMNT bzw. SHPADV
Partnerart LI (Lieferant/Kreditor) oder KU (Kunde)
Partnerrolle CR (Carrier) bzw. WE Warenempfänger

52 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines Transportbelegs (LE-TRA-TP)

Port SUBSYSTEM
Ausgabemodus z.B. IDocs sammeln
Basistyp SHPMNT03
Applikation V7
Nachrichtenart SEDI, bzw. eine von Ihnen definierte Kopie von SEDI
Vorgangscode SHPM

Aktivitäten
1. Szenario: Der Versender übergibt dem Spediteur einen teilweise oder vollständig
geplanten Transport (Transportauftrag).

Sie erfassen einen Transportbeleg, der entweder teilweise oder vollständig geplant ist (je
nachdem, ob Sie selbst oder ob der Spediteur die Feinplanung des Transports
übernimmt).

Je nach Einstellung des Zeitpunkts bei der Nachrichtenfindung wird der EDI-Versand
sofort bei Buchung (Zeitpunkt 4) oder z.B. bei expliziter Anforderung (Zeitpunkt 3)
angestoßen.
2. Szenario: Der Versender oder der Spediteur teilt dem Kunden Informationen über einen
zu erwartenden Transport mit (Transportavis).

Sie verfügen über einen vollständig geplanten Transportbeleg (den Sie selbst erstellt und
geplant, oder geplant vom Spediteur erhalten haben).

Je nach Einstellung des Zeitpunkts bei der Nachrichtenfindung wird der EDI-Versand
sofort bei Buchung (Zeitpunkt 4) oder z.B. bei expliziter Anforderung (Zeitpunkt 3)
angestoßen.

April 2001 53
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Transportbelegs (LE-TRA-TP)

R/3
R/3 (Spediteur)
(Spediteur)

Transportauftrag
R/3
R/3 (Versender)
(Versender)
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung
Lieferung

Transport
Transport R/3
R/3 (Kunde)
(Kunde)
Transportavis

54 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Transportbelegs (LE-TRA-TP)

EDI-Eingang eines Transportbelegs (LE-TRA-TP)


Verwendung
Transporte können durch eine EDI-Nachricht angelegt oder geändert werden.
Damit lassen sich beispielsweise folgende Szenarien abdecken:

Sammelgutverkehr
Der Spediteur holt in den Vorläufen Anlieferungen bei den Lieferanten ab. Dann stellt er den
Transport für den Hauptlauf zusammen und teilt diese Information dem Kunden als Transportavis
mit. Der Kunde kann nun sehr einfach einen Wareneingang für den gesamten Transport
(genauer die darin enthalten Anlieferungen) durchführen.

Transportdisposition
Ein Lieferant stellt dem Spediteur Lieferungen als Transportbedarfe zur Verfügung. Der
Spediteur plant den Transport und teilt das Ergebnis dem Lieferanten mit, der damit
entsprechende Aktivitäten für den Warenausgang der zugehörigen Lieferungen starten kann. Für
das Erzeugen von Transporten beim Kunden steht die Nachricht SHPADV
(Transportmeldung/Transportavis) zur Verfügung. Für das Anlegen oder Ändern von eigenen
Transporten ist die Nachricht SHPMNT zu verwenden. Beide Nachrichten basieren auf dem
Idoctyp SHPMNT03, die Verarbeitung erfolgt über den Vorgangscode SHPM. Sie können diese
Parameter innerhalb der EDI-Partnervereinbarung pflegen. Wählen Sie dazu Werkzeuge -
>Business Communication -> IDoc -> Partnervereinbarung.

Meldung von Termin und Status


Der Spediteur meldet per EDI den geplanten oder aktuellen Termin, z.B. den Status
Transportende mit dem entsprechenden Zeitpunkt.

Die Anlieferungen, auf die sich der Transport bezieht, müssen im System existieren.
Die Referenz erfolgt über die Anlieferungsnummer des Lieferanten
(Sammelgutverkehr) oder direkt (Transportdisposition). Beim Sammelgutverkehr ist
es deshalb notwendig, die Anlieferungen beim Kunden zu avisieren. Das geschieht
über die Nachrichten DESADV (Anlieferung). Es ist nicht möglich, über die
Eingangsverarbeitung von Transporten gleichzeitig Anlieferungen anzulegen, wie
dies bei Direkttransporten notwendig ist. Ebenso erfolgt bei Änderung des
Transports (z.B. geplantes Ankunftsdatum) keine Änderung der Anlieferung (mit
Auswirkung auf die Materialdisposition).

Voraussetzungen
Die im eingehenden Transport referenzierten Lieferungen müssen im empfangenden System
vorhanden sein.

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:

April 2001 55
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Transportbelegs (LE-TRA-TP)

Feld Wert
Nachrichtentyp SHPADV bzw. SHPMNT
Partnerart LI (Lieferant/Kreditor)
Basistyp SHPMNT03
Applikation V7
Nachrichtenart SEDI, bzw. eine von Ihnen definierte Kopie von SEDI
Vorgangscode SHPM

56 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Rechnungsprüfung (MM-IV)

Rechnungsprüfung (MM-IV)
Einsatzmöglichkeiten
Elektronisch übermittelte Rechnungen eines Lieferanten werden im Modul Logistik-
Rechnungsprüfung automatisch verarbeitet. Es wird also nur der EDI-Eingang betrachtet.

Ablauf
EDI-Eingang einer Rechnung [Seite 58]

April 2001 57
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang einer Rechnung (MM-IV)

EDI-Eingang einer Rechnung (MM-IV)


Einsatzmöglichkeiten
Durch EDI können Informationen zwischen verschiedenen Unternehmen übertragen werden.
Damit kann ein Lieferant statt mit einer gedruckten Papierrechnung die Rechnungsinformationen
elektronisch übermitteln. Das hat folgende Vorteile:
· schnellere Datenübermittlung
· Vermeidung von Eingabefehlern beim manuellen Erfassen der Rechnung
Für jede Rechnung wird ein IDoc erstellt. Aus den darin enthaltenen Daten bucht das System
eine Rechnung. Dazu muß die Rechnung in sich stimmig sein, und sie darf keine
Fehlermeldungen im System hervorrufen.
Weitere Informationen finden Sie unter IDoc-Schnittstelle / Electronic Data Interchange [Extern].

Voraussetzungen
Anwendungskomponente
Es müssen folgende Einstellungen im Customizing gepflegt sein:
Funktion Einstellung im Customizing der
Rechnungsprüfung
In welchem Buchungskreis soll die Rechnung Rechnungsprüfung ® EDI ® Buchungskreis
gebucht werden? zuordnen
Mit welchen Steuerkennzeichen sollen die vom Rechnungsprüfung ® EDI ®
Lieferanten übermittelten Steuerinformationen Steuerkennzeichen zuordnen
gebucht werden?
Mit welcher Belegart soll die Rechnung gebucht Rechnungsprüfung ® EDI ®
werden? Programmparameter eingeben
Wie soll das System auf Abweichungen
zwischen Rechnungsmengen und -werten zu
den aus Bestellung und Bestellentwicklung
ermittelten Mengen und Werten reagieren?

IDoc-Schnittstelle
Es sind folgende Einstellungen für die IDoc-Schnittstelle gepflegt:
Feld Wert
Nachrichtentyp INVOIC
IDoc-Typ INVOIC01
Vorgangscode INVM: herkömmliche Rechnungsprüfung
INVL: Logistik-Rechnungsprüfung

58 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang einer Rechnung (MM-IV)

Ablauf
Bei dem Verarbeiten eines IDocs im Rechnungseingang geht das System wie folgt vor:
1. Es ermittelt den Rechnungssteller.
2. Es liest die Daten der oben aufgeführten Customizing-Tabellen.
3. Es erzeugt die Eingangsrechnung.

Ergebnis
Wenn es möglich ist, bucht das System zu jedem IDoc einen Rechnungsbeleg.
Wenn das Buchen nicht möglich ist, dann erhält das IDoc einen entsprechenden Fehlerstatus.
Das IDoc muß dann manuell weiterverarbeitet werden.
Siehe auch:
Eingangsverarbeitung des gesendeten IDocs [Extern]
Bestimmung des Wareneingangs [Extern]
Verarbeitung der EDI-Rechnung [Extern]

April 2001 59
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Gutschriftsverfahren bei Lieferplänen (MM-IV-LIV, SD-SLS-OA-SCH)

Gutschriftsverfahren bei Lieferplänen (MM-IV-LIV, SD-


SLS-OA-SCH)
Einsatzmöglichkeiten
Beim Gutschriftsverfahren schreibt sich der Kunde die Rechnung selbst: Damit fällt für ihn die
Rechnungsgebühr weg. Per EDI wird das Verfahren papierlos und schnellstmöglich abgewickelt.
Im Szenario läuft das Gutschriftsverfahren im Rahmen eines Lieferplans ab.
Gutschriftsverfahren gibt es natürlich auch bei Einzelbestellungen.

Voraussetzungen
· Ein Lieferplan liegt vor. Beachten Sie dazu auch das Szenario Lieferabruf [Seite 33].
· Ein Lieferavis liegt vor. Beachten Sie dazu auch das Szenario Lieferavis [Seite 40].

Ablauf
Versand
Auf MM-Seite wird ein Wareneingang verbucht und anschließend abgerechnet. Der ERS-Beleg
wird mit Buchen des Verrechnungsbelegs erzeugt und per EDI verschickt.

Eingang
Auf SD-Seite wird der ERS-Beleg als externe Rechnung per EDI empfangen und mit der internen
Faktura verglichen. Bei Übereinstimmung der Werte wird die interne Faktura entsprechend
modifiziert. Bei Abweichungen wird sie von Hand modifiziert.

R/3
R/3 (Kunde)
(Kunde)

Lieferung
Bestandsführung
Bestandsführung

Wareneingang

Rechnungswesen
Rechnungswesen

ERS-Beleg

Abrechnungsbeleg

Rechnungswesen
Rechnungswesen

Buchhaltungs-
Buchhaltungs-
beleg
beleg

R/3
R/3 (Lieferant)
(Lieferant)

60 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Gutschriftsverfahren bei Lieferplänen (MM-IV-LIV, SD-SLS-OA-SCH)

April 2001 61
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines ERS-Belegs (MM-IV-LIV)

EDI-Versand eines ERS-Belegs (MM-IV-LIV)


Verwendung
Im EDI-Szenario rechnen Sie Wareneingänge mit der automatischen Wareneingangsabrechnung
(ERS-Verfahren) ab, bei dem die Rechnungen und die dazugehörigen FI-Buchungen erzeugt
werden. Als Nachweis über die abgerechneten Vorgänge versenden Sie einen ERS-Beleg per
EDI.
Das Szenario läuft im Rahmen eines Lieferplans ab. ERS-Belege zu Einzelbestellungen können
aber auch versendet werden.

Voraussetzungen
Anwendung
· In den Lieferplanpositionen ist das Kennzeichen Automatische WE-Abrechnung gesetzt.
Dazu muß wiederum im Lieferantenstamm (Sicht Einkaufsdaten) das Kennzeichen
Automatische WE-Abrechnung gesetzt sein.
· Ein Lieferavis mit Bezug auf einen Lieferabruf liegt vor. Er enthält automatisch
abrechenbare Lieferplanpositionen.
· Die Lieferscheinnummer wird beim Wareneingang angegeben.

Nachrichtensteuerung
Folgende Konditionselemente müssen gepflegt sein:

Konditionselement Wert
Zugriffsfolge 0002
Bedingung 0
“Exklusiv” markieren
Nachrichtenart ERS6 (ERS-Verfahren per EDI = Sendemedium 6)
Schema MR0004 (ERS-Verfahren),
Applikation MR
Verarbeitungsroutine Programm RSNASTED, Formroutine EDI-PROCESSING
allgemeine Daten Konditionszugriff und Mehrfachversendung markieren, sonst Felder
freilassen
Zeitpunkt z.B. 4 (sofort, IDocs werden unmittelbar nach dem Buchen
erzeugt)
Sendemedium 6
Partnerrolle LF

62 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines ERS-Belegs (MM-IV-LIV)

Sie können Konditionssätze aus der Logistik-Rechnungsprüfung über Umfeld


definieren.

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:

Feld Wert
Nachrichtentyp GSVERF
Partnerart LI (Lieferant/Kreditor)
Partnerrolle LF (Lieferant)
Port SUBSYSTEM
Ausgabemodus z.B. IDocs sammeln
Basistyp GSVERF01
Applikation MR
Nachrichtenart ERS6 bzw. die von Ihnen definierte Art
Vorgangscode MRRL

Aktivitäten
· Sie erfassen einen Wareneingang in der Bestandsführung: Wählen Sie dazu Zur
Bestellung. Im folgenden Bild geben Sie Nummer des Lieferplans ein.
· Zur Bewertung (Preisfindung über Konditionstechnik) wählen Sie aus dem R/3-
Einstiegsbild über Logistik ® Materialwirtschaft ® Rechnungsprüfung ® Logistik
Rechnungsprüfung, Weiterverarbeitung ® ERS durchführen. Verwenden Sie die
Belegabgrenzung “4”, um eine Rechnungsposition zu buchen. Damit wird im ERS-Beleg
pro Lieferschein eine Position erzeugt. Auf der Eingangsseite kann der Vertrieb nämlich
pro IDoc nur einen Lieferschein verarbeiten.
· Mit Buchen des Belegs wird die Nachrichtenfindung und Nachrichtenverarbeitung
(Versandzeitpunkt 4 = “Ausgabe sofort”) angestoßen.
· Resultat ist ein Ausgangs-IDoc pro Lieferavis.

April 2001 63
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines ERS-Belegs (MM-IV-LIV)

R/3
R/3 (Kunde)
(Kunde)

Lieferung
Bestandsführung
Bestandsführung

Materialbeleg
Materialbeleg

Rechnungsprüfung
Rechnungsprüfung

ERS-Beleg
ERS-Beleg

NAST/IDoc-Schnittstelle
NAST/IDoc-Schnittstelle

IDoc,
IDoc, Typ
Typ
GSVERV01
GSVERV01

64 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang der externen Rechnung (SD-SLS-OA-SCH)

EDI-Eingang der externen Rechnung (SD-SLS-OA-SCH)


Verwendung
Beim Zulieferer werden die Fakturen, die er aufgrund der Lieferungen an den Kunden erzeugt
hat, automatisch mit den Werten aus der externen Rechnung verglichen. Die externe Rechnung
ist die Grundlage für das Zahlungsavis, das vom Kunden an den Zulieferer versandt wird.
Das Szenario läuft im Rahmen eines Lieferplans ab. Externe Rechnungen zu Einzelbestellungen
können natürlich auch verarbeitet werden.

Voraussetzungen
Anwendung
· Customizing-Einstellung zum EDI-Auftraggeber und zur Fehlerbehandlung zu
Lieferplänen. Diese Einstellungen sind im Szenario Lieferabruf empfangen [Seite 37]
beschrieben.
· Für den Warenempfänger existiert eine Sonderregel, die Sie im Customizing pflegen
(Transaktion OVD1). Die Verkaufsbelegarten GS und LS sind nur für
Ausgleichsrechnungen erforderlich.
· Sie haben die Lieferung als Warenausgang gebucht und fakturiert (interne Faktura).

IDoc-Schnittstelle
· Eine Eingangs-IDoc vom Typ GSVERF01 liegt vor, das von einem in den
Partnervereinbarungen eingetragenen Partner stammt. Sie können sich über das
Testwerkzeug künstlich ein Eingangs-IDoc aus einem Ausgangs-IDoc erzeugen, das im
MM gemäß EDI-Versand eines ERS-Belegs (MM-IV-LIV) [Seite 62] erzeugt wurde.
· In den Partnervereinbarungen (Eingangsparameter) sind folgende Felder gepflegt:

Feld Wert
Nachrichtentyp GSVERF (Bestellung)
Partnerart KU (Kunde/Debitor). Im ALE-Szenario (IDoc kommt per tRFC vom
R/3-System): LS (logisches System)
Vorgangscode GSVE
Verarbeitung sofortige Verarbeitung
Erlaubter Bearbeiter Organisationseinheit (z.B. ein R/3-Benutzer)

April 2001 65
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang der externen Rechnung (SD-SLS-OA-SCH)

Aktivitäten
Eingangsverarbeitung
Das System ermittelt die zur externen Rechnung zugehörigen Lieferungen und interne Fakturen.
Die Faktura ist “intern”, da sie ja nicht an den Kunden verschickt wird. Zur Ermittlung werden
folgende IDoc-Daten nach der angegebenen Priorität herangezogen:
1. Interne Lieferungsnummer
2. Bestellnummer des Kunden: Dies gilt bei Anlieferung über einen externen Dienstleister
aus einem Konsignationsbestand, hat also im vorliegenden Szenario keine Bedeutung.
3. Externe, vom Kunden vorgegebene Lieferungsnummer
Zu den über 1., 2. oder 3. gefundenen Lieferungen werden die zugehörigen Fakturen ermittelt.
Die ermittelten Werte aus den Fakturen werden mit den Werten aus der externen Rechnung
verglichen. Folgende Werte werden pro Lieferposition geprüft:
· Nettowert der Position
· Skonto
· Zu-/Abschläge
· Mehrwertsteuer
Falls die Werte übereinstimmen, wird dem offenen Posten des FI-Belegs als Referenz die
Nummer der externen Rechnung übergeben. Sie ersetzt dort die Bestellnummer des Kunden
und belegt damit, daß die Rechnung im SD vom Lieferanten geprüft wurde: Der Lieferant hat
diese Aufgabe dem Kunden abgenommen. Die neue Referenznummer wird im Folgeszenario
(Zahlungsavis) bei der automatischen Auszifferung verwendet.

Ausnahmebehandlung.
Falls es Abweichungen gibt, erhalten die in den Partnervereinbarungen eingetragenen Bearbeiter
ein Workitem in ihren integrierten Eingangskorb. Einer der Bearbeiter nimmt das Workitem auf
und nimmt Korrekturen vor (Preisdifferenz, Entfernen der Fakturasperre). Er übergibt
gegebenenfalls die Gutschriftsnummer manuell an den offenen Posten (FI-Beleg) und entfernt
die Fakturasperre.

66 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Zahlungsavis (FI-AP-AP-PT, FI-AP-AP-P)

Zahlungsavis (FI-AP-AP-PT, FI-AP-AP-P)


Einsatzmöglichkeiten
Durch Angabe einer EDI-Verbindung zum Geschäftspartner können Sie auf einen Druck von
Begleitschreiben (sog. Avisen) zum Zahlungsträger verzichten und die Informationen zu
bezahlten Posten auf elektronischem Wege per EDI weiterleiten. Damit können die Informationen
schneller zum Partner übertragen werden. Der Geschäftspartner kann die Daten automatisch
weiterverarbeiten.

Ablauf
Versand
Sie erzeugen das IDoc zum Zahlungsavis direkt aus dem FI, ohne die Nachrichtensteuerung.
EDI-Versand eines Zahlungsavis (FI-AP-AP-PT) [Seite 68]

Eingang
Das Avis wird in die Avisdatenbank eingestellt und steht dann für den Ausgleich der offenen
Posten zur Verfügung.
EDI-Eingang eines Zahlungsavis (FI-AR-AR-P) [Seite 70]

April 2001 67
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Zahlungsavis (FI-AP-AP-PT)

EDI-Versand eines Zahlungsavis (FI-AP-AP-PT)

Verwendung
Durch Angabe einer EDI-Verbindung zum Geschäftspartner können Sie auf einen Druck von
Begleitschreiben (sog. Avisen) zum Zahlungsträger verzichten und die Informationen zu
bezahlten Posten auf elektronischem Wege per EDI weiterleiten. Damit können die Informationen
schneller zum Partner übertragen werden. Der Geschäftspartner kann die Daten automatisch
weiterverarbeiten.

Voraussetzungen
Anwendung
Beim Kreditor/Debitor muß zusätzlich bei der Stammsatzpflege das Kennzeichen Avis per EDI
(Buchungskreisdaten/Zahlungsverkehr) markiert werden.
Da per EDI ISO-Codes übermittelt werden, müssen zusätzlich im Customizing die Tabellen zur
Umsetzung der SAP-Codes in ISO-Codes für die Währung, die Mengeneinheit und die Länder
gepflegt sein.
Weitere Informationen hierzu finden Sie im Einführungsleitfaden "Globale Einstellungen" in den
Arbeitsschritten „Länder definieren [Extern]“, "Währungscodes überprüfen [Extern]" und
"Maßeinheiten überprüfen [Extern]".

IDoc-Schnittstelle
Sie pflegen die Ausgangs-Partnervereinbarungen (allgemeine Ausgangsparameter) mit
folgenden Werten:

Feld Wert
Nachrichtentyp REMADV
Partnerart LI (Lieferant / Kreditor)
Basistyp PEXR2001
Port z.B. SUBSYSTEM

Aktivitäten
Wenn der Versand per EDI eingestellt ist, nutzen sämtliche Zahlungsträgerprogramme die
Möglichkeit, Informationen auf elektronischem Wege zu versenden. Diese Programme prüfen
automatisch, ob der Geschäftspartner ein EDI-Avis erhalten soll oder ob das Avis gedruckt wird.
Beim Avisdruck erhält der Partner nur dann ein Avis, wenn die Informationen nicht über den
Zahlungsträger übermittelt werden können. Beim EDI-Avis wird dagegen stets ein Avis erstellt.

68 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Aktivitäten

Es kann vorkommen, daß ein Avis erneut versandt werden muß.


Normalerweise wird der Avisdruck dadurch wiederholt, daß man die Reports zur
Zahlungsträgererstellung erneut startet. Dies ist bei EDI nicht möglich, da die
Informationen möglicherweise bereits an einen oder mehrere Partner versendet sind.
Um EDI-Avise erneut zu versenden, muß man den Report RFFOEDI0 verwenden.

April 2001 69
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Zahlungsavis (FI-AR-AR-P)

EDI-Eingang eines Zahlungsavis (FI-AR-AR-P)

Verwendung
Elektronisch übermittelte Avise können automatisch weiterverarbeitet werden. Diese Avise
können entweder von einem Partner (Zahlungsavis/Avis zur Lastschrift/zum Bankeinzug) oder
von einer Bank (Gutschriftsanzeige/Belastungsanzeige) stammen.
Das Avis wird in die Avisdatenbank eingestellt und steht dann für den Ausgleich der offenen
Posten zur Verfügung. Die Avisdaten können auch automatisch weiterverarbeitet werden:
· Es kann ein Avis für die Finanzdisposition erzeugt werden
· Die offenen Posten können automatisch ausgeglichen werden
Ist der Ausgleich nicht erfolgreich, so wird der Betrag dennoch dem betreffenden Konto
gutgeschrieben. Mit dem dann noch vorhandenen Avis (Ursprungsavis plus Akonto-
Belegzeile) können Sie diese Fälle mit dem Report RFAVIS40 bearbeiten.
Sie steuern über den Vorgangscode, ob die Avisdaten lediglich in die Avisdatenbank
geschrieben werden, oder ob sie automatisch weiterverarbeitet werden. (siehe auch den
Abschnitt über die IDOC-Schnittstelle)

Voraussetzungen
Anwendung
· Buchungskreis
EDI benötigt für den Zahlungsaviseingang einen Buchungskreis.
Wenn Ihr Partner Ihnen Ihre Bankverbindung mitteilt, kann das SAP-System diesen
Buchungskreis über die Bankverbindung ermitteln.
Wenn nicht, müssen Sie im Customizing den externen Namen Ihrer Firma einem
Buchungskreis zuordnen. Führen Sie dazu im Einführungsleitfaden der Debitoren- und
Kreditorenbuchhaltung unter Geschäftsvorfälle ® Zahlungseingang ® Zahlungseingang
elektronisch ® Zahlungsavise den Arbeitsschritt Buchungskreis für EDI-Avise zuordnen
[Extern] durch. Hier finden Sie die Konvertierungstabelle für die Umsetzung des
übermittelten Namens Ihrer Firma zum Buchungskreis.
· ISO-Codes hinterlegen
Da per EDI ISO-Codes übermittelt werden, müssen Sie im Customizing die Umsetzung
der SAP-Codes in ISO-Codes für die Währung, die Mengeneinheit und die Länder
korrekt und vollständig hinterlegt haben.
Weitere Informationen hierzu finden Sie im Einführungsleitfaden Globale Einstellungen
® Länder definieren [Extern], Währungscodes überprüfen [Extern], Maßeinheiten
überprüfen [Extern].
· Weitere Verarbeitung der Avise festlegen
Die weitere Verarbeitung (Finanzdispoavis erzeugen, offene Posten automatisch
ausgleichen) hinterlegen Sie im Customizing. Führen Sie im Einführungsleitfaden der
Debitoren- und Kreditorenbuchhaltung unter Geschäftsvorfälle ® Zahlungseingang ®

70 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Aktivitäten

Zahlungseingang elektronisch ® Zahlungsavise den Arbeitsschritt Weitere Verarbeitung


von Avisen hinterlegen [Extern] durch.

IDoc-Schnittstelle
Sie müssen die Eingangs-Partnervereinbarungen mit folgenden Werten pflegen:

Feld Wert
Aviseingang
Nachrichtentyp REMADV
Partnerart KU
Vorgangscode REMA (keine Weiterverarbeitung)
REMC (automatische Weiterverarbeitung)
Gutschriftsanzeige
Nachrichtentyp CREADV
Partnerart B
Vorgangscode CREA (keine Weiterverarbeitung)
CREC (automatische Weiterverarbeitung)
Belastungsanzeige
Nachrichtentyp DEBADV
Partnerart B
Vorgangscode DEBA (keine Weiterverarbeitung)
DEBC (automatische Weiterverarbeitung)

Aktivitäten
Ausnahmebehandlung
Für den Fehlerfall muß der Standardaufgabe 7949 (REMADV_Error) eine Planstelle zugewiesen
werden. Sollen Fehlersituationen pro EDI-Partner von unterschiedlichen Sachbearbeitern
(Planstellen) bearbeitet werden, so können Sie dies bei der EDI-Partnervereinbarung einstellen.

Der Sachbearbeiter, der in der EDI-Partnervereinbarung eingetragen wird, muß auch


der Organisationseinheit (z.B. der Planstelle) zugeordnet sein, die zur
Standardaufgabe eingetragen ist – oder diese Aufgabe ist als generelle Aufgabe
klassifiziert.

April 2001 71
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Beispieldaten (FI-AR-AR-P)

Beispieldaten (FI-AR-AR-P)

Parameter Wert IDES?


Debitor (Stammdaten Vertrieb): Sicht
Buchhaltung Zahlungsverkehr
Selektionsregel 001 (Für die Identifizierung eines
offenen Postens bzw. zur
Auszifferung beim Zahlungseingang
mit Bezug auf Zahlungsavis.)

72 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Kontoauszugs (FI-BL-PT-BS)

EDI-Eingang eines Kontoauszugs (FI-BL-PT-BS)


Verwendung
Der Kontoauszug, der bisher mittels Datenfernübertragung von der Hausbank abgeholt wurde,
kann per EDI empfangen werden. Die Kontoauszugsinformationen gelangen automatisch in das
R/3-System und Umsätze bzw. Ausgleichsbuchungen, die aus dem Kontoauszug resultieren,
können direkt verbucht werden. Erhaltene Zahlungen von Ihrem Geschäftspartner werden z.B.
automatisch mit offenen Rechnungsposten ausgeglichen.
Der Kontoauszug besteht aus zwei Ebenen:
· Summenebene
Sie enthält Daten zum Hausbankkonto und den aktuellen Kontostand.
· Ebene der Umsätze
Sie enthalten die Bewegungen auf dem Bankkonto. Die Umsätze können noch detailliert
in eigenen Nachrichten (Gutschrifts- bzw. Belastungsanzeige) beschrieben werden. In
diesem Fall enthält der Kontoauszug nur eine Referenz auf diese Nachrichten.
Eine besondere Art des Kontoauszugs stellt die Abfrage des Kontostandes (Polling
Information) dar. Er enthält keine Umsätze.

Voraussetzungen
Anwendung
· Bank als EDI-fähig kennzeichnen
Diesen Schritt müssen Sie vor der Pflege der Partnervereinbarungen ausführen, da nur
dort die EDI-fähigen Banken ausgewählt werden können.
Dazu gehen Sie folgendermaßen vor:
a. Wählen Sie im Einführungsleitfaden Bankbuchhaltung ® Bankkonten ® Hausbanken
definieren.
b. Führen Sie den Arbeitsschritt aus.
c. Geben Sie einen Buchungskreis ein und wählen Sie Springen ® Hausbanken.
d. Wählen Sie die gewünschte Bank per Doppelklick.
e. Wählen Sie Springen ® DTA.
f. Geben Sie eine Partnernummer ein (z.B. den Bankschlüssel).
Von hier aus können Sie die Partnervereinbarungen erreichen. Was Sie dort hinterlegen,
lesen Sie im Abschnitt IDoc-Schnittstelle.
· Einstellungen im Customizing des elektronischen Kontoauszugs vornehmen
Damit das System Umsätze, die sich aus dem Kontoauszug ergeben, automatisch auf
die entsprechenden Konten buchen kann, müssen Sie die folgenden Einstellungen im
Customizing des elektronischen Kontoauszugs vornehmen. Sie finden Sie im
Einführungsleitfaden der Bankbuchhaltung unter Geschäftsvorfälle ® Zahlungsverkehr
® Elektronischer Kontoauszug

April 2001 73
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Kontoauszugs (FI-BL-PT-BS)

Vorgangstypen anlegen [Extern]


Zuordnung von Banken zu Vorgangstypen [Extern]
Schlüssel für Buchungsregeln anlegen [Extern]
Zuordnen von externen Vorgängen zu Buchungsregeln [Extern]
Buchungsregeln definieren [Extern]
Reportauswahl definieren [Extern]
Weitere Informationen zum elektronischen Kontoauszug finden Sie in der R/3-Bibliothek
unter Finanzwesen ® Bankbuchhaltung ® Elektronischer Kontoauszug.
· ISO-Codes hinterlegen
Da per EDI ISO-Codes übermittelt werden, müssen Sie im Customizing die Umsetzung
der SAP-Codes in ISO-Codes für die Währung, die Mengeneinheit und die Länder
korrekt und vollständig hinterlegt haben.
Weitere Informationen hierzu finden Sie im Einführungsleitfaden Globale Einstellungen
® Länder definieren [Extern], Währungscodes überprüfen [Extern], Maßeinheiten
überprüfen [Extern].
IDoc-Schnittstelle
Hinterlegen Sie folgende Parameter in den Eingangs-Partnervereinbarungen:
Feld Wert
Nachrichtentyp FINSTA
Partnerart B
Vorgangscode FINS
Verarbeitung z.B. sofortige Verarbeitung
Erlaubter Bearbeiter Organisationseinheit (z.B. ein R/3-Benutzer)

Aktivitäten
Eingangsverarbeitung
Die Verarbeitung eines Kontoauszuges erfolgt in drei Schritten:
1. Die Daten aus dem IDoc werden in das R/3-System eingelesen und im Bankdatenspeicher
bzw. in der Avisdatenbank gespeichert. Das Customizing zum Kontoauszug wird
ausgewertet und der Kontoauszug wird um diese Daten ergänzt (Buchungsregeln,
Buchungskreis, Daten zum Hausbankkonto usw.).
Anschließend werden die Gutschrifts- und Belastungsanzeigen gesucht, die im
Kontoauszug referenziert sind, und im Kontoauszug wird der zugehörige Schlüssel der
Avisdatenbank hinterlegt. Das System gewinnt über die Avise die Informationen für den
Zahlungsausgleich. Die Avise können die Belegnummer, aber auch jedes andere
Kriterium enthalten, das der Anwender wünscht.
Enthält die Gutschrifts- bzw. Belastungsanzeige keine detaillierten Daten (keine
Avispositionen), so werden die Daten in die Position des Kontoauszugs übertragen und
das Avis wird anschließend gelöscht.

74 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Kontoauszugs (FI-BL-PT-BS)

2. Um die Buchungen zu erzeugen, die aus dem Kontoauszug resultieren, planen Sie den
Report RFEBKA30 ein.
3. Die nicht automatisch gebuchten Umsätze können Sie mit Hilfe der
Nachbearbeitungstransaktion des elektronischen Kontoauszugs (FEBA) ergänzen und dann
buchen.

Wenn es sich bei dem Kontoauszug um eine Abfrage des Kontostandes handelt
(Polling Information), werden in Schritt 1 die Informationen im Bankdatenspeicher
in einem gesonderten Bereich abgelegt .In Schritt 2 werden keine Buchungen,
sondern Avise der Finanzdisposition erzeugt. In Schritt 3 können Sie den
Kontoauszug mit dem Report RFEBPI20 nachbearbeiten.
Ausnahmebehandlung
Im Fehlerfall erzeugt das System ein Workitem (die Aufgabe FINSTA_ERROR wird gestartet)
und ermittelt den Bearbeiter über die Standardmethode der IDoc-Schnittstelle [Extern].

Achten Sie darauf, daß bei den Grunddaten zum Workflow ein Administrator
hinterlegt ist, der im Fehlerfall automatisch benachrichtigt werden kann. Wählen Sie
dazu vom Einstiegsbild aus Werkzeuge ® Business Workflow ® Entwicklung ®
Definitionswerkzeuge ® Aufgaben/Aufgabengruppen ® Ändern.
Modifikation der Daten mittels Customer-Function
Bei der Verarbeitung des IDocs kann über definierte Schnittstellen lesend oder ändernd auf den
Datenbestand zugegriffen werden. Dazu werden mehrere Customer-Functions unterstützt, die zu
bestimmten Zeitpunkten aufgerufen werden. Die Funktionsbausteine sind in der Erweiterung
'FEDI0005' abgelegt. Weitere Informationen finden Sie im Einführungsleitfaden der
Bankbuchhaltung unter Geschäftsvorfälle ® Zahlungsverkehr ® Elektronischer Kontoauszug ®
Erweiterungen für el. Kontoauszug entwickeln (formatspez.).
Die folgenden Customer-Functions werden bei der Verarbeitung von IDocs des Typs FINSTA01
aufgerufen und können für Kundenmodifikationen verwendet werden:
· Sichern eines Kontoauszuges
Der Funktionsbaustein 201 wird unmittelbar vor dem Schreiben der Daten eines
Kontoauszuges aufgerufen. Detailinformation finden Sie in der Dokumentation zum
Funktionsbaustein EXIT_SAPLIEDP_201 in der Erweiterung FEDI0005 (Transaktion
CMOD).
· Dynamische Aufrufe
Es ist ebenfalls möglich, beim Schreiben einzelner Segmente per Customer-Function auf
den Datenbestand zuzugreifen. Dazu ist zunächst zu definieren, bei welchen Segmenten
ein entsprechender Aufruf erfolgen soll.
Pflegen Sie dazu zunächst die Tabelle 'FEDICUS'.
Der Funktionsbaustein '202' wird nun fuer die Verarbeitung der in der Tabelle FEDICUS
angegebenen Segmente aufgerufen. Detailinformation finden Sie in der Dokumentation
zum Funktionsbaustein EXIT_SAPLIEDP_202 in der Erweiterung FEDI0005.

April 2001 75
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Kontoauszugs (FI-BL-PT-BS)

Die Erweiterung FEB00001 des elektronischen Kontoauszuges wird auch beim IDoc-
Eingang durchlaufen (Der Report RFEBKA30 ruft den Report RFEBBU10 auf (dort
wird der User-Exit aufgerufen)). Es ist also nicht notwendig, das ggf. dort hinterlegte
Coding in eine der Custumer-Functions der Erweiterung FEDI0005 zu übertragen.

76 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang von Lockbox-Daten (FI-BL-PT-LB)

EDI-Eingang von Lockbox-Daten (FI-BL-PT-LB)


Verwendung
Lockbox [Extern]-Daten, die bisher mittels Datenfernübertragung von der Hausbank oder einem
Lockbox-Provider abgeholt wurden, können nun per EDI empfangen werden. So gelangen diese
Daten automatisch in das System und können dort weiterverarbeitet werden, d.h. die
Forderungen des Debitoren werden mit den eingehenden Zahlungen ausgeglichen.

Voraussetzungen
Anwendung
· Bank als EDI-fähig kennzeichnen
Diesen Schritt müssen Sie vor der Pflege der Partnervereinbarungen ausführen, da nur
dort die EDI-fähigen Banken ausgewählt werden können.
Dazu gehen Sie folgendermaßen vor:
a. Wählen Sie im Einführungsleitfaden Bankbuchhaltung ® Bankkonten ® Hausbanken
definieren.
b. Führen Sie den Arbeitsschritt aus.
c. Geben Sie einen Buchungskreis ein und wählen Sie Springen ® Hausbanken.
d. Wählen Sie die gewünschte Bank per Doppelklick.
e. Wählen Sie Springen ® DTA.
f. Geben Sie eine Partnernummer ein (z.B. den Bankschlüssel).
Von hier aus können Sie die Partnervereinbarungen erreichen. Was Sie dort hinterlegen,
lesen Sie im Abschnitt IDoc-Schnittstelle.
· Einstellungen im Customizing der Lockbox vornehmen
Weitere Informationen dazu finden Sie im Einführungsleitfaden der Bankbuchhaltung
unter Geschäftsvorfälle ® Zahlungsverkehr ® Lockbox
Steuerungsparameter hinterlegen [Extern]
Buchungsstoff hinterlegen [Extern]
Weitere Informationen zur Lockbox finden Sie in der R/3-Bibliothek unter Finanzwesen
® Bankbuchhaltung ® Zahlungsverkehr ® Lockbox.
· ISO-Codes hinterlegen
Da per EDI ISO-Codes übermittelt werden, müssen Sie im Customizing die Umsetzung
der SAP-Codes in ISO-Codes für die Währung, die Mengeneinheit und die Länder
korrekt und vollständig hinterlegt haben.
Weitere Informationen hierzu finden Sie im Einführungsleitfaden Globale Einstellungen
® Länder definieren [Extern], Währungscodes überprüfen [Extern], Maßeinheiten
überprüfen [Extern].
IDoc-Schnittstelle
Hinterlegen Sie folgende Parameter in den Eingangs-Partnervereinbarungen:

April 2001 77
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang von Lockbox-Daten (FI-BL-PT-LB)

Feld Wert
Nachrichtentyp FINSTA01
Logische Nachricht LOCKBX
Partnerart B
Vorgangscode LOBX
Verarbeitung z.B. sofortige Verarbeitung
Erlaubter Bearbeiter Organisationseinheit (z.B. ein R/3-Benutzer)

Aktivitäten
Eingangsverarbeitung
Die Verarbeitung der Lockbox-Daten erfolgt in drei Schritten:
1. Die Daten aus dem IDoc werden in das R/3-System eingelesen und im Bankdatenspeicher
gespeichert. Das Customizing der Lockbox wird ausgewertet und diese Daten werden den
Lockbox-Daten hinzugefügt (Buchungsregeln, Buchungskreis, Daten zum Hausbankkonto
usw.).
2. Um die Buchungen für die Debitoren- und Hauptbuchhaltung zu erzeugen, die sich aus den
Lockbox-Daten ergeben, planen Sie den Report RFEBLB30 ein.
3. Führen Sie die Transaktion FLB1 aus, um die Lockbox-Daten (Schecks) nachzubearbeiten.
Im Rahmen der Nachbearbeitung verzweigen Sie in die Bearbeitung von Avisen, wo Sie
Ausgleichsinformationen ändern, hinzufügen oder löschen können.
Ausnahmebehandlung
Im Fehlerfall erzeugt das System ein Workitem (die Aufgabe LOCKBX_ERROR wird gestartet)
und ermittelt den Bearbeiter über die Standardmethode der IDoc-Schnittstelle [Extern].

Achten Sie darauf, daß bei den Grunddaten zum Workflow ein Administrator
hinterlegt ist, der im Fehlerfall automatisch benachrichtigt werden kann. Wählen Sie
dazu vom Einstiegsbild aus Werkzeuge ® Business Workflow ® Entwicklung ®
Definitionswerkzeuge ® Aufgaben/Aufgabengruppen ® Ändern.
Modifikation der Daten mittels Customer-Function
Wenn ein IDoc vom Typ FINSTA01 verarbeitet wird, können Sie über folgende Customer-
Functions lesend oder ändernd auf den Datenbestand zugreifen:
· Sichern der Lockboxdaten (Aufruf des Funktinsbausteins 201)
Der Funktionsbaustein wird unmittelbar vor dem Schreiben der Lockboxdaten
aufgerufen. Weitere Informationen finden Sie in der Dokumentation zum
Funktionsbaustein EXIT_SAPLIEDP_201 in der Erweiterung FEDI0005.
· Dynamische Aufrufe
Sie können beim Schreiben einzelner Segmente auf den Datenbestand zugreifen.
Definieren Sie dazu, bei welchen Segmenten ein entsprechender Funktionsbaustein
aufgerufen werden soll. Pflegen Sie dazu die Tabelle FEDICUS. Der Funktionsbaustein

78 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang von Lockbox-Daten (FI-BL-PT-LB)

202 wird nur für die Verarbeitung der Segmente aufgerufen, die in der Tabelle FEDICUS
angegeben sind. Weitere Informationen finden Sie in der Dokumentation zum
Funktionsbaustein EXIT_SAPLIEDP_202 in der Erweiterung FEDI0005.

Die Erweiterung FEBLB001 für Lockboxdaten wird auch beim IDoc-Eingang


durchlaufen. (Der Report RFEBLB30 ruft den Report RFEBLB20 auf, der die
Customer-Exits aufruft.) Es ist also nicht notwendig, das dort hinterlegte Coding in
eine der Customer-Functions der Erweiterung FEDI0005 zu übertragen.

April 2001 79
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand von Zahlungen (FI-AP-AP-PT)

EDI-Versand von Zahlungen (FI-AP-AP-PT)


Verwendung
Sie können einen Bestand an offenen Posten (Rechnungen) Ihrer Kreditoren, die Sie begleichen
möchten, oder einen Bestand an offenen Posten Ihrer Debitoren, die Sie einziehen möchten, mit
dem Zahlprogramm [Extern] generieren. Diesen Regulierungsbestand können Sie per EDI an
Ihre Hausbank übermitteln.

Voraussetzungen
Anwendung
· Customizing zum Zahlprogramm
Weitere Informationen dazu finden Sie im Einführungsleitfaden der Debitoren- und
Kreditorenbuchhaltung unter Geschäftsvorfälle ® Zahlungsausgang ®
Zahlungsausgang automatisch ® Zahlweg-/Bankenauswahl ® Zahlungsprogramm
einrichten [Extern].
· Bank als EDI-fähig kennzeichnen
Diesen Schritt müssen Sie vor der Pflege der Partnervereinbarungen ausführen, da nur
dort die EDI-fähigen Banken ausgewählt werden können.
Dazu gehen Sie folgendermaßen vor:
a. Wählen Sie im Einführungsleitfaden Bankbuchhaltung ® Bankkonten ® Hausbanken
definieren.
b. Führen Sie den Arbeitsschritt aus.
c. Geben Sie einen Buchungskreis ein und wählen Sie Springen ® Hausbanken.
d. Wählen Sie die gewünschte Bank per Doppelklick.
e. Wählen Sie Springen ® DTA.
f. Geben Sie eine Partnernummer ein (z.B. den Bankschlüssel).
Von hier aus können Sie die Partnervereinbarungen erreichen. Was Sie dort hinterlegen,
lesen Sie im Abschnitt IDoc-Schnittstelle.
· EDI-fähige Zahlwege definieren
Führen Sie die Schritte a. bis f. durch, wie oben beschrieben. Von Schritt f. aus können
Sie die EDI-fähigen Zahlwege erreichen.
· ISO-Codes hinterlegen
Da per EDI ISO-Codes übermittelt werden, müssen Sie im Customizing die Umsetzung
der SAP-Codes in ISO-Codes für die Währung, die Mengeneinheit und die Länder
korrekt und vollständig hinterlegt haben.
Weitere Informationen hierzu finden Sie im Einführungsleitfaden Globale Einstellungen
® Länder definieren [Extern], Währungscodes überprüfen [Extern], Maßeinheiten
überprüfen [Extern].
IDoc-Schnittstelle

80 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand von Zahlungen (FI-AP-AP-PT)

Pflegen Sie die Ausgangs-Partnervereinbarungen mit folgenden Werten:


Feld Wert
Zahlungsauftrag
Nachrichtentyp PAYEXT
Partnerart B
Port z.B. Subsystem
Basistyp PEXR2001, PEXR2002 [Extern]
Referenznachricht für elektronische Unterschrift
Nachrichtentyp EUPEXR
Partnerart B
Port z.B. Subsystem
Basistyp IDCREF01
Bankeinzug
Nachrichtentyp DIRDEB
Partnerart B
Port z.B. Subsystem
Basistyp PEXR2001, PEXR2002 [Extern]

Aktivitäten
1. Erzeugen Sie mit dem Zahlungsprogramm [Extern] einen Regulierungsbestand.
2. Starten Sie das Zahlungsträgerprogramm RFFOEDI1 bzw. planen Sie es über das
Zahlprogramm ein. Es erzeugt die Ausgangs-IDocs. Weitere Informationen finden Sie in der
Dokumentation zum Report.
Pro Zahlungsbeleg wird ein PAXEXT-IDoc erzeugt. Das EUPEXR-IDoc ist die logische
Klammer um alle Zahlungsaufträge.

Stellen Sie sicher, daß zeitlich parallel zu RFFOEDI1 keine weiteren


Zahlungsträgerprogramme auf denselben Datenbestand zugreifen. Bei Einplanung
durch das Zahlprogramm wird RFFOEDI1 deshalb vor allen anderen
Zahlungsträgerprogrammen gestartet.
Sofern Sie eine oder mehrere Zahlungen per EDI nicht durchführen konnten, können
Sie den EDI-Status der Zahlungsbelege mit dem Report RFFOEDI2 modifizieren.
Damit können Sie die Zahlungsbelege erneut per EDI versenden, oder einen
konventionellen Datenträger erstellen. Weitere Informationen entnehmen Sie der
Dokumentation des Reports RFFOEDI2.
Ausnahmebehandlung

April 2001 81
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand von Zahlungen (FI-AP-AP-PT)

Wenn Sie den Standard-Workflow verwenden, müssen Sie bei den Grunddaten zum Workflow
einen Administrator hinterlegen, der im Fehlerfall automatisch benachrichtigt werden kann.

82 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Qualitätszeugnis (QM-CA)

Qualitätszeugnis (QM-CA)
Einsatzmöglichkeiten
Der Lieferant verschickt ein Qualitätszeugnis per EDI an seinen Kunden. Das Zeugnis wird mit
einer digitalen Signatur versehen.

Ablauf
EDI-Versand eines Qualitätszeugnisses (QM-CA) [Seite 84]
EDI-Eingang eines Qualitätszeugnisses (QM-CA) [Seite 86]

April 2001 83
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Qualitätszeugnisses im PDF-Format (QM-CA)

EDI-Versand eines Qualitätszeugnisses im PDF-Format


(QM-CA)
Verwendung
Im EDI-Szenario versenden Sie ein Qualitätszeugnis im PDF-Format per EDI an Ihren Kunden.
Das erzeugte IDoc erhält automatisch eine digitale Signatur. Damit kann das Zeugnis gegen
jegliche Änderung während des Versands geschützt werden.

Voraussetzungen
Anwendung
Für den Zeugnisversand gelten folgende Voraussetzungen:
· Das Datenvolumen des Qualitätszeugnisses beträgt maximal 500 KB.

Im Kundenauftrag sollte auf dem Lieferpositionsdetail die Bestellposition oder die


Kundenmaterialnummer angegeben sein. Wenn die Bestellposition nicht angegeben
ist, kann diese beim Zeugniseingang [Seite 86] über eine Kundenerweiterung
zugeordnet werden.

Nachrichtensteuerung
Folgende Konditionselemente müssen angelegt sein:
Konditionselement Wert
Nachrichtenart LQCA, LQCB
Applikation V2
Schema V20001
Sendemedium 6 (EDI)
Zugriffsfolge 0003, 0008
Partnerrolle AG (Auftraggeber) und WE (Warenempfänger)
Wählen Sie dazu im Customizing des Qualitätsmanagements (QM) unter Qualitätszeugnis:
· Nachrichtenfindung
· Nachrichtenverarbeitung

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:
Feld Wert
Nachrichtentyp QCERT

84 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines Qualitätszeugnisses im PDF-Format (QM-CA)

Partnerart KU (Kunde)
Partnerrolle WE, AG, Q1 oder Q2
Empfängerport z.B. SUBSYSTEM
Ausgabemodus z.B. IDocs sofort übergeben
Basistyp QALITY01
Vorgangscode QCERT_OUT

Aktivitäten
Sie kommissionieren eine Lieferung zum Zeugnisempfänger. Bei der Kommissionierung wird das
Qualitätszeugnis entweder sofort versendet oder regelmäßig im Hintergrund verarbeitet.

April 2001 85
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Qualitätszeugnisses im PDF-Format (QM-CA)

EDI-Eingang eines Qualitätszeugnisses im PDF-Format


(QM-CA)
Verwendung
Im EDI-Szenario empfangen und verarbeiten Sie ein Qualitätszeugnis im PDF-Format, das von
einem Lieferanten von einem R/3-System an Sie verschickt wurde. Mit der Überprüfung der
digitalen Signatur wird die Übereinstimmung des eingegangenen Zeugnisses mit dem
versandten Dokument sichergestellt. Das eingegangene Zeugnis wird anschließend mit SAP
ArchiveLink abgelegt.

Wenn keine Bestellposition zu den Belegdaten zugeordnet werden konnte oder das
Material nicht zeugnispflichtig ist, wird das Zeugnis zentral abgelegt und über SAP
Business Workflow an die zuständigen Sachbearbeiter zur Zuordnung weitergeleitet.

Voraussetzungen
Anwendung
Zur Verarbeitung des eingegangenen Qualitätszeugnisses gelten folgende Voraussetzungen:
· Das Liefermaterial, zu dem das Qualitätszeugnis übertragen wird, ist zeugnispflichtig.
· Die Belegdaten (Materialnummer, Bestellposition, Charge) ermöglichen eine eindeutige
Zuordnung zur Bestellung.

Wenn die Bestellposition im IDoc nicht angegeben ist, können Sie diese über die
Kundenerweiterung QCE10001 zuordnen.
Zur Überprüfung der digitalen Signatur gelten folgende Voraussetzungen:
· In den Stammdaten zum Kreditor ist die SSF-ID unter Weitere Kommunikation angelegt.
· Der öffentliche Schlüssel (Public Key) des Kreditors ist in Ihrem externen Sicherheitsprodukt
unter der SSF-ID abgelegt.
Um ein eingegangenes Zeugnis über SAP Business Workflow an die zuständigen
Sachbearbeiter zur Zuordnung weiterleiten zu können, gilt folgende Voraussetzung:
· Der Dokumentenart QMICERTPDF sind ein oder mehrere Bearbeiter zugeordnet und die
erforderlichen Voreinstellungen gemacht.

Um der Dokumentenart QMICERTPDF Bearbeiter zuzuordnen und die erforderlichen


Voreinstellungen zu machen, wählen Sie Werkzeuge ® Business Documents ®
Sonstiges ® Voreinstellungen.

IDoc-Schnittstelle
In den Partnervereinbarungen Eingang sind folgende Werte gepflegt:

86 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Qualitätszeugnisses im PDF-Format (QM-CA)

Feld Wert
Nachrichtentyp QCERT
Partnerart LI (Lieferant)
Partnerrolle LF
Empfängerport z.B. SUBSYSTEM
Basistyp QALITY01
Vorgangscode QCERT_IN

Aktivitäten
Das IDoc geht entweder über den Internet-Port als Anlage zu einem E-Mail oder über das
Subsystem ein. Über die Verwaltungsdaten sucht das System einen bestehenden Zeugnissatz
und legt das zugehörige Zeugnis in SAP ArchiveLink ab. Wenn kein Zeugnissatz dazu existiert,
wird ein neuer Zeugnissatz angelegt und das Zeugnis dazu abgelegt.
Siehe auch:
Ablegen eingehender Zeugnisse (QM-CA) [Extern]

April 2001 87
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

EDI-Versand eines Qualitätszeugnisses mit Datenzugriff


(QM-CA)
Verwendung
Im EDI-Szenario versenden Sie die auf einem Qualitätszeugnis ausgegebenen Prüfergebnisse in
formatierter Form an Ihren Kunden. Dabei können Sie das Qualitätszeugnis zusätzlich als PDF
mitversenden.
Grundsätzlich kann sich das Qualitätszeugnis auf eine Lieferung, ein Prüflos oder eine Charge
beziehen. Die Übertragung der Qualitätszeugnisdaten ist also nicht zwangsläufig an eine
Bestellung bzw. Lieferung gebunden. Vielmehr können auch Ergebnisse von Qualitätsprüfungen,
die aus Sicht des Empfängers extern durchgeführt wurden, an das Empfängersystem geschickt
und dort flexibel weiterverwendet werden. Weitere Informationen finden Sie unter EDI-Eingang
eines Qualitätszeugnisses mit Datenzugriff (QM-CA) [Seite 93].
Das Zeugnis im PDF-Format erhält automatisch eine digitale Signatur. Damit können die Daten
gegen jegliche Änderung während des Versands geschützt werden.

Voraussetzungen
Anwendung
Für den Versand der Qualitätszeugnisdaten gelten folgende Voraussetzungen:
· Beim Absender (Lieferanten)
- werden Zeugnisvorlagen sowie Klassenmerkmale oder Stammprüfmerkmale verwendet
- ist im Falle von unterschiedlichen Merkmalsbezeichnungen auf Kunden- und
Lieferantenseite in der Merkmalsmappingtabelle [Extern] eine eindeutige Zuordnung der
Merkmale gewährleistet
- sind die Adressdaten des Kunden in der EDI-Partnervereinbarung definiert

Bei der Übertragung von Qualitätszeugnisdaten zu einer Lieferung sollte im


Kundenauftrag auf dem Lieferpositionsdetail die Bestellposition oder die
Kundenmaterialnummer angegeben sein, um die Zuordnung der Lieferung zur
Bestellung beim Kunden zu erleichtern.

Nachrichtensteuerung
Folgende Konditionselemente müssen angelegt sein:
Konditionselement Wert
Nachrichtenart LQCA, LQCB
Applikation V2
Schema V20001
Sendemedium 6 (EDI)
Zugriffsfolge 0003, 0008

88 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

Partnerrolle AG (Auftraggeber) und WE (Warenempfänger)


Wählen Sie dazu im Customizing des Qualitätsmanagements (QM) unter Qualitätszeugnis:
· Nachrichtenfindung
· Nachrichtenverarbeitung

IDoc-Schnittstelle
Sie müssen sowohl die Ausgangspartnervereinbarungen als auch die zusätzlichen
Partnervereinbarungen beim Ausgang unter Nachrichtensteuerung mit folgenden Werten
pflegen:
Feld Wert
Nachrichtentyp QCERT
Partnerart KU (Kunde)
Partnerrolle WE, AG, Q1 oder Q2
Empfängerport z.B. SUBSYSTEM
Ausgabemodus z.B. IDocs sofort übergeben
Basistyp QALITY02
Applikation V2
Nachrichtenart LQCA/LQCB
Vorgangscode QCERT_OUT

Funktionsumfang
Die Kommunikation erfolgt im R/3 über die IDoc-Schnittstelle. Dabei werden ausgehende und
eingehende IDocs auf der Datenbank gespeichert und später im Ablagesystem verwaltet. Der
technische Übertragungsweg kann partnerbezogen festgelegt werden. Grundsätzlich kann die
Kommunikation erfolgen:
· zwischen zwei R/3-Systemen
· zwischen einem Fremdsystem auf Lieferantenseite und einem R/3-System auf Kundenseite
· zwischen einem R/3-System auf Lieferantenseite und einem Fremdsystem auf Kundenseite

April 2001 89
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

A: Kommunikation zwischen zwei R/3-Systemen

Lieferant Kunde

IDoc IDoc R/3


Belegdaten Belegdaten Zeugnis-
satz
EDI
R/3 Qualitäts- Qualitäts-
XML Prüflos
Zeugnis- zeugnisdaten zeugnisdaten
erstellung
Mail
Zeugnis Zeugnis
als als
PDF PDF Zeugnis
als PDF

Ablagesystem

Ablagesystem Ablagesystem

90 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Versand eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

B: Kommunikation zwischen Fremdsystem (Lieferant) und R/3-System (Kunde)

Lieferant Kunde

IDoc R/3
EDI Belegdaten Zeugnis-
EDI-Konverter satz
Zeugnis-
erstellung
XML-Konverter, Qualitäts- Prüflos
Business Connector zeugnisdaten
XML

Zeugnis
als
PDF Zeugnis
als PDF

Ablagesystem

Ablagesystem

April 2001 91
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Versand eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

C: Kommunikation zwischen R/3-System (Lieferant) und Fremdsystem (Kunde)

Lieferant Kunde

IDoc
Belegdaten EDI
EDI-Konverter
Zeugnis-
R/3 erfassung
Qualitäts- XML-Konverter,
Zeugnis- zeugnisdaten Business Connector
erstellung XML

Zeugnis
als
PDF

Ablagesystem

92 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

EDI-Eingang eines Qualitätszeugnisses mit Datenzugriff


(QM-CA)
Verwendung
Im EDI-Szenario empfangen und verarbeiten Sie
· die auf einem Qualitätszeugnis ausgegebenen Prüfergebnisse (Qualitätszeugnisdaten), die
Sie in ein vorhandenes Prüflos übernehmen können sowie
· optional ein Qualitätszeugnis im PDF-Format [Seite 86]
Grundsätzlich kann sich das als IDoc eingegangene Zeugnis auf eine Lieferung, ein Prüflos oder
eine Charge beziehen. Die Übertragung der Qualitätszeugnisdaten ist also nicht zwangsläufig an
eine Bestellung bzw. Lieferung gebunden. Vielmehr können auch Ergebnisse von
Qualitätsprüfungen, die aus Sicht des Empfängers extern durchgeführt wurden, an das
Empfängersystem geschickt und dort flexibel weiterverwendet werden.
Bei der Übertragung der Qualitätszeugnisdaten mit Bezug zu einer Lieferung bzw. zu einer
Bestellung können die Daten beim Empfänger - ausgelöst durch einen Wareneingang -
automatisch in ein Wareneingangsprüflos übernommen werden. Neben dieser automatisch
ausgelösten Datenübernahme ist es auch möglich, die Qualitätszeugnisdaten über Funktionen
beim Zeugniseingang [Extern] manuell in ein beliebiges Prüfos zu übernehmen. So können Sie
z.B. die Qualitätszeugnisdaten bereits vor einem Wareneingang in ein Abnahmeprüflos
übernehmen und so bereits in diesem Stadium eine Beurteilung der Ware durchführen.
Bei der Übertragung der Qualitätszeugnisdaten mit Bezug zu einer Charge oder einem Prüflos
können Sie die Daten über SAP Business Workflow direkt aus dem IDoc in ein beliebiges Prüflos
übernehmen. Weitere Informationen finden Sie in der Workflow-Dokumentation Datenübernahme
aus einem IDoc in ein Prüflos [Extern].
Mit der Überprüfung der digitalen Signatur wird die Übereinstimmung des eingegangenen
Zeugnisses mit dem versandten Dokument sichergestellt. Das eingegangene Zeugnis wird
anschließend mit SAP ArchiveLink abgelegt.

Voraussetzungen
Anwendung: Allgemein
Funktion Voraussetzung Anmerkung
Überprüfung der digitalen In den Stammdaten zum
Signatur Kreditor ist die SSF-ID unter
Weitere Kommunikation
angelegt.
Der öffentliche Schlüssel
(Public Key) des Kreditors ist
in Ihrem externen
Sicherheitsprodukt unter der
SSF-ID abgelegt.

April 2001 93
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
EDI-Eingang eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

Identifikation und eindeutige In der Partnereinstellung zum Ein Merkmalsmapping ist dann
Zuordnung der zu Qualitätsdatenaustausch ist erfoderlich, wenn die
übertragenden die Merkmalsmapping- Bezeichnungen der Merkmale
Qualitätszeugnisdaten Tabelle gefüllt. Weitere bei Sender und Empfänger
zwischen Sender und Informationen finden Sie unterschiedlich sind.
Empfänger unter Merkmalsmapping
(Merkmalsmapping) [Extern] für die Übertragung
von Qualitätszeugnisdaten.
Übernahme der Die Komponente SAP Weitere Informationen finden
Qualitätszeugnisdaten Business Workflow ist aktiv. Sie unter in der Workflow-
Dokumentation
Datenübernahme aus einem
IDoc in ein Prüflos [Extern].

Im Plan bzw. in der Weitere Informationen zur


Materialspezifikation ist Übernahme der
eingestellt, daß die Qualitätszeugnisdaten bei
Ergebnisdaten aus dem Materialspezifikation finden
Zeugnis übernommen werden Sie unter Werte zum
sollen. Stammprüfmerkmal [Extern];
bei Plan unter Funktionen in
der Prüfmerkmalsübersicht
[Extern].

Anwendung: Zeugnis zur Lieferung


Funktion Voraussetzung Anmerkung
Verarbeitung des Das Liefermaterial, zu dem Wenn keine Bestellposition zu
eingegangenen das Qualitätszeugnis den Belegdaten zugeordnet
Qualitätszeugnisses zur übertragen wird, ist werden konnte oder das
Lieferung (PDF-Format) zeugnispflichtig. Material nicht zeugnispflichtig
ist, wird das Zeugnis zentral
Die Belegdaten
abgelegt und über SAP
(Materialnummer,
Business Workflow an die
Bestellposition, Charge)
zuständigen Sachbearbeiter
ermöglichen eine eindeutige
zur Zuordnung weitergeleitet.
Zuordnung zur Bestellung.
Wenn die Bestellposition im
IDoc nicht angegeben ist,
können Sie diese über die
Kundenerweiterung
QCE10001 zuordnen.
Übernahme der Im Q-Infosatz in der
Qualitätszeugnisdaten in ein Beschaffung ist in der
Wareneingangsprüflos Prüfsteuerung der Eintrag
Elektronisches Zeugnis mit
Datenübernahme oder
Elektronisches Zeugnis ohne
PDF mit Datenübernahme
eingestellt.

94 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
EDI-Eingang eines Qualitätszeugnisses mit Datenzugriff (QM-CA)

IDoc-Schnittstelle
In den Partnervereinbarungen Eingang sind folgende Werte gepflegt:
Feld Wert
Nachrichtentyp QCERT
Partnerart LS
Partner Logisches System des Lieferanten
Empfängerport z.B. SUBSYSTEM
Basistyp QALITY02
Vorgangscode QCERT_IN

Funktionsumfang
Der Zeugniseingang zur Lieferung wird durch folgende Grafik veranschaulicht:

A: Elektronischer Zeugniseingang beim Qualitätszeugnis zur Lieferung

Eingang

IDoc Automatisch in WE-Prüflos:


Steuerung über
Belegdaten
Q-Infosatz

WE-Prüflos
Qualitäts-
zeugnisdaten
Manuell
zum Befüllen
eines beliebigen Prüfloses:
Über Menüfunktion Prüflos
Zeugnis als • Prüflos befüllen
PDF • Übernahmeprotokolle

Zeugnis Qualitätszeugnis-
als PDF eingang anzeigen/ändern

Ablagesystem

Beim Eingang eines nicht bestellbezogenen elektronischen Zeugnisses (Zeugnis zum Prüflos
oder zur Charge) wird ein Workflow gestartet, der die Datenübernahme in ein beliebiges Prüflos
erlaubt.

April 2001 95
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Vendor-Managed-Inventory (VMI)

Vendor-Managed-Inventory (VMI)
Einsatzmöglichkeiten
Dieses Szenario beschreibt, wie ein Lieferant die Disposition für seine Artikel im Unternehmen
eines Kunden als Dienstleistung übernimmt. Voraussetzung für diese Dienstleistung ist, daß der
Lieferant Zugriff auf Bestands- und Abverkaufsdaten aus dem Unternehmen des Kunden hat.
In einem R/3-System können Sie Vendor-Managed-Inventory (VMI) sowohl aus Sicht eines
Lieferanten als auch aus Sicht eines Kunden realisieren. Ein typischer Anwendungsfall für VMI
ist z.B. die Disposition von Konsumgütern in einem Handelsunternehmen durch den Hersteller
dieser Güter.
Sie können die Funktionen für VMI auch unabhängig voneinander und ggf. auch in einem
anderen Zusammenhang als VMI verwenden.

Integration
Die folgenden R/3-Komponenten kommen dabei zum Einsatz:
Komponente Funktion
Lieferant (im System des Kunden) Senden von Bestands- und
Abverkaufsdaten
Kundenauftrag (im System des Empfangen von Bestands- und
Lieferanten) Abverkaufsdaten über EDI
Durchführen der Nachschubplanung für
Kunden
Einkauf (im System des Kunden) Anlegen einer Bestellung zu einer per EDI
eingehenden Bestellbestätigung

Ablauf
Es wird angenommen, daß der Lieferant und der Kunde jeweils ein R/3-System einsetzen.

96 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Vendor-Managed-Inventory (VMI)

Kunde Lieferant

1. Bestands- und Abverkaufs-


daten über EDI senden.
2. Bestands- und Abverkaufs
daten über EDI empfangen.

3. Nachschubplanung für
Kunden durchführen.
4. Bestellung zur über EDI Kundenauftrag generieren
eingehenden Bestell- und dazu Bestellbestätigung
bestätigung generieren. über EDI senden.
optional:
Bestellnummer über EDI an
den Kunden zurücksenden.
5. optional:
Bestellnummer in
Kundenauftrag eintragen.

1. Senden von Bestands- und Abverkaufsdaten über EDI


Der Kunde sendet über den Nachrichtentyp PROACT historische oder prognostizierte
Abverkaufsdaten und den aktuellen Bestand eines bestimmten Artikels an den
Lieferanten.
Weitere Informationen finden Sie unter Bestände/Abverkäufe an Lieferanten versenden
[Extern].
2. Empfangen von Bestands- und Abverkaufsdaten über EDI
Im System des Lieferanten werden die Abverkaufsdaten des Artikels in der
Informationsstruktur S130 des Informationssystems fortgeschrieben. Die Bestandsdaten
werden in den Nachschubdaten dieses Artikels eingetragen.
3. Durchführen der Nachschubplanung für Kunden
Anhand der Abverkaufsdaten kann der Lieferant eine Prognose der zu erwartenden
Abverkäufe im Unternehmen des Kunden durchführen. Er kann alternativ auch auf
Prognosewerten aufbauen, die ihm der Kunde übermittelt hat.
Auf Basis der aktuellen Bestände und ggf. der Prognosewerte führt der Lieferant eine
Nachschubplanung für den Artikel durch. Die Nachschubplanung errechnet den Bedarf
und generiert einen Kundenauftrag als Folgebeleg.
Die Kundenauftragsdaten werden als Bestellbestätigung per EDI an den Kunden
gesendet. Dazu wird der Nachrichtentyp ORDRSP verwendet.
Weitere Informationen finden Sie unter Kundennachschub [Extern].
4. Generieren einer Bestellung zu einer per EDI eingehenden Bestellbestätigung
Die empfangene Bestellbestätigung des Lieferanten wird im System des Kunden
verarbeitet und in eine entsprechende Bestellung umgesetzt. Wenn keine Bestellung
generiert werden kann, z.B. weil die Daten unvollständig sind, wird ein Workflow
angestoßen.

April 2001 97
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Vendor-Managed-Inventory (VMI)

Wenn zu einem späteren Zeitpunkt Folgenachrichten zu diesem Vorgang vom


Lieferanten an den Kunden gesendet werden sollen (z.B. Auftragsänderungsmitteilungen
oder Lieferavise), muß die Bestellnummer dem System des Lieferanten bekanntgegeben
werden. Das Lieferantensystem kann die Nummer dann als Identifikator in die
Folgenachrichten eintragen und ermöglicht es dadurch dem System des Kunden, sofort
die betroffene Bestellung zu ermitteln.
Wenn die Bestellnummer nach der Bestellgenerierung automatisch an das System des
Lieferanten übertragen werden soll, müssen Sie die Partnervereinbarung für den EDI-
Nachrichtentyp ORDCHG mit der Nachrichtenvariante VMI pflegen.
5. Eintragen der Bestellnummer in den Kundenauftrag
Die Bestellnummer aus dem System des Kunden wird als Referenz in den zugehörigen
Kundenauftrag eingetragen.

98 April 2001
SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
VMI: Senden von Bestands- und Abverkaufsdaten

VMI: Senden von Bestands- und Abverkaufsdaten


Verwendung
Mit dem Report RWVMIPAD können Sie Informationen über historische und prognostizierte
Abverkäufe, aktuelle Bestände und aktuelle offene Bestellmengen von Artikeln per EDI
(Electronic-Data-Interchange) an die Lieferanten der Artikel übermitteln. Sie können vorgeben,
für welche Betriebe und an welche Lieferanten Daten versendet werden sollen. Falls zu
übermittelnde Daten gefunden werden, erzeugt der Report pro Betrieb und Lieferant ein IDoc des
Nachrichtentyps PROACT.
Der Lieferant kann für einen Artikel z.B. die offene Bestellmenge in seinem System mit der im
System des Kunden vergleichen. Mit Hilfe von historischen Abverkaufsdaten kann er eine
Prognose über die zukünftigen Abverkäufe beim Kunden erstellen. Alternativ kann der Kunde
auch prognostizierte Abverkäufe übermitteln, wenn er selbst schon eine Prognose durchgeführt
hat. Ist der Lieferant gleichzeitig auch der Hersteller des Artikels, kann er die Daten zur Planung
und Steuerung seiner Produktion verwenden.

Voraussetzungen
Damit für einen Artikel Abverkaufs- und Bestandsdaten übermittelt werden können, müssen
folgende Voraussetzungen erfüllt sein:
· Für den Artikel ist ein Einkaufsinformationssatz zum Lieferanten, an den gesendet werden
soll, vorhanden.
· Der Artikelstamm ist für den Betrieb, dessen Daten gesendet werden sollen, gepflegt.
· Das System kann für den Artikel ein Steuerprofil ermitteln.
Die Einstellungen für ein Steuerprofil nehmen Sie im Customizing vor. Sie können einem
Lieferanten im Lieferantenstamm ein Steuerprofil auf der Einkaufsorganisationsebene
zuordnen. Wenn Sie abweichende Daten auf einer anderen Ebene gepflegt haben,
können Sie dort ebenfalls ein Steuerprofil hinterlegen. Für abweichende Daten kommen
folgende Ebenen in Frage:
- Einkaufsorganisation, Lieferantenteilsortiment und Betrieb
- Einkaufsorganisation und Lieferantenteilsortiment
- Einkaufsorganisation und Betrieb
Das System prüft zunächst, ob abweichende Daten vorhanden sind. Ist das der Fall, wird
in der oben angegebenen Reihenfolge die am stärksten spezialisierte Ebene ermittelt. Ist
dort ein Steuerprofil gepflegt, wird dieses verwendet. Ist dort kein Steuerprofil gepflegt,
wird das Steuerprofil auf der Einkaufsorganisationsebene verwendet. Falls dort ebenfalls
kein Steuerprofil vorhanden ist, wird das Default-Steuerprofil verwendet, das Sie auf dem
Selektionsbild des Reports angeben können.
· Der Artikel erfüllt die Kriterien des Selektionsschlüssels aus dem ermittelten Steuerprofil.

April 2001 99
IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
VMI: Empfangen von Bestands- und Abverkaufsdaten

VMI: Empfangen von Bestands- und Abverkaufsdaten


Verwendung
Ein R/3-System kann Bestands- und Abverkaufsdaten, die über den Nachrichtentyp PROACT
per EDI übermittelt werden, empfangen und verarbeiten. Durch diese Funktion kann z.B. ein
Hersteller die aktuellen Bestands- und Abverkaufsdaten eines Kunden erhalten, um für diesen
Kunden eine Nachschubplanung durchzuführen.

Integration
Die empfangenen Daten werden im Informationssystem und in den Nachschubartikeldaten
fortgeschrieben.

Voraussetzungen
· Für das Unternehmen, das Ihnen Daten sendet, müssen Sie Kundenstammdaten pflegen.
Sie müssen einen Kundenstamm anlegen, dem Sie die Partnerolle des Auftraggebers
zuweisen. Der Auftraggeber ist gleichzeitig auch der EDI-Partner für den Austausch von
Nachrichten.
· Darüber hinaus müssen Sie für jeden Betrieb im Unternehmen des Kunden, für den Sie eine
Nachschubplanung durchführen wollen, einen eigenen Kundenstamm erfassen. Alle
Kundenstammsätze, die zu einem Unternehmen gehören, müssen genau einem
Vertriebsbereich zugeordnet sein. Die Nummern dieser Stammsätze müssen Sie in den
Partnerrollen des Auftraggebers als Warenempfänger eintragen. Für jeden Warenempfänger
können Sie dessen externe Nummer im Unternehmen des Kunden eintragen, so daß beim
IDoc-Eingang eine Umschlüsselung in die Kundennummer Ihres Systems erfolgen kann.
· Sie müssen für den Kundenstamm, der die Partnerrolle Auftraggeber hat, eine EDI-
Partnervereinbarung pflegen.
· Im Customizing des Vertriebs muß für die Konfiguration von EDI-Partnern eine Zuordnung
des Kunden, der die Partnerrolle Auftraggeber hat, zu einem Vertriebsbereich gepflegt sein.
· Bei der IDoc-Verarbeitung kann die Artikelnummer des Kunden in die entsprechende
Artikelnummer Ihres Systems umgeschlüsselt werden. Zu diesem Zweck müssen Sie eine
Kunden-Artikel-Information anlegen und dort die Artikelnummer des Kunden eintragen.
· Die Nachschubartikeldaten müssen für den jeweiligen Kunden gepflegt sein.

Funktionsumfang
Die empfangenen Daten werden automatisch verarbeitet. Bevor diese Standardverarbeitung
beginnt, wird der User-Exit EXIT_SAPLWVMI_002 aufgerufen, über den Sie Daten ändern und
auf eine individuelle Art verarbeiten können. Über eine spezielle Transaktion können Sie sich die
Daten der eingegangenen IDocs anzeigen lassen.
Die empfangenen Informationen werden in der Standardauslieferung folgendermaßen
verarbeitet:
· Abverkaufsdaten
Die Abverkaufsdaten werden in die Informationsstruktur S130 übernommen. In der
Struktur sind getrennte Felder für Normal- und Aktionsdaten vorhanden. Für die
Fortschreibung von historischen und prognostizierten Daten ist jeweils eine eigene

100 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
VMI: Empfangen von Bestands- und Abverkaufsdaten

Version der Informationsstruktur vorgesehen. In der Auslieferung sind folgende


Versionen eingestellt:
- Ist-Version (für historische Daten): 000
- aktive Version (für prognostizierte Daten): A00
Sie können diese Customizing-Einstellungen in der allgemeinen Steuerung des
Nachschubs (Bereich verbrauchsgesteuerte Disposition) ändern. Die Daten des Senders
werden gemäß der Perioden in der Informationsstruktur des Empfängers umgerechnet.
· Bestandsdaten
Die Bestandsdaten werden in den Artikeldaten des Nachschubs fortgeschrieben und
können z.B. verwendet werden, um den Nachschub für einen Kunden zu planen.
· Bestelldaten
Die noch offene Bestellmenge wird ebenfalls in die Artikeldaten des Nachschubs
übernommen. Sie können sich diese Daten in der Parameterübersicht des Nachschubs
anzeigen lassen.

April 2001 101


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
VMI: Nachschubplanung für Kunden

VMI: Nachschubplanung für Kunden


Verwendung
Mit dieser Funktion können Sie für einen Kunden eine Nachschubplanung durchführen. Das
Ergebnis der Nachschubplanung ist ein Kundenauftrag, den Sie in Form einer Bestellbestätigung
per EDI an den Kunden übermitteln können. Dadurch kann z.B. ein Lieferant Kundenbedarfe
über ein automatisiertes Verfahren berechnen und so die Kunden bedarfsgerecht beliefern.

Integration
Die Bestandsdaten werden aus den Nachschubartikeldaten ermittelt. Die Abverkaufsdaten, die
übe EDI empfangen wurden, werden in der Informationsstruktur S130 des Informationssystems
abgelegt und bei der Nachschubplanung ausgewertet. Vom Kunden übermittelte
Abverkaufsdaten, die sich auf Aktionen beziehen, werden bei der Nachschubplanung nicht
berücksichtigt.

Voraussetzungen
· Für das Unternehmen, das Ihnen Daten sendet, müssen Sie Kundenstammdaten
pflegen. Sie müssen einen Kundenstamm anlegen, dem Sie die Partnerrolle des
Auftraggebers zuweisen. Der Auftraggeber ist gleichzeitig auch der EDI-Partner für den
Austausch von Nachrichten.
Darüber hinaus müssen Sie für jeden Betrieb im Unternehmen des Kunden, für den Sie
eine Nachschubplanung durchführen wollen, einen eigenen Kundenstamm erfassen. Alle
Kundenstammsätze, die zu einem Unternehmen gehören, müssen genau einem
Vertriebsbereich zugeordnet sein. Die Nummern dieser Stammsätze müssen Sie in den
Partnerrollen des Auftraggebers als Warenempfänger eintragen.
· Die Nachschubartikeldaten müssen für den jeweiligen Warenempfänger gepflegt sein.
· Der Kunde muß Ihnen die aktuellen Bestandsinformationen für die zu planenden Artikel
übermittelt haben. Das System kann bei der Nachschubplanung den Sollbestand für den
Kunden mit Hilfe einer Prognose neu berechnen. Für diese Prognose benötigen Sie
zusätzlich die Abverkaufsdaten des Kunden aus den letzten Perioden.
· Damit zu den erzeugten Kundenaufträgen Bestellbestätigungen als EDI-Nachrichten an
die Kunden gesendet werden, müssen Sie die Nachrichtenfindung entsprechend
einstellen.

Funktionsumfang
Die Nachschubplanung gliedert sich in folgende Schritte:

Planung
Bei der Planung werden zunächst die Nachschubbedarfe ermittelt. Hier lassen sich abhängig
vom Dispositionsmerkmal folgende Verfahren unterscheiden:
· Planung mit statischem Sollbestand
Wenn dem Artikel das Dispositionsmerkmal für statischen Sollbestand (Standard RP)
zugewiesen ist, ergibt sich der Bedarf folgendermaßen:
Bedarf = Sollbestand - aktueller Bestand des Kunden

102 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
VMI: Nachschubplanung für Kunden

· Planung mit dynamischem Sollbestand


Wenn dem Artikel das Dispositionsmerkmal für dynamischen Sollbestand (Standard RF)
zugewiesen ist, errechnet das System auf Basis der prognostizierten zukünftigen
Abverkäufe einen neuen Sollbestand. Voraussetzung ist, daß Sie vorher über die flexible
Planung eine Prognose der Abverkäufe erstellt haben oder prognostizierte
Abverkaufsdaten vom Kunden übermittelt worden sind. Der Sollbestand wird
folgendermaßen berechnet:
Sollbestand = Summe der prognostizierten Abverkäufe innerhalb der Sollreichweite +
Sicherheitsbestand
Falls Sie einen minimalen oder maximalen Sollbestand in den Nachschubartikeldaten
angegeben haben, begrenzen diese den Sollbestand. Der Bedarf wird dann analog zur
Planung mit statischem Sollbestand berechnet.
Wenn Sie einen Meldebestand festgelegt haben, wird außerdem geprüft, ob der Bestand den
Meldebestand bereits unterschritten hat. Wenn Sie die Planung im Dialog gestartet haben,
werden die ermittelten Bedarfe angezeigt und können von Ihnen geändert werden.

Folgebeleggenerierung
Im Anschluß an die Bedarfsermittlung werden Kundenaufträge der Kundenauftragsart TAV als
Folgebelege generiert. Im Dialog müssen Sie diesen Vorgang aus der Anzeige der Bedarfe
anstoßen.
Bei der Folgebeleggenerierung findet eine Mengenoptimierung statt, was ggf. zu einer Änderung
der Bedarfsmenge führt. Die Nachschubmenge ergibt sich also aus dem Bedarf nach erfolgter
Optimierung. Wenn ein Kundenauftrag erzeugt worden ist, erhöht sich dadurch der Bestand für
den jeweiligen Kunden.
Der Kundenauftrag wird dann in Form einer Bestellbestätigung (Nachrichtentyp ORDRSP mit
Nachrichtenvariante VMI) per EDI an den Kunden übermittelt. In der Standardauslieferung wird
die Bestellbestätigung zum Kundenauftrag als Nachricht der Nachrichtenart BAV0 erzeugt, für
die Sie die in Ihrem Fall benötigten Konditionssätze im System anlegen müssen.

Nachschubmonitor
Sie können im Customizing in der allgemeinen Steuerung des Nachschubs einstellen, daß die
Nachschubergebnisse auf der Datenbank fortgeschrieben werden sollen. Wenn Sie die
Fortschreibung aktivieren, können Sie sich die Ergebnisse des Nachschubs im
Nachschubmonitor anzeigen lassen.
Jede Ausführung der Nachschubplanung ist ein Nachschublauf, für den eine interne Nummer
vergeben wird. Über diese Nummer können Sie den Vorgang bei einer nachträglichen
Auswertung im Nachschubmonitor identifizieren. Die Ergebnisse werden in drei Kategorien
eingeteilt (erfolgreich bearbeitet, Workitem erzeugt, fehlerhaft). In jeder Kategorie erhalten Sie
Informationen, wie die Positionen (jeweils eine Kombination aus Kunde und Artikel) verarbeitet
worden sind.

April 2001 103


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Nachschub: Artikelstammdaten für externe Kunden

Nachschub: Artikelstammdaten für externe Kunden


Verwendung
Sie müssen im Artikelstamm Daten pflegen, die den Ablauf und das Ergebnis der
Nachschubplanung steuern. Wenn Sie den Nachschub für externe Kunden einsetzen, sind bei
der Pflege folgende Fälle zu unterscheiden:
· In einem SAP-Retail-System [Extern] pflegen Sie die Daten über die Artikelpflege
(Transaktion MM41 bzw. MM42).
· In einem SAP-Manufacturing-System pflegen Sie die Daten über die Materialpflege
(Transaktion MM01 bzw. MM02).
Die zur Pflege angebotenen Daten sind in beiden Fällen identisch. Die Daten werden auf
Kundenebene verwaltet und haben daher keine Zuordnung zu einem Betrieb.

Funktionsumfang
Sie können z.B. folgende Daten über die Artikelpflege bearbeiten:
· Nachschubparameter
- Dispositionsmerkmal
Die Nachschubplanung kann nur durchgeführt werden, wenn ein für den Nachschub
vorgesehenes Dispositionsmerkmal eingetragen ist. Dem Dispositionsmerkmal
müssen das Dispositionsverfahren W und eine Planungsmethode ungleich 1 (durch
externes System geplant) zugeordnet sein. Wenn dem Dispositionsmerkmal das
Prognosekennzeichen + (Mußprognose) zugeordnet ist, wird der Sollbestand bei der
Nachschubplanung dynamisch berechnet. Für eine Planung mit dynamischem
Sollbestand ist eine vorherige Prognose der Abverkäufe Voraussetzung.
In der Standardauslieferung sind die Merkmale RP (Nachschubplanung mit
statischem Sollbestand) und RF (Nachschubplanung mit dynamischem Sollbestand)
vorgesehen.
- Sollbestand
Sie müssen den Sollbestand nur dann pflegen, wenn Sie ein Dispositionsmerkmal
für Nachschubplanung mit statischem Sollbestand zugeordnet haben. Der statische
Sollbestand legt fest, wie hoch der Bestand des Artikels beim Kunden nach dem
Wareneingang sein sollte. Bei der Nachschubplanung wird der Nachschubbedarf aus
dem Sollbestand wie folgt berechnet:
Nachschubbedarf = Sollbestand - aktueller Bestand des Kunden
- Meldebestand
- Sicherheitsbestand
- Sollreichweite
Die Sollreichweite gibt die Zeitdauer in Tagen an, die zwischen dem Wareneingang
zur aktuellen Planung und dem darauffolgenden Wareneingang vergeht.
- Kennzeichen für Nachschubbestandsführung (NachschBestf.)

104 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Nachschub: Artikelstammdaten für externe Kunden

Dieses Kennzeichen ist immer gesetzt. Die Bestandsführung der Materialwirtschaft


verwaltet den Bestand immer pro Betrieb, kann aber nicht zur Bestandsführung für
Kunden genutzt werden.
- Kennzeichen Nachschubbestand mit Belegmenge korrigieren (NB korrigieren)
Dieses Kennzeichen wirkt sich ausschließlich bei Verwendung der
Nachschubbestandsführung aus. Wenn Sie das Kennzeichen setzen, erhöhen die
Mengen aus den generierten Folgebelegen bei einem Nachschublauf den
Nachschubbestand und werden somit als vorweggenommene Wareneingänge
betrachtet. Dies ist sinnvoll, wenn als Grundlage für den Nachschub lediglich
Informationen über Abverkäufe aus den Filialen vorliegen.

April 2001 105


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
VMI: Generieren Bestellung zu EDI-Bestellbestätigung

VMI: Generieren Bestellung zu EDI-Bestellbestätigung


Verwendung
Zu einer per EDI eingehenden Bestellbestätigung wird im empfangenden System eine Bestellung
generiert. Über diese Funktion kann z.B. ein Kunde von seinem Lieferanten Informationen über
Kundenaufträge erhalten, die der Lieferant durch eine Nachschubplanung für den Kunden
erzeugt hat. Im System des Kunden wird dann eine Bestellung generiert, die das Gegenstück
zum Kundenauftrag des Lieferanten darstellt.
Die Nummer des Kundenauftrags wird als Referenznummer in die Bestellung eingetragen.
Anschließend wird eine Bestelländerungsnachricht an den Lieferanten gesendet, die dem
System des Lieferanten die Bestellnummer aus dem Kundensystem bekanntmacht.

Voraussetzungen
· Sie müssen im Menü für die Pflege von Lieferanten unter Umfeld ® Bestellerf. Lieferant die
organisatorische Zuordnung des Lieferanten zu den Einkaufsorgansationsdaten pflegen.
- Feld Lieferant
Hier geben Sie die interne Lieferantennummer an, unter der der Lieferant in Ihrem
System geführt wird.
- Feld Kunde (Auftraggeber)
Hier geben Sie die externe Auftraggebernummer, unter der Ihr Unternehmen im
System des Lieferanten als Kunde geführt wird.
Zu einer Kombination aus Lieferant und Auftraggeber ordnen Sie in den Detaildaten eine
Einkaufsorganisation und eine Einkäufergruppe zu. Einkaufsorganisation und
Einkäufergruppe müssen beim Anlegen einer Bestellung bekannt sein, sind aber im IDoc
nicht enthalten. Daher werden sie vom System beim IDoc-Eingang aus den Daten zur
organisatorischen Zuordnung ermittelt.
Der Lieferant kann zusätzlich eine externe Warenempfängernummer senden, unter der
ein Betrieb Ihres Unternehmens beim Lieferanten geführt wird. Damit das System diese
Nummer beim IDoc-Eingang in eine interne Betriebsnummer umschlüsseln kann, tragen
Sie die externe Nummer im Feld Kunde (Warenempfänger) ein und legen dazu in den
Detaildaten die interne Nummer des Betriebs fest, der die Ware erhalten soll.
Darüber hinaus können Sie in den Detaildaten die Einkaufsbelegart vorgeben, die beim
Anlegen einer Bestellung für den Lieferanten verwendet werden soll. Wenn Sie keine
Einkaufsbelegart angegeben, wird die Einkaufsbelegart verwendet, die im Customizing
für die Neuanlage einer Bestellung im Dialog festgelegt ist.
· Für den Lieferanten, der die Bestellbestätigung sendet, müssen Sie in den Einkaufsdaten
des Lieferantenstamms das Kennzeichen für Bestellerfassung durch den Lieferanten setzen.
· Für die Artikel muß in den Betriebsdaten ein Dispositionsmerkmal eingetragen sein, dem als
Planungsmethode die Planung durch ein externes System zugewiesen ist.
· Sie müssen für die beteiligten Artikel und den Lieferanten Einkaufsinformationssätze
anlegen. Dort können Sie auch die Lieferantenartikelnummer hinterlegen und dadurch eine
Umschlüsselung vornehmen, wenn im IDoc nur die Lieferantenartikelnummer gesendet wird.

106 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
VMI: Generieren Bestellung zu EDI-Bestellbestätigung

Funktionsumfang
Die Funktion verarbeitet IDocs des Nachrichtentyps ORDRSP mit der Nachrichtenvariante VMI.
Vor der Bestellgenerierung wird der User-Exit EXIT_SAPLWVMI_003 aufgerufen, über den Sie
die Daten des eingegangenen IDocs verändern können.
Dadurch haben Sie z.B. die Möglichkeit, die Artikelnummern des Lieferanten nach einem
individuellen Verfahren in die Artikelnummern Ihres Systems umzuschlüsseln. Kann keine
Bestellung generiert werden, z.B. weil die Daten unvollständig sind, wird ein Workflow
angestoßen.
Um nach der Bestellgenerierung die Bestellnummer an das System des Lieferanten zu
übermitteln, wird ein IDoc des Nachrichtentyps ORDCHG mit der Nachrichtenvariante VMI
verwendet. Eine solche Nachricht wird nur versendet, wenn Sie eine Partnervereinbarung für
diesen Nachrichtentyp gepflegt haben.

April 2001 107


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
MM MM-MOB- und WM-LSR-Schnittstellen

MM MM-MOB- und WM-LSR-Schnittstellen


Ankopplung von Fremdsystemen an das SAP-Logistikmodul [Seite 109]

Szenarios: Mobile Datenerfassung in der Lagerlogistik [Seite 117]

Szenarios: Lagersteuerrechner-Anbindung [Seite 128]

Datenfluß: Technische Beschreibungen [Seite 145]

Beschreibung der IDocs [Seite 164]

SAP-Systemeinstellungen und Modifikationskonzept [Seite 215]


Siehe Schnittstellen zu Fremdsystemen [Extern] in der Dokumentation Lagerverwaltung.

108 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Schnittstelle zwischen Fremdsystem und SAP-Logistikmodul

Schnittstelle zwischen Fremdsystem und SAP-


Logistikmodul
Allgemeine Informationen
Das Logistikumfeld bietet zwei Schnittstellen:
1. MM-MOB Mobile Datenerfassung
2. WM-LSR Lagersteuerrechnerkopplung
Im Bereich der mobilen Datenerfassung wird folgendes ermöglicht:
· mobile Erfassung und Übertragung von Daten an das SAP-System mit / ohne
Funkunterstützung
· Einsatz von drahtlosen Barcode-Lesegeräten zur papierlosen Dateneingabe
· schnelle und sichere Datenübertragung
Im Bereich der Lagersteuerrechnerkopplung wird folgendes ermöglicht:
· Einbindung von Lagersteuerrechnern in die SAP-Umgebung
· Anbindung von Staplerleitsystemen, Karussellen
· Kostenersparnis durch definierte, release-unabhängige Schnittstellen

SD FI
MM CO

R/3
PP AM

QM
Client / Server PS
PM
ABAP/4 WF
HR IS

Staplerleitsystem Gabelstapler Mobile Datenübertr.

April 2001 109


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Funktionen

Funktionen
Die Schnittstelle Mobile Datenerfassung unterstützt dabei folgende Funktionen:
· Erfassung von Warenbewegungen
· Erfassung von Inventurzähldaten
· Erfassung von Verpackungen
· Versenden Lieferbeleg an Fremdsystem
· Erfassen von Pickmengen zum Lieferbeleg
· Erfassung von Lagerbewegungen
Dadurch sind viele Szenarien vorstellbar: Etwa Wareneingänge, die mit Handheld Terminals
erfaßt werden, Inventurzähldaten, die per tragbarem Gerät erfaßt werden, Wareneingänge aus
der Produktion etc.
Bei Einsatz der Schnittstelle ist die bestehende Situation sorgfältig zu analysieren.
Die Schnittstelle Lagersteuerrechnerkopplung unterstützt folgende Funktionen:

SAP an Fremdsystem

· Melden Transportaufträge
· Melden Sammelgangsfreigabe
· Stornieranforderung Transportaufträge

Fremdsystem an SAP

· Erzeugen gemeldete Transportaufträge


· Quittieren Transportaufträge
· Bewegen Lagereinheiten
· Sperren Lagerplätze (Gassen)
· Erzeugen Transportbedarfe
· Stornieren nichtquittierte Transportaufträge

110 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Partnerkonzept

Partnerkonzept
Um unseren Kunden eine flexible und sichere Anbindung von mobilen Datenerfassungsgeräten,
Lagersteuersystemen, Staplerleitsystemen, Karrussellen etc. zu ermöglichen, werden wir mit
ausgewählten Partnern zusammenarbeiten. Die Aufgabenteilung sieht dabei folgendermaßen
aus:
SAP liefert standardmäßig ab Release 3.0 die technischen Werkzeuge (IDocs, ALE, RFC) aus,
die zur Anbindung der externen Rechner notwendig sind. Außerdem werden auf
Anwendungsseite Funktionen (Standard-IDocs) zur Verfügung gestellt, die gängige
Geschäftsvorfälle abbilden und die entsprechende Verarbeitung im SAP-System veranlassen.
Die Partner sind für die komplette Realisierung der Verarbeitungslogik, Screenaufbau und
Kommunikation auf den Rechnern verantwortlich. Insbesondere sind sie erste
Ansprechpartner der gemeinsamen Kunden bei Auftreten von Fehlern im
Kommunikationsbereich.
Für die Partner ist seitens SAP ein Zertifizierungsverfahren vorgesehen. Hier wird geprüft, ob
der Partner die Voraussetzungen für eine erfolgreiche Anbindung externer Systeme an SAP
mittels obiger Technik erfüllt. Eine Funktionsprüfung der Anwendungssoftware der Partner ist
nicht vorgesehen.

April 2001 111


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Technik

Technik
Technisch beruht die Schnittstelle auf dem transaktionalen Remote Function Call (tRFC). Dies ist
ein vereinfachtes Verfahren um Programm zu Programm Kommunikation möglich zu machen.
Im Gegensatz zum synchronen Remote Function Call (sRFC) werden beim tRFC die Daten
zwischengesichert, bevor sie versendet werden. Damit sind Anwendung und Kommunikation
entkoppelt.
Der sRFC kann aber besonders im Umfeld der mobilen Datenerfassung zur
Informationsbeschaffung, d.h. für lesende Zugriffe eingesetzt werden.
Zur logischen Fehleranalyse bietet SAP ein ausgefeiltes Monitoring. Außerdem werden im
Fehlerfall Nachrichten an Personen oder Personengruppen gesendet. Aus deren
Eingangskörben ist eine Nachbuchmöglichkeit gegeben.

112 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Zertifizierungsanforderung

Zertifizierungsanforderung
SAP erteilt entweder ein Vollzertifikat oder ein Teilzertifikat, je nachdem, ob ein Partner alle
IDoc-Anbindungen oder nur einen Teil zeigt.
Die Liste der IDocs zum Erhalt des Vollzertifikats sowie die Zuordnung der IDocs zu den beiden
Schnittstellen finden Sie unter Beschreibung der IDocs [Seite 164]. Im folgenden sind für jede der
beiden Schnittstellen die Minimalvoraussetzungen beschrieben, die erfüllt sein müssen, damit ein
Teilzertifikat erteilt wird.
Die Zertifikate enthalten eine Liste der zertifizierten IDoc-Anbindungen.

April 2001 113


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Schnittstelle WM-LSR - Minimalvoraussetzung

Schnittstelle WM-LSR - Minimalvoraussetzung


Im Lagersteuerbereich sind folgende Bewegungen abzudecken:
1. SAP sendet einen Transportauftrag. Der Empfang (WMTOID01) muß nachgewiesen
werden.
2. SAP erhält vom Sub-System die Quittierung des Transportauftrags (WMTCID01).
3. Das Fremdsystem sperrt eine Gasse im Lager generisch (Senden einesWMBIID01).
4. Das Fremdsystem bewegt eine Lagereinheit (Senden eines WMSUID01).

114 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Schnittstelle MM-MOB - Minimalvoraussetzung

Schnittstelle MM-MOB - Minimalvoraussetzung


1. Vom Fremdsystem muß ein synchroner Remote Function Call auf einen
Funktionsbaustein (‘L_PO_READ_MDE‘) in SAP die Bestelldaten anfordern. Nach dem
Nachweis der Bestelldaten im Fremdsystem soll ein Wareneingang zur Bestellung
erfolgen (WMMBID01).
2. Entweder müssen die Minimalvoraussetzungen der WM-LSR-Schnittstelle oder die IDocs
des SD angebunden werden.

April 2001 115


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Zuordnung von IDoc zu Schnittstelle

Zuordnung von IDoc zu Schnittstelle


Zuordnung von IDoc zu Schnittstelle

IDoc Komponente Bezeichnung


WMMBID01 MOB Warenbewegungen
SDPIOD01 MOB Kommissioniermeldung an Fremdsystem
SDPIID01 MOB Kommissionierrückmeldung
SDPAID01 MOB Versandelementrückmeldung
LSR/MOB LSR/MOB Transportaufträge TA
LSR/MOB LSR/MOB Quittieren Transportaufträge
LSR/MOB LSR/MOB Stornoanforderung / Storno TA
LSR/MOB LSR/MOB Transportaufträge TA
LSR/MOB LSR/MOB Sperren Lagerplätze (Gassen)
LSR/MOB LSR/MOB Freigabe TAs zur Gruppe
LSR/MOB LSR/MOB Bewegen von Lagereinheiten
LSR/MOB LSR/MOB Erfassung von Inventurzähldaten
LSR/MOB LSR/MOB Informationstext

116 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Szenarios: Mobile Datenerfassung in der Lagerlogistik

Szenarios: Mobile Datenerfassung in der Lagerlogistik


Dieser Abschnitt beschreibt mögliche Szenarios für eine Anbindung von Systemen zur mobilen
Datenerfassung an SAP-R/3. Hierbei werden die betriebswirtschaftlichen Zusammenhänge
erklärt. Diese Sammlung einzelner Anwendungen ist nicht vollständig. Sie ist als Auflistung
möglicher Anbindungen gedacht und soll typische Einsatzmöglichkeiten aufzeigen. Im
Unterschied zur LSR-Ankopplung ist die Ankopplung mobiler Datenerfassungsgeräte
komponentenübergreifend angesiedelt, d.h. es werden Anbindungen an die Lagerverwaltung,
aber auch an Bestandsführung und Versand besprochen.

Zusammenfassung
Die in diesem Abschnitt genannten Anbindungen verstehen sich als Beispiele für den Einsatz
mobiler Datenerfassungsgeräte. Im einzelnen Kundenfall muß analysiert werden, welche
Einsatzmöglichkeiten realisierbar und sinnvoll sind.
Prinzipiell können alle Standard-IDocs der WM-LSR- und MM-MOB-Schnittstelle im mobilen
Bereich eingesetzt werden.
Auch als Erweiterung der Logistikkette mit Einsatz eines Steuerrechners für die papierlose Ein-
und Auslagerung sind mobile Funktionen denkbar.
Informationen zum technischen Aufbau der IDocs bzw. zum Versenden und Empfangen finden
Sie in den entsprechenden Beschreibungen der einzelnen IDocs.

April 2001 117


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Wareneingang Fremdsystem in Bestandsführung

Wareneingang Fremdsystem in Bestandsführung


Einsatzmöglichkeiten
Erfassen von Wareneingängen zu Bestellungen
Das mobile Erfassen von Wareneingängen in der Bestandsführung ist eine typische Anforderung
von Kundenseite. Problematisch für eine Standardabwicklung ist die Vielfältigkeit der Abwicklung
im Detail. Standardmäßig unterstützt SAP daher ‘nur’ das Senden und Verbuchen des
Wareneingangs, nicht aber gewünschte Prüfungen und Dialoge. Die Technik erlaubt es aber,
diese auf einfachem Wege zu realisieren.

Voraussetzungen
Verwenden Sie das Standard-IDoc WMMBID01. Erfassungsdaten auf dem Fremdsystem
müssen in Form dieses IDocs aufgebaut sein, damit in SAP der Wareneingang in der
Bestandsführung gebucht werden kann. Das IDoc wird via transaktionalem RFC an SAP
versendet.
Sämtliche Prüfungen gegen Bestellungen auf dem Fremdsystem, der Druck der Bestellnummer
auf Lieferscheinen, Aufbereitung der Daten in IDoc-Format sowie differenzierte Dialoge zwischen
Fremdsystem und mobilem Terminal sind individuell den Kundenwünschen entsprechend zu
realisieren. Bestelldaten lassen sich über synchronen RFC bequem vom Fremdsystem aus
herunterladen (siehe auch Synchroner RFC).
Die Abwicklung im Lager (Erstellen Transportaufträge, physischer Transport etc.) ist davon
unabhängig, da es sich um eine Ankopplung an die Bestandsführung handelt.

Ablauf
Eine typische Abwicklung könnte folgendermaßen aussehen, nachdem ein Lieferant Ware zum
Wareneingang geschafft hat:
1. Die Bestellnummer auf dem Lieferschein wird mittels Barcodescanner eingelesen.
2. Vom R/3-System werden die Bestelldaten zum Fremdsystem heruntergeladen.
3. Dort werden die Lieferscheinpositionen eingegeben.
4. Das Fremdsystem prüft Bestellung gegen Lieferung.
5. Das Fremdsystem versendet die Daten. Im R/3-System werden die Wareneingänge
verbucht.

118 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Einlagerung aus Produktion in die Bestandsführung

Einlagerung aus Produktion in die Bestandsführung


Einsatzmöglichkeiten
Erfassen von Wareneingängen zu Fertigungsaufträgen
Mithilfe dieser Funktion soll der Eingang aus der Produktion beschleunigt werden. Dies wird
ermöglicht durch eine Vorplanung der Eingänge durch den Fertigungsauftrag.

Voraussetzungen
Auch hier verwenden Sie den Standard-IDoc WMMBID01. Das Erstellen der Barcode-Aufkleber
ist individuell zu realisieren.
Die Abwicklung im Lager (Erstellen Transportaufträge, physischer Transport etc.) ist davon
unabhängig, da es sich um eine Ankopplung an die Bestandsführung handelt.

Ablauf
Wird die Ware in der Produktion fertiggestellt und ins Lager versendet, kann man sich die
Abwicklung so denken:
1. Fertigungsauftragsnummer, Material und Menge werden als Aufkleber schon in der
Produktion an die entsprechende Palette geheftet.
2. In der Wareneingangszone werden die Daten via Barcodescanner eingelesen, an SAP
versendet und dort verbucht.

April 2001 119


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Einlagerung aus Produktion in die Lagerverwaltung

Einlagerung aus Produktion in die Lagerverwaltung


Einsatzmöglichkeiten
Vereinnahmen von erzeugten Waren im Lager
Im Unterschied zum vorigen Beispiel wird hier nicht im Bestandsführungssystem eine
Zugangsbuchung erfaßt, sondern lediglich die physische Einlagerungsabwicklung
vorweggenommen. Dies passiert in Form des Quittierens von vorgeplanten Transportaufträgen
(TAs). Diese Transportaufträge müßten Sie zuvor im System erzeugen, drucken und an die
Produktion übergeben. Die aus der Produktion ins Lager gesendeten Paletten sollten dann mit
einen Transportauftragsdruck ausgerüstet sein.

Voraussetzungen
Sie verwenden das Standard-IDoc WMTOID01. Der TA-Druck inkl. Barcode ist im Standard
realisiert. Die im WM vereinnahmten Mengen sammeln sich als Gegenbuchung auf einer
Schnittstelle. Erst das Buchen des Wareneingangs (WE) in der Bestandsführung macht die Ware
dispositiv verfügbar und gleicht diesen Schnittstellenbestand aus.
Vorteil dieser Abwicklung ist jedoch die Möglichkeit die Anzahl der WE-Buchungen drastisch zu
reduzieren, da die Mengen kumulativ verbucht werden können.

Ablauf
1. Im Lager wird die Transportauftragsnummer eingescannt.
2. Das Fremdsystem baut die Daten zum Quittieren des TAs auf. Sind weniger als die
geplanten Mengen zu vereinnahmen, so wird mit Differenz quittiert.
3. Nach dem Versenden der Daten werden diese im WM verbucht und werden damit im
Lager verfügbar.

120 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Einlagerung im WM mit manueller Lagerplatzvergabe

Einlagerung im WM mit manueller Lagerplatzvergabe


Einsatzmöglichkeiten
Ware auf einen manuell vergebenen Lagerplatz mit Systemmeldung einlagern

Voraussetzungen
Sie verwenden das Standard-IDoc WMTOID01. Die erstellten Transportaufträge werden bereits
quittiert erstellt, da der physische Transport schon erfolgt ist. Diese Abwicklung macht Sinn,
wenn der Lagerarbeiter die Organisation der Einlagerung selbst übernehmen soll oder will. Zur
Zeit nicht realisiert ist das Erstellen TA zum Transportbedarf, so daß bei dieser Abwicklung kein
Bezug zum Transportbedarf hergestellt werden kann.

Ablauf
Diese Funktion ist eine reine Lagerfunktion. Die Ware wird auf einem Lagerplatz abgelegt.
1. Einscannen Lagerplatz, Material und Menge.
2. Versenden Daten und Erstellen Transportauftrag in SAP.

April 2001 121


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Nachschub-TA für die Produktion

Nachschub-TA für die Produktion


Einsatzmöglichkeiten
Erzeugen eines Nachschubtransportauftrags für die Produktion

Voraussetzungen
Sie verwenden das Standard-IDoc WMTOID01. Die Barcode-Information ist individuell zu
erstellen, z.B. in Form einer Kanban-Karte.

Ablauf
Das Erzeugen von Nachschub für die Produktion ist hier als eine Lagerfunktion abgebildet. Wird
an einem WM-verwalteten Produktionslagerplatz erkannt, daß Nachschubbedarf vorhanden ist,
ergibt sich folgendes Szenario:
1. Einscannen von Material, Menge und Lagerplatz.
2. Versenden der Daten und Erzeugen TA im WM.
3. Drucken TA und physischer Transport zum Lagerplatz.

122 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Erfassen von Inventurzähldaten ohne WM (offline)

Erfassen von Inventurzähldaten ohne WM (offline)


In der Bestandsführung gibt es mit Release 3.0 einen Report, der es ermöglicht
Inventurzähldaten, die in einer sequentiellen Datei gesammelt wurden, im SAP-System
einzubuchen. Die Übertragung der Datei in den SAP-UNIX-Pfad erfolgt über file transfer. Die
genaue Beschreibung dieser Schnittstelle entnehmen Sie bitte der R/3-Retail-Spezifikation
‘Übernahme Inventur-MDE-Daten’.

April 2001 123


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Erfassen von Inventurzähldaten mit dem WM

Erfassen von Inventurzähldaten mit dem WM


Einsatzmöglichkeiten
Mobiles Erfassen der Zähldaten zu Inventuraufnahmebelegen

Voraussetzungen
Sie verwenden das Standard-IDoc WMIVID01. Die Reihenfolge der zurückzumeldenden Sätze
ist irrelevant. Die Zählsätze werden den richtigen Belegen automatisch zugeordnet.

Ablauf
Sobald mit Lagerverwaltungssystem gearbeitet wird, muß die Inventur lagerplatzbezogen
durchgeführt werden, da eventuell auftretende Differenzen dem Lagerplatz zugeordnet werden
müssen. Eine typische Inventur im WM enthält folgende Schritte: Erstellen Aufnahmebelege (d.h.
Zuordnen Plätze zu Belegen), Drucken, Zählen, Ergebnisse erfassen, Differenzen ausbuchen.
Mit Einsatz mobiler Datenerfassung könnte dies jetzt so aussehen:
1. Erfassen Inventuraufnahmebelege im WM
2. Versenden Aufnahmebelege an Fremdsystem
3. Erfassen Zähldaten auf den mobilen Terminals
4. Versenden und Verbuchen der Zählergebnisse im WM
5. Differenzen ausbuchen etc., normale Abwicklung
Schritt 2 ist nicht zwingend, erleichtert aber den Aufbau der Zähldaten im entsprechenden IDoc-
Format, da im gleichen Format auch ans Fremdsystem gesendet wird.

124 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Rückmelden Verpackungen an SD

Rückmelden Verpackungen an SD
Einsatzmöglichkeiten
Melden der aktuell gewählten Verpackungen an die Lieferung.

Ablauf
Sie haben drei Möglichkeiten, Packstücke (Versandelemente) an die Lieferung zurückzumelden:
Sie können das System fortschreiben für:
· Freie Packstücke ohne Inhaltsangabe (ohne Bezug zur Lieferungsposition)
· Verpackte Positionen
· Verpackte Packstücke
Packstücke sind beliebig oft in andere Packstücke verpackbar. Aus den Packstücken können in
der Lieferung Lieferpositionen erzeugt werden, so daß diese fakturierbar und bestandsführbar
werden.

Voraussetzungen
Sie verwenden das Standard-IDoc SDPAID01.

April 2001 125


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Anbinden von Kommissioniersystemen

Anbinden von Kommissioniersystemen


Senden von Kommmissionieraufträgen
Pro Versandstelle können Sie entscheiden, ob die Daten der Kommissionierliste (d.h. zu
kommissionierende Positionen, die nicht mit WM-Transportaufträgen kommissioniert werden) als
Papier gedruckt oder an ein Fremdsystem gesendet werden sollen. Gesendet werden
kommissionierrelevante Lieferungskopf- und Positionsdaten. In beiden Fällen wird ein
Kommissionierauftrag erzeugt.
Sind die Positionen quittierungspflichtig, muß eine Rückmeldung der kommissionierten Mengen
erfolgen.
Sie verwenden den Standard-IDoc SDPIOD01.

Rückmeldung von Kommissionieraufträgen an die Lieferung


Kommissionieraufträge können entweder über die Online-Transaktion /nVL08 oder im Falle eines
Fremdsystems über ein IDoc an die Lieferung zurückgemeldet werden. Zur Zeit können quittierte
Mengen, Chargensplitts und Bewegungsartensplitts zurückgemeldet werden.
Optional kann dabei die Anpassung der Liefermenge an die kommissionierte Menge erfolgen und
die Warenausgangsbuchung angestoßen werden.
Sie verwenden den Standard-IDoc SDPIID01.

126 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Anbinden von Kommissioniersystemen

Buchen von Wareneingängen und Warenausgängen mit


Wiegemengen
Verwendung
Um mit gewogenen Mengen zu arbeiten, können Sie diesen IDoc mit der gleichen Schnittstelle
wie im Standard verwenden, auch wenn die Datenerfassung in diesem Fall nicht über ein
mobiles Terminal erfolgt.
Geben Sie hierfür die Differenz des Gewichts eines LKWs vor und nach dem Laden in das SAP-
System ein, um den Wareneingang oder Warenausgang zu buchen.

April 2001 127


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Szenarios: Lagersteuerrechner Anbindung

Szenarios: Lagersteuerrechner Anbindung


Dieser Abschnitt beschreibt mögliche Szenarios für eine Anbindung der SAP-R/3-Anwendung
Lagerverwaltung (WM) an ein Fremdsystem. Die Schnittstelle wird dabei aus der Sicht der
Anwendung beschrieben.
Unter einem Fremdsystem sind sowohl unterlagerte Lagersysteme wie Lagersteuerrechner
(LSR) oder Staplerleitsysteme (SLS) zu verstehen als auch Systeme, die sich nur aus dem Lager
bedienen, beispielsweise Produktionsleitstände. Die Schnittstelle zum WM kann unabhängig von
der Art des Fremdsystems effektiv eingesetzt werden.
Es gibt nicht nur eine große Vielfalt der Systeme, die an WM angekoppelt werden können. Die
Komplexität dieser Schnittstelle resultiert vielmehr aus der Funktionalität, die sie abdecken muß.
Deswegen sollen die im folgenden beschriebenen Szenarios einige typische
Einsatzmöglichkeiten innerhalb dieser Schnittstelle aufzeigen. Dabei wird besonders auf die
Funktionsverteilung zwischen WM und dem Fremdsystem eingegangen.
Bevor die einzelnen Szenarios dargestellt werden, soll zuerst geklärt werden, wie die SAP-
Lagerverwaltung in der Systemlandschaft einzuordnen ist, d.h. welche Rolle sie aus SAP-Sicht in
der Systemverteilung spielt und welche Aufgaben sie übernimmt. Anhand des 4- und 3-Ebenen-
Modells läßt sich das wie folgt veranschaulichen.
Das 4-Ebenen-Modell beschreibt den Einsatz eines R/2-Hostsystems (Ebene 1) mit dezentral
hierzu gekoppelter R/3-Lagerverwaltung. Das 3-Ebenen-Modell beschreibt den Einsatz des
integrierten R/3-Systems.

4-Ebenen
4-Ebenen Modell
Modell 3-Ebenen
3-Ebenen Modell
Modell

SAP
Materialwirtschaft
Materialwirtschaft
11 Produktionsplanung
Produktionsplanung
Vertrieb
Vertrieb

11 Lagerverwaltung
Lagerverwaltung

22 Lagerverwaltung
Lagerverwaltung

33 Lagersteuerung
Lagersteuerung 22 Lagersteuerung
Lagersteuerung

Ausführung
Ausführung Ausführung
Ausführung
44 Fahrbefehle
33 Fahrbefehle
Fahrbefehle Fahrbefehle

128 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Szenarios: Lagersteuerrechner Anbindung

Auf der dispositiven Ebene (1) sind Materialwirtschaft, Produktionsplanung und Vertrieb
eingeordnet. Die Lagerverwaltung auf der Ebene (2) ist zwar eigenständige, aber vollständig mit
der dispositiven Ebene integriert. Aus Sicht der Systemarchitektur laufen die beiden Ebenen auf
demselben System, genauer gesagt auf derselben Datenbank. Lediglich beim dezentralen WM,
das mit dem R/2-System verbunden ist, handelt es um zwei verschiedene Systeme.
Die beiden Ebenen übernehmen alle Funktionen der Lagerverwaltung. Die Funktionen der
Lagersteuerung und der ausführbaren Fahrbefehle liegen dagegen nicht im Aufgabenbereich des
SAP-Systems. Deswegen sind diese Ebenen aus Sicht der Anwendung immer als eigenständige
Systeme zu betrachten. Die Funktionen der Lagersteuerung müssen also von einem
Fremdsystem übernommen werden, das aber außer der Steuerung des Materialflusses auch
andere Aufgaben wie die Optimierung der Lagerbewegung oder zusätzliche
Kontrollmechanismen übernehmen kann.
Mit der neuen Schnittstelle zum Fremdsystem soll die Kommunikation zwischen Lagerverwaltung
und Lagersteuerung durch standardisierte Datenträger (IDocs) und Kommunikationstechniken
(tRFC) sowie durch eine flexible Gestaltungsmöglichkeit der Schnittstelle besser unterstützt
werden.
Die Szenarios lassen sich abhängig von der Art der Lagertechnik in 6 Gruppen unterteilen:
1. Manuelles Lager mit WM-Lagerverwaltung [Seite 131]
2. Halbautomatisches Lager mit WM-Lagerverwaltung [Seite 133]
3. Vollautomatisches Lager mit WM-Lagerverwaltung [Seite 135]
4. Vollautomatisches Lager [Seite 139] als ‘Blackbox’ mit beschränkter Funktionalität der
WM-Lagerverwaltung
5. Keine WM-Lagerverwaltung [Seite 142] ; direkte Ankopplung eines fremden WMS an die
dispositive Ebene des SAP-Systems
Außer Lagersystemen können abhängig von der Art der Lagertechnik auch beliebige
andere Systeme an WM gekoppelt werden:
6. Anbindung von Nicht-Lagersystemen an das WM [Seite 144]

Zusammenfassung
Die in diesem Abschnitt genannten Anbindungen verstehen sich als Beispiele für den Einsatz
von Fremdsystemen in Verbindung mit dem WM bzw. anstelle des WM. Die einzelnen Szenarios
lassen sich wie folgt zusammenfassen:
· Die Anbindung an Lagersysteme ist sehr variantenreich.
· Es gibt kein fertiges Rezept bei der Entscheidung für das passende Szenario.
· Die Funktionsverteilung zwischen WM und dem Fremdsystem muß immer
kundenindividuell ermittelt werden.
· Mit dem Standard ist bereits ein hoher Abdeckungsgrad für die Schnittstelle erreicht.
· Die Flexibilität der Schnittstelle ermöglicht kundeneigene Anpassungen und
Ergänzungen.
Informationen zum technischen Aufbau der IDocs bzw. zum Versenden und Empfangen finden
Sie in den entsprechenden Beschreibungen der einzelnen IDocs.

April 2001 129


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Szenarios: Lagersteuerrechner Anbindung

130 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Manuelles Lager: Szenario 1

Manuelles Lager: Szenario 1


Einsatzmöglichkeiten
Ziel dieses Szenarios ist die sinnvolle Ergänzung der WM-Funktionalität durch Einsatz eines
Fremdsystems.
Bei einem manuellen Lager wird die gesamte Verwaltung des Lagers vom WM-System
übernommen; u.a.:
· Verwaltung der Materialbestände und der Lagerplätze
· Erstellung von Lagerbewegungen (Ein-/Aus-/Umlagerungen sowie Umbuchungen)
· Ermittlung der Lagerplätze für die Bewegungen mit festgelegten Ein- und
Auslagerungsstrategien
· Durchführung der Inventur
Folgende ergänzende Funktionen können die Verwaltung eines manuellen Lagers optimaler
gestalten:
· Einsatz eines Staplerleitsystems
· Beleglose Kommissionierung
· Rückmeldung der vollzogenen Lagerbewegung via Funkterminal
Als Beispiel für das Anbindung eines Fremdsystems im manuellen Lager wird der Einsatz eines
Staplerleitsystems (SLS) beschrieben.

Staplerleitsystem
Funktionsverteilung zwischen WM und Fremdsystem
WM:
· Anstoßen von Warenbewegungen
· Erstellung von Transportaufträgen für alle mögliche Lagerbewegungen
· Versenden erstellter Transportaufträgen an das SLS
Schnittstelle WM Fremdsystem
Fremdsystem:
· Optimierung der Lagerbewegungen
· Zusätzliche Mechanismen zur Kontrolle der Lagerbewegungen
· Durchführung der Lagerbewegungen
· Rückmeldung der Warenbewegungen an WM
Schnittstelle Fremdsystem WM
WM:
· Quittieren der zurückgemeldeten Transportaufträge

April 2001 131


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Manuelles Lager: Szenario 1

Die im WM erstellten Transportaufträge werden an das Fremdsystem mit dem Standard-IDoc


WMTOID01 übergeben. Anhand der Daten, die mittels dieses IDocs übergeben werden, wird die
Lagerbewegung im Lager durchgeführt. Alle Bewegungen werden vom SLS überwacht und bei
Bedarf auch optimiert. Der an das SLS übergebene Transportauftrag bestimmt, ob die
Lagerbewegung an WM zurückgemeldet werden muß. Die Rückmeldung erfolgt über das
Standard-IDoc WMTCID01. Die Rückmeldedaten müssen in Form dieses IDocs auf der SLS-
Seite aufgebaut und an SAP versendet werden, damit in SAP der Transportauftrag quittiert
werden kann.
Sollen Lagerbewegungen manuell veranlaßt werden, wie eine Umlagerung innerhalb eines
Lagers (z.B. Zusammenfassung der Restmengen, um Platz zu beschaffen), können sie im SLS
aufgenommen und an WM gemeldet werden. Das Melden der vorgezogenen Bewegung erfolgt
über das Standard-IDoc WMTOID01. Die Transportauftragsdaten müssen in Form dieses IDocs
auf der SLS-Seite aufgebaut und an SAP versendet werden, damit SAP für die Lagerbewegung
einen Transportauftrag erstellen kann, um das WM zu aktualisieren.
Ähnlich kann auch bei einer manuellen Einlagerung verfahren werden, bei der der Lagerplatz
durch das Lagerpersonal direkt im Lager bestimmt wird. Die Lagerbewegung wird mit mobilen
Geräten (MDE) erfaßt und an das WM gemeldet.

132 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Halbautomatisches Lager: Szenario 2

Halbautomatisches Lager: Szenario 2


Einsatzmöglichkeiten
Übernahme der Steuerung von Regalbediengeräten durch das Fremdsystem
Auch bei halbautomatischen Lagern wird die gesamte Verwaltung des Lagers vom WM-System
übernommen. Die Funktionen, die das Lagerverwaltungssystem in diesem Fall wahrnehmen
muß, sind vergleichbar mit denen im manuellen Lager, u.a.:
· Verwaltung der Materialbestände und der Lagerplätze
· Erstellung von Lagerbewegungen (Ein-/Aus-/Umlagerungen sowie Umbuchungen)
· Ermittlung der Lagerplätze für die Bewegungen mit festgelegten Ein- und
Auslagerungsstrategien
· Durchführung der Inventur
Vom Fremdsystem wird nur eine einfache Lagersteuerung übernommen, d.h. der Transport und
die Durchführung der Lagerbewegung. Im einzelnen die möglichen Funktionen:
· Steuerung der Förderfahrzeuge bzw. Regalbediengeräte
· Steuerung des Materialflusses
Bei diesem Szenario sollte überlegt werden, ob eine Schnittstelle zwischen WM und
Fremdsystem überhaupt notwendig ist. Eine einfache Barcode-Schnittstelle wäre in diesem Fall
auch eine effiziente Lösung. In den folgenden Beispielen für die Ein- und Auslagerung werden
keine Daten vom WM an das Fremdsystem versendet, lediglich die Rückmeldung der
Lagerbewegungen vom Fremdsystem erfolgt über diese Schnittstelle.

Einlagerung
Funktionsverteilung zwischen WM und Fremdsystem
WM:
· Anstoßen von Warenbewegungen
· Bestimmen Ziel für die Einlagerung
· Erstellung von Transportaufträgen für die Einlagerung. Dabei wird:
- Der Lagerplatz für die Einlagerung ermittelt
- Ein Begleitpapier (Palettenschein) mit dem Lagerplatz als Barcode gedruckt
Fremdsystem:
· Einscannen Barcode aus dem Begleitpapier, um die Palette einzulagern
· Transportieren Palette zum Ziel und einlagern
· Rückmeldung der Lagerbewegungen an WM
Schnittstelle Fremdsystem an WM
WM:
· Quittieren zurückgemeldeter Transportaufträge

April 2001 133


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Halbautomatisches Lager: Szenario 2

Die Transportaufträge werden nur in Papierform als Palettenbegleitschein ausgedruckt. Dabei


wird der Lagerplatz für die Einlagerung als Barcode angelistet. Die Palette wird zum
Regalbediengerät transportiert. Am Regalbediengerät wird der Barcode eingescannt, um den
Lagerplatz anzusteuern. Die Palette wird zu diesem Lagerplatz befördert und eingelagert.
Soll die Lagerbewegung vom Fremdsystem an das zurückgemeldet werden, müssen die
Rückmeldedaten in Form des Standard-IDocs WMTCID01 auf der Fremdsystemseite aufgebaut
und an SAP versendet werden, damit in SAP der Transportauftrag quittiert werden kann.

Auslagerung
Funktionsverteilung zwischen WM und Fremdsystem
WM:
· Initiierung der Lagerbewegungen
· Bestimmen Art und Umfang der Auslagerung
· Erstellung von Transportaufträgen für die Auslagerung. Dabei wird:
- Der Lagerplatz für die Auslagerung ermittelt
- Eine Auslagerungsliste (Kommi-Liste) mit dem Lagerplatz als Barcode gedruckt
Fremdsystem:
· Scannen die einzelnen Lagerplätze aus der Auslagerungsliste, um alle Paletten zu einem
Transportauftrag auszulagern bzw. um beim direkten Kommissionieren im Lager die
Lagerplätze anzufahren
· Auslagern Palette bzw. Kommissionieren direkt am Lagerplatz
· Rückmeldung der Lagerbewegungen bzw. des Kommissioniervorgangs an WM
(Schnittstelle Fremdsystem an WM)
WM:
· Quittieren der zurückgemeldeten Transportaufträge
Die Transportaufträge werden nur in Papierform als Auslagerungslisten bzw. Kommi-Listen
ausgedruckt. Dabei werden die beteiligten Lagerplätze als Barcode angelistet. Müssen die
einzelnen Paletten ausgelagert werden, z.B. es werden volle Paletten versendet oder die
Kommissionierung erfolgt nicht direkt im Lager, sondern in einem Kommissionierbereich, wird die
Auslagerung der einzelnen Paletten durch Scannen des Barcodes aus der Liste veranlaßt.
Erfolgt die Kommissionierung direkt im Lager, wird durch das Scannen des Barcodes das
Regalbediengerät zum entsprechenden Lagerplatz befördert.
Soll die Auslagerung bzw. die Kommissionierung vom Fremdsystem an das WM zurückgemeldet
werden, müssen die Rückmeldedaten in Form des Standard-IDocs WMTCID01 auf der
Fremdsystemsseite aufgebaut und an SAP versendet werden, damit in SAP der Transportauftrag
quittiert werden kann.

134 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Vollautomatisches Lager: Szenario 3

Vollautomatisches Lager: Szenario 3


Einsatzmöglichkeiten
Das Fremdsystem soll die Lagersteuerung und bei Bedarf einen bestimmten Teil der
Lagerverwaltung übernehmen.
Grundsätzlich kommen die Szenarios 3, 4 und 5 in Verbindung mit einem automatischen Lager in
Betracht. In diesem Abschnitt wird das Szenario 3 beschrieben. Soll in der Praxis eine
Entscheidung über den Einsatz des WM im automatischen Lager getroffen werden, sollten Sie
alle drei Szenarios berücksichtigen.
Bei einem vollautomatischen Lager müssen einerseits die Gesamtheit des Lagers und
andererseits die Spezifikationen der Lagerautomatik betrachtet werden, um zu entscheiden, wie
sinnvollerweise die Funktionsverteilung innerhalb dieses Lagers zwischen WM und Fremdsystem
erfolgen soll. Es gibt keine pauschale Lösung für die Funktionsverteilung; sie muß
kundenindividuell bzw. projektspezifisch betrachtet werden. Grundsätzlich wird die
Lagerverwaltung wie bei den anderen Szenarios mittels WM-System durchgeführt, u.a.:
· Verwaltung der Materialbestände und der Lagerplätze
· Erstellung von Lagerbewegungen (Ein-/Aus-/Umlagerungen sowie Umbuchungen)
· Ermittlung der Lagerplätze für die Bewegungen mit festgelegten Ein- und
Auslagerungsstrategien
Vom Fremdsystem wird die gesamte Lagersteuerung übernommen:
· Steuerung der Förderfahrzeuge
· Steuerung des Materialflusses
· Optimierung der Ressourcen
Nicht immer lassen sich alle Funktionen der Lagerverwaltung ausschließlich im WM
unterzubringen. Es gibt sinnvolle Aufteilungen der Funktionen der Lagerverwaltung zwischen den
beiden Systemen, die aber von Fall zu Fall unterschiedlich sein können. Dabei spielt der
Automatisierungsgrad des Lagers eine wesentliche Rolle. Bei einem einfachen automatischen
Lager wird in vielen Fällen die gesamte Lagerverwaltung mittels WM erfolgen. Das Fremdsystem
übernimmt nur die Funktionen der Lagersteuerung, wobei eine Optimierung der vom WM
erstellten Lagerbewegungen durch die Lagersteuerung sinnvoll durchgeführt werden kann. Bei
höherer Lagerautomatisierung muß oft bei der Erstellung des Transportauftrags auch die
Lagertechnik mitberücksichtigt werden, damit sie optimal ausgenutzt wird. Beispielsweise werden
verschiedene Kommissionierpunkte der Lagertechnik bei der Auslagerung über die
Bewegungsart des Transportauftrags angesteuert. In den folgenden Beispielen wird eine
Möglichkeit der Funktionsverteilung zwischen WM und Fremdsystem in einem Lager mit relativ
hohen Automatisierungsgrad skizziert.
Ein einfaches Lager wird dagegen wie im ersten Szenario beschrieben. Die Nutzung der
Schnittstelle zwischen WM und Fremdsystem unterscheidet sich in diesem Fall in keiner Weise
von der Schnittstelle zwischen einem manuellen Lager und einem Staplerleitsystem.

April 2001 135


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Vollautomatisches Lager: Szenario 3

Ablauf
Einlagerung über I-Punkt
Funktionsverteilung zwischen WM und Fremdsystem
WM:
· Initiierung der Lagerbewegungen
· Bestimmen des Ziels für die angelieferte bzw. vorbereitete Palette
· Erstellung von Transportaufträgen von der WE-Zone zum I-Punkt; dabei wird die
Palettennummer als Barcode auf dem Palettenschein angedruckt.
· Versenden erstellter Transportaufträge an das Fremdsystem
Schnittstelle WM Fremdsystem
Fremdsystem:
· Einscannen Barcode aus dem Palettenschein im I-Punkt, um die Palette zu identifizieren
· Ermitteln des Palettentyps durch Konturenkontrolle und Vergeben des Einlagerplatzes
· Einlagern Palette
· Melden der eingelagerten Palette an WM
Schnittstelle Fremdsystem WM
WM:
· Erstellen Transportaufträge für die gemeldeten Palettenbewegungen
Im WE-Bereich wird die angelieferte Palette (Lagereinheit) mit SAP-Mitteln vereinnahmt bzw. die
Palette wird zuerst gebildet. Danach wird im WM anhand der anwendungsbezogenen Daten das
Ziel für die einzulagernde Palette bestimmt. Bei der Zielermittlung wird entweder nur der
Lagertyp oder direkt der Lagerplatz eines Lagertyps zum Einlagern bestimmt. Erfolgt die
Einlagerung wie in diesem Beispiel über I-Punkt, wird ein Transportauftrag vom WE-Bereich zum
I-Punkt eines automatischen Lagers erstellt. Dieser Transportauftrag wird mit den notwendigen
Daten an das Fremdsystem mit dem Standard-IDoc WMTOID01 versendet. Mit diesem IDoc wird
u.a. die Palettennummer übergeben.
Die einzulagernde Palette wird zum I-Punkt transportiert. Am I-Punkt wird sie mittels Barcode
vom Fremdsystem identifiziert. Da bei der Einlagerung die Förderfahrzeuge optimal ausgelastet
werden sollen, wird der Lagerplatz vom Fremdsystem vergeben. Die Palette wird eingelagert und
an WM gemeldet. Das Melden der Bewegung einer Palette erfolgt über das Standard-IDoc
WMSUID01. Die Palettendaten mit dem Lagerplatz müssen in Form dieses IDocs auf der
Fremdsystemseite aufgebaut und an SAP versendet werden, damit in SAP für die bewegte
Palette ein Transportauftrag erstellt und dadurch die vom Fremdsystem erzeugte Bewegung im
WM-System nachgebucht werden kann.

Auslagerung über K-Punkt


Funktionsverteilung zwischen WM und Fremdsystem
WM:
· Initiierung der Lagerbewegungen
· Bestimmen Art und Umfang der Auslagerung

136 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Vollautomatisches Lager: Szenario 3

· Erstellung von Transportaufträgen vom Lager zum WA- bzw. Kommissionierbereich.


· Versenden erstellter Transportaufträge an das Fremdsystem
Schnittstelle WM an Fremdsystem
· ( Versenden Freigabe der Gruppe an Fremdsystem
Schnittstelle WM Fremdsystem
Fremdsystem:
· Bestimmen der optimalen Reihenfolge für die Auslagerung der einzelnen Paletten
· Auslagern einzelner Paletten zu einem vom Fremdsystem ermittelten K-Punkt
· Kommissionierung am K-Punkt mit der Visualisierung der einzelnen
Kommissionierpositionen
· Bestätigung der Entnahme und Rückmeldung an WM versenden
Schnittstelle Fremdsystem WM
· Ermitteln Lagerplatz für Rücklagerung einer Palette, die durch die Entnahme nicht
geleert wurde
· Palette Rücklagern
· Melden der zurückgelagerten Palette an WM
Schnittstelle Fremdsystem an WM
WM:
· Quittieren der zurückgemeldeten Transportaufträge
· Erstellen Transportaufträge für die gemeldeten Palettenbewegungen
Im WM-System wird eine Auslagerung bzw. eine Kommissionierung veranlaßt. Der Umfang und
die Art der Warenentnahme hängt von sehr vielen Kriterien ab; als Beispiel werden mehrere
Lieferscheine einer Route in einen Kommissioniervorgang zusammengefaßt. Für diese
Lieferscheine werden Transportaufträge erstellt und an das Fremdsystem mit dem Standard-
IDoc WMTOID01 übergeben.
Dabei gibt es zwei Möglichkeiten der Kommissionierung:
1. Die Kommissionierung erfolgt lieferscheinbezogen, d.h. jeder versendete
Transportauftrag wird vom Fremdsystem als eigenständiger Kommissionierauftrag
behandelt.
2. Die Kommissionierung erfolgt nicht lieferscheinbezogen, sondern wie im Beispiel
bezogen auf eine Route, d.h. die versendeten Transportaufträge dürfen nicht gleich
kommissioniert werden. Erst wenn alle Transportaufträge zu einer Route versendet
werden, kann mit dem Kommissionieren angefangen werden. Der Start zum
Kommissionieren dieser Aufträge wird im WM-System durch Freigabe der Gruppe
gegeben. Die Freigabe der Gruppe wird an das Fremdsystem mit dem Standard-IDoc
WMRRID01 versendet.
Der vom WM versendete Kommissionierauftrag, der aus einem oder mehreren
Transportaufträgen besteht, wird vom Fremdsystem verarbeitet. Die einzelnen
Lagerbewegungen, die aus dem Kommissionierauftrag resultieren, werden vom Fremdsystem
optimiert, d.h. das Fremdsystem bestimmt in welcher Reihenfolge die einzelnen Paletten

April 2001 137


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Vollautomatisches Lager: Szenario 3

ausgelagert werden. Falls es mehrere K-Punkte gibt, wird auch die Zuordnung der einzelnen
Kommissioniervorgänge bzw. Paletten zu den einzelnen K-Punkten vom Fremdsystem
übernommen. Nur das Fremdsystem kann eine optimale K-Punkt-Zuordnung treffen, da auch
hier die Auslastung der Ressourcen der Lagertechnik eine sehr große Rolle spielt. Die
Kommissionierung erfolgt am K-Punkt. Die zu kommissionierende Ware und Menge wird vom
Fremdsystem am begleitenden Bildschirm des K-Punkts angezeigt. Die Kommissionierung wird
bestätigt und bei Abweichungen die Differenzen erfaßt. Der Kommissioniervorgang wird an WM
zurückgemeldet. Die Rückmeldung erfolgt über das Standard-IDoc WMTCID01, wobei hierfür die
einzelnen Paletten (Lagereinheiten) zurückgemeldet werden. Die Rückmeldedaten mit
eventuellen Differenzen müssen in Form dieses IDocs auf der Fremdsystemseite aufgebaut und
an SAP versendet werden, damit in SAP die Entnahme zu einer Lagereinheit und dadurch auch
alle für eine Lagereinheit relevanten Transportauftragspositionen quittiert werden.
Alle Paletten, die durch die Entnahme nicht geleert wurden, müssen zurückgelagert werden. Die
Paletten werden zum I-Punkt transportiert. Durch die Konturenkontrolle wird ein neuer
Palettentyp und ein entsprechender Lagerplatz bestimmt. Die Palette wird eingelagert und wie
bei der normalen Einlagerung mittels des Standard-IDocs WMSUID01 an WM gemeldet.

Sperren Lagerplätze
Bei den automatischen Lagern kommt es oft vor, daß bestimmte Lagerplätze nicht angefahren
werden können. Entweder fallen bestimmte Strecken von Förderfahrzeugen aus oder einige
Lagerplätze können von der Lagertechnik nicht mehr erreicht werden. Da die
Lagerplatzverwaltung im WM erfolgt, müssen diese Lagerplätze schnellstmöglich auch im WM
gesperrt werden, damit keine Lagerbewegungen mehr für diese Lagerplätze erstellt werden. Das
Sperren der einzelnen Lagerplätze erfolgt mit dem Standard-IDoc WMBBID01. Die einzelnen
Lagerplätze bzw. ganze Gassen müssen in Form dieses IDocs vom Fremdsystem an WM
versendet werden. Sollen die gesperrten Lagerplätze wieder entsperrt werden, müssen die
betroffenen Lagerplätze bzw. Gassen mit IDocs des gleichen Aufbaus vom Fremdsystem an WM
übergeben werden.

138 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Vollautomatisches Lager - Blackbox: Szenario 4

Vollautomatisches Lager - Blackbox: Szenario 4


Einsatzmöglichkeiten
Das Fremdsystem soll alle Lagerfunktionen ausführen und die gesamte Lagerverwaltung sowie
Lagersteuerung für ein bestimmtes Lager übernehmen.
Grundsätzlich kommen die Szenarios 3, 4 und 5 in Verbindung mit einem automatischen Lager in
Betracht. In diesem Abschnitt wird das vierte Szenario beschrieben. Soll in der Praxis eine
Entscheidung über den Einsatz des WM im automatischen Lager getroffen werden, sollten Sie
alle drei Szenarios berücksichtigen.
Bei einem Lagerkomplex mit vielen verschiedenen Lagern (aus SAP-Sicht sind es verschiedene
Lagertypen) können in den einzelnen Lagern unterschiedliche Lagertechniken benutzt werden.
Möglich wäre ein Lager mit mehreren manuellen und einem oder mehreren automatischen
Lagertypen. Der automatische Lagertyp hat einen sehr hohen Automatisierungsgrad und ist in
seiner Struktur und der verwendeten Lagertechnik sehr komplex. Die Verwaltung dieses
Lagertyps ist direkt mit der Lagersteuerung verdrahtet, d.h. um eine Lagerbewegung zu
definieren, werden direkt die Informationen über den aktuellen Zustand der Lagertechnik
benötigt. In diesem Fall wäre mit einer sehr hohen Zahl an Kommunikationsvorgängen zwischen
WM und dem Fremdsystem zu rechnen. Außerdem ist diese Kommunikation sehr zeitkritisch,
d.h. bestimmte Ereignisse im Lagersteuerrechner führen dazu, daß die Lagerverwaltung direkt
reagieren muß. Die asynchrone Schnittstelle, die momentan für die Kommunikation zwischen
WM und Fremdsystem benutzt wird, eignet sich für solch ein dynamisches Lager nicht. Für die
Verwaltung dieses Lagertyps ist es sinnvoller, ein System einzusetzen, das sowohl die
Lagerverwaltung als auch die Steuerung in einem Software-Paket anbietet.
Da der automatische Lagertyp nur ein Teil des Lagerkomplexes darstellt und die meisten Lager
manuell verwaltet werden, kann das WM für den gesamten Lagerkomplex eingesetzt werden.
Das WM verwaltet den gesamten Lagerkomplex und verteilt die einzelnen Ein- und
Auslagerungsvorgänge auf die einzelnen Lagertypen. In manuellen Lagern wird die gesamte
Lagerverwaltung vom WM gesteuert. Das automatische Lager wird vom WM als ‘Blackbox’
betrachtet, d.h. das WM kennt in dem Lager keine Lagerplatzbestände.

Ablauf
Bei diesem Szenario werden vom WM folgende Funktionen für das automatische Lager
übernommen:
· Verwaltung der summarischen Bestände pro Material
· Anstoß und Erstellung von Warenbewegungen
Das Fremdsystem übernimmt die gesamte Lagerverwaltung und Lagersteuerung innerhalb
dieses Lagertyps, u.a.:
· Ermittlung der Lagerplätze für die einzelnen Bewegungen
· Erstellung von Lagerbewegungen innerhalb des Lagertyps
· Durchführung der Inventur
· Steuerung der Förderfahrzeuge
· Steuerung des Materialflusses
· Optimierung der Ressourcen

April 2001 139


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Vollautomatisches Lager - Blackbox: Szenario 4

Das automatische Lager wird im WM als ein bestimmter Lagertyp definiert. Es gibt mehrere
Möglichkeiten, wie der Lagertyp vom WM verwaltet wird:
1. Der Lagertyp ist mit einem festen Lagerplatz definiert (analog einem
Schnittstellenlagertyp), und alle Bestände werden auf diesem Lagerplatz verwaltet.
2. In dem Lagertyp werden mehrere Lagerplätze definiert, die aber nicht den physischen
Lagerplätzen entsprechen. Die Zulagerung im Lager muß erlaubt sein, so daß ein
Lagerplatz immer mit einem Material belegt wird. Dadurch werden die Bestände eines
Materials auf einem Lagerplatz kumuliert; ein neues Material belegt immer einen neuen
Lagerplatz. Diese Art der Verwaltung kann eingesetzt werden, falls Sie bei der
Möglichkeit 1 Probleme mit der Lagerplatzsperre bekommen.
Der Lagerplatz in WM hat keine Bedeutung für das Fremdsystem.
Im folgenden Beispielen wird eine Möglichkeit der Funktionsverteilung zwischen WM und
Fremdsystem für dieses Lager beschrieben:
WM:
· Kommunikation mit anderen SAP-Anwendungskomponenten wie SD, MM und PP
· Anstoßen von Warenbewegungen
· Erstellung von Transportaufträgen
· Versenden der erstellten Transportaufträge an das Fremdsystem; dabei sind die
Materialidentifikation, die Menge und der Verursacher der Bewegung, nicht aber der
Lagerplatz von Bedeutung
Schnittstelle WM an Fremdsystem
Fremdsystem: :
· Bestimmung von Lagerplätzen für die Ein- und Auslagerung
· Optimierung des Materialflusses
· Durchführung der einzelnen Warenbewegungen
· (Rückmeldung der Warenbewegungen an WM
Schnittstelle Fremdsystem an WM)
· Durchführung der Inventur
· Melden von Differenzen an WM
Schnittstelle Fremdsystem an WM
· Anstoß und Durchführung lagerinterner Bewegungen wie Umlagerungen
WM:
· (Quittierung der zurückgemeldeten Transportaufträge)
· Erstellung von Transportaufträgen für die gemeldeten Differenzen
Das WM übernimmt die Kommunikation mit den anderen SAP-Anwendungskomponenten für den
gesamten Lagerkomplex und somit auch für das automatische Lager. Bei einem Wareneingang
wird das WM vom MM über eine anstehende Einlagerung informiert. Das WM erstellt für den
Wareneingang einen Transportauftrag mit einer oder mehreren Positionen. Dabei wird das Ziel
der Einlagerung bestimmt, d.h in welchen Lagertyp die einzelne Ware eingelagert werden soll.

140 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Vollautomatisches Lager - Blackbox: Szenario 4

Wird das automatische Lager für die Einlagerung bestimmt, werden die betroffenen
Transportauftragspositionen mit dem Standard-IDoc WMTOID01 an das Fremdsystem
übergeben. Die weitere Verarbeitung des Einlagerungsvorgangs wird vom Fremdsystem
übernommen. Die Identifikation der einzulagernden Ware erfolgt im Fremdsystem entweder über
die versendeten Transportauftragsnummer und -Positionen oder über die
Lagereinheitennummer. Diese Lagerbewegung muß nicht unbedingt an das WM zurückgemeldet
werden.
Bei der Auslagerung bzw. Kommissionierung wird im WM der Umfang des Vorgangs bestimmt
und ein oder mehrere Transportaufträge erstellt. Auch in diesem Fall können bei einem
Kommissioniervorgang mehrere Lagertypen betroffen sein. Alle für das automatische Lager
relevanten Transportauftragspositionen werden im WM aufbereitet und mit dem Standard-IDoc
WMTOID01 an das Fremdsystem übergeben. Im Fremdsystem erfolgt die Entscheidung, aus
welchem Lagerplatz die Ware optimal ausgelagert bzw. kommissioniert wird. Wird die
Kommissionierung im Fremdsystem durchgeführt, sollte auch der Kommissioniervorgang an das
WM zurückgemeldet werden. Die Rückmeldedaten müssen in Form des Standard-IDocs
WMTCID01 auf der Fremdsystemseite aufgebaut und an das SAP-System versendet werden,
damit die einzelnen Transportauftragspositionen mit den Istmengen im SAP-System quittiert
werden können.
Werden Differenzen im Fremdsystem festgestellt, entweder durch eine Inventur oder im
laufenden Betrieb, müssen sie unbedingt an das WM gemeldet werden. Für die einzelnen
Differenzen eines Materials muß im Fremdsystem das Standard-IDoc WMTOID01 erzeugt und
an das WM versendet werden. Im WM wird aus dem IDoc ein Transportauftrag erstellt, um die
Differenz vom Lager auf eine Differenzenschnittstelle zu buchen.
Die lagerinternen Bewegungen müssen nicht an das WM versendet werden, da im WM nur der
summarische Bestand verwaltet wird.

April 2001 141


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Schnittstelle zu einem WM-Fremdsystem Szenario 5

Schnittstelle zu einem WM-Fremdsystem Szenario 5

Lieferant
Einlagerung
WE-Zone
Fertigung

Kunde
WA-Zone
Fertigung Auslagerung

SAP
- MM: Materialwirtschaft
- PP: Produktionsplanung Fremd-LVS
- SD: Versand/Vertrieb

Einsatzmöglichkeiten
Das Fremdsystem übernimmt für ein gesamtes Lager alle Lagerfunktionen sowohl der
Lagerverwaltung als auch der Lagersteuerung.
Grundsätzlich kommen die Szenarios 3, 4 und 5 in Verbindung mit einem automatischen Lager in
Betracht. In diesem Abschnitt wird das Szenario 5 beschreiben. Soll in der Praxis eine
Entscheidung über den Einsatz des WM im automatischen Lager getroffen werden, sollten Sie
alle drei Szenarios berücksichtigen.
Bei Einsatz eines WM-Systems erfolgt die Kommunikation zwischen SAP-WM und dem
Fremdsystem. D.h. eine Schnittstelle von der Materialwirtschaft (MM), dem Versand (SD) oder
Produktionsplanung (PP) zum Fremdsystem ist in diesem Fall für alle Lagervorgänge nicht mehr
notwendig, da zuerst immer das WM-System aktiviert wird. Es gibt aber Lager, für die der
Einsatz eines Fremd-Lagerverwaltungssytems (kein SAP-WM) durchaus geeignet wäre.
Grundsätzlich kann man folgende Gründe für den Einsatz eines Fremd-WMS nennen:
· Das Lager ist vollautomatisch mit sehr komplexen Lagertechniken. D.h. zu Grunde liegt
ein Lager wie im Szenario 4, dabei gibt es aber keine Lager mehr, die mit
herkömmlichen Methoden verwaltet werden. Das WM soll normalerweise, wie im
Szenario 4 beschrieben, in einem Lager mit sehr hohem Automatisierungsgrad nicht
eingesetzt werden.
· Die Funktionalität des WM-Systems reicht zu einem hohen Grad nicht aus, um das
Lager zu verwalten. Der Aufwand für die Anpassung der Standards an die
Anforderungen des Lagers sind zu hoch.
· Der Kunde setzt das SAP-System in einem Lagerbereich ein, der bereits mit einer
Software für die Lagerverwaltung gefahren wird. Dieses Lagerverwaltungssystem soll
unbedingt beibehalten werden.
Das SAP-System bietet momentan keine Standardschnittstelle für die Anbindung der einzelnen
Anwendungskomponenten MM, SD und PP zu einem fremden Lagerverwaltungssystem. Die

142 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Schnittstelle zu einem WM-Fremdsystem Szenario 5

Ankopplung eines fremden WMS müssen Sie in eigener Regie realisieren, z.B. in einem
Projekt mit dem Anbieter dieses Systems. Dabei können Sie bestimmte SAP-Standard-Objekte
nutzen:

Bestandsführung (MM):
· MM - Fremd-WMS:
In der Bestandsführung kann beim Verbuchen eines Materialbeleges ein User-Exit
‘MB_CF001’ aktiviert werden. Dieser User-Exit kann benutzt werden, um die
notwendigen Daten für das Fremd-WMS kundenindividuell vorzubereiten und zu
versenden. Hierfür können Sie das Standard-IDoc WMMBID01 verwenden. In der Doku
des User-Exits ist ab Rel.3.0C Beispielcoding vorhanden.
· Fremd-WMS - IM:
Das Melden der Lagerbewegungen vom Fremd-WMS an IM kann über das Standard-
IDoc WMMBID01 analog der MDE-Anbindung erfolgen.

Produktionsplanung (PP):
In der Produktionsplanung gibt es ab Release 3.0C einen User-Exit bei den Fertigungsaufträgen.
Dieser ist über die Transaktion /nCMOD zur Entwicklungsklasse ‘CO’ zu finden.
Ab Release 3.0D stellt SAP einen User-Exit zur Verfügung, um auch Transportbedarfe zu
Bereitstellungen für Fertigungsaufträgen (WM-PP-Kopplung) an ein Fremdsystem versenden zu
können. Auch hierfür ist in der Doku des Exits Beispielcoding vorhanden.

Verkauf/Versand (SD):
· SD - Fremd-WMS:
Mit dem Standard-IDoc SDPIOD01 werden Kommissionieraufträge vom Versand an ein
Fremdsystem versendet.
· Fremd-WMS - SD:
Die Rückmeldung der Kommissionierung vom Fremdsystem an Versand wird über das
Standard-IDoc SDPIID01 durchgeführt.
Die Rückmeldung der Versandelemente vom Fremdsystem an Versand wird über das
Standard-IDoc SDPAID01 durchgeführt.

April 2001 143


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
WM-Schnittstelle zu Nicht-Lagersystemen

WM-Schnittstelle zu Nicht-Lagersystemen
Das WM-System kann auch an andere Systeme (keine Lagersysteme) angekoppelt werden. In
diesem Szenario handelt es sich normalerweise um Systeme, die an das WM-System
Anforderungen an Lagerbewegungen versenden. Es werden Ankündigungen für Wareneingänge
oder Bedarfe für Warenausgänge versendet. Folgende Systeme betrifft diese Anbindung:
· Fremde Kommissionier- bzw. Versandsysteme
· Fremde Produktionsplanungs- und Steuerungssysteme
· Fremde Bestandsführungssysteme
Die vom WM empfangenen Anforderungen bzw. Ankündigungen werden als Transportbedarfe
angelegt. Diese können auf verschiedene Art und Weise im WM in Transportaufträge umgesetzt
werden. Momentan beinhaltet diese Schnittstelle nur den Weg vom Fremdsystem zum WM. Eine
Rückmeldung der Anforderungen nach erfolgten Lagertransporten ist im Standard nicht
vorgesehen.
Im folgenden Beispiel wird das Versenden von Anforderungen für Kommissionierung bzw.
Warenbereitstellung beschrieben:

Fremdsystem:
· Bestimmen Umfang der Kommissionierung bzw.
· Bereitstellung Melden Anforderungen an WM
Schnittstelle Fremdsystem WM
WM:
· Erstellen Transportbedarfe für die gemeldeten Anforderungen
· Umsetzen Transportbedarfe in Transportaufträge
· Durchführung der Kommissionierung bzw. Bereitstellung
Die Anforderungen müssen in Form des Standard-IDocs WMTRID01 auf der Fremdsystemseite
aufgebaut und an SAP versendet werden. Dabei wird bestimmt, welche Materialien, mit welcher
Menge, wann kommissioniert werden sollen, und wohin die kommissionierten Mengen
transportiert werden sollen. Auf der WM-Seite werden aus diesen IDocs Transportbedarfe
erstellt, die später mit WM-Mitteln in Transportaufträge umgesetzt werden.

144 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Datenfluß: Technische Beschreibungen

Datenfluß: Technische Beschreibungen


Im ersten Abschnitt wird der Datenfluß beim Senden und Empfangen von Transportaufträgen
zwischen dem WM und dem Fremdsystem inklusive Fehlerbearbeitung und
Sicherheitsmechanismen beschrieben. Der zweite Teil befaßt sich dann mit der
programmtechnischen Realisierung der Schnittstelle.
Dabei wird zuerst das Senden von Daten an ein Fremdsystem erklärt, anschließend das
Empfangen der Daten vom Fremdsystem.
Der Datenfluß wird anhand des Beispiels Transportauftrag dargestellt. Ein Transportauftrag bildet
innerhalb der Lagerverwaltung das zentrale Medium, um Materialien von Platz A zu Platz B zu
transportieren. Bei der Erstellung des Transportauftrags laufen im System Suchstrategien etc.
ab.
Wie sich die Transportauftragserstellung betriebswirtschaftlich in das Konzept der Schnittstelle
einfügt, wird im Abschnitt der Szenarios beschrieben.

April 2001 145


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Senden von Transportaufträgen

Senden von Transportaufträgen


Die folgende Übersicht stellt den Sendevorgang schematisch dar.

WM
Erstellen Transportauftrag WM
WM
Vorbereiten IDoc

ALE IDoc
IDoc
Zwischensichern Daten

RFC tRFC
Aufbau Kommunikation / Senden
tRFC

Fremdsystem
CC--Programm
Programm
Daten empfangen

Verarbeiten Anwendung
Anwendung

Erstellen eines Transportauftrags im WM


Im WM werden Transportaufträge auf verschiedene Weise erstellt, entweder manuell,
automatisch als Folgeverarbeitung oder im Sammelgang.
Entscheidend ist jetzt die Frage, ob ein Transportauftrag relevant für ein Fremdsystem ist oder
nicht. Im Einführungsleitfaden ’Steuerung der Schnittstelle zum Fremdsystem’ kann dies
individuell definiert werden. Innerhalb einer Lagernummer kann für einen Lagertyp bzw. eine
bestimmte Bewegungsart eine Transportauftragsposition für diese Schnittstelle aktiviert und der
Empfänger dieser Lagerbewegung festgelegt werden.

Tabelle: Steuerung der Schnittstelle


Lnr Vontyp Nachtyp BWA Laufnr. Inaktiv EmpfSystem Variante
001 *** HRL FREMDSYSTEM
001 HRL *** FREMDSYSTEM
Alle Transportauftragspositionen, d.h. alle Lagerbewegungen für den Lagertyp HRL, würden im
Beispiel weitergemeldet. Die Daten des Transportauftrags werden im WM aufbereitet und im
IDoc-Format intern an einen Funktionsbaustein von ALE weitergegeben.

146 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Senden von Transportaufträgen

Zwischensichern von Daten


Innerhalb derselben logischen Verarbeitungseinheit (LUW) werden die Daten vom
Funktionsbaustein der ALE-Schicht in Form von Repository- (Data Dictionary) Strukturen
aufbereitet. Diese Strukturen werden als IDoc (Intermediate Document) bezeichnet. Die erstellten
IDocs werden in der Datenbank gesichert.
Informationen zur Definition eines IDocs bzw. zum Aufbau der verschiedenen IDocs finden Sie
unter Beschreibung der IDocs [Seite 164].

Kommunikation und Versenden


Asynchron zum Erstellen des Transportauftrags und des IDocs, d.h. nach dem Erstellen des
IDocs, wird von ALE das Versenden des IDocs angestoßen. IDocs können direkt versendet oder
zuerst gesammelt und in einem Paket von mehreren IDocs versetzt verschickt werden.
Beim Versenden der IDocs bedient sich ALE der Technik des Remote Function Call. Dabei wird
im Fremdsystem eine Remote Shell gestartet und ein C-Programm aufgerufen, an das die
aufzurufende Funktion innerhalb des Programms übergeben wird. Die zugrundeliegende
Technik, die das Versenden protokollarisch korrekt ablaufen läßt, ist oben als RFC-Schicht
visualisiert. Programmseitig steht eine ganze Bibliothek von C-Programmen zur Abwicklung zur
Verfügung, die allerdings verborgen ausgeführt werden.
Informationen zur Erstellung des C-Programms und zu den Systemeinstellungen für die
Verbindung finden Sie an späterer Stelle in der technischen Dokumentation.

Aufgaben des Fremdsystems


Auf dem Fremdsystem muß das C-Programm zum Empfangen der Daten zur Verfügung stehen.
Dazu gibt es ein Beispielprogramm. Unterstützt wird dies durch die RFC-Bibliothek, die Sie von
SAP ausgeliefert bekommen.
Das Programm muß die Daten seinerseits nach dem Empfangen zwischensichern, bevor die
Empfangsbestätigung an R/3 zurückgeht. Dann kann die Verarbeitung der Daten beginnen. Wir
empfehlen das Zwischensichern, damit auch auf dem Fremdsystem die Kommunikation von der
Verarbeitungslogik getrennt abläuft.
Außerdem sollte das Fremdsystem eine Statusverwaltung der empfangenen Daten vorsehen.
Damit kann eine Doppeltverarbeitung verhindert werden. Weiterhin muß das Fremdsystem in der
Lage sein zu erkennen, ob IDocs schon einmal vom R/3 System gesendet wurden. Dies wird
durch eine eindeutige Transaktions-ID pro Kommunikationsvorgang ermöglicht. (Siehe auch die
technische Dokumentation des RFC). Außer der Transaktions-ID kann die doppelte Übertragung
eines IDoc auch anhand der IDoc-Nummer erkannt werden. Die IDoc-Nummer ist nur innerhalb
eines Mandanten eines SAP-Systems eindeutig. Erfolgt die Kommunikation mit mehreren
Mandanten bzw. mehreren SAP-Systemen, kann die Eindeutigkeit der IDocs nur anhand der
IDoc-Nummer nicht erkannt werden.

Fehlerbearbeitung
Beim Versenden eines IDocs können typischerweise folgende Probleme auftreten:

Verbuchungsabbruch in der Anwendung (z.B. bei TA-Erstellung)


Dies ist nicht interessant für die Kommunikation, da ohne Transportauftrag auch kein IDoc erstellt
wird. Beide Verbuchungen laufen in derselben LUW ab und werden daher synchron verbucht.

April 2001 147


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Senden von Transportaufträgen

Fehler in der ALE-Schicht


1. Die im WM vorbereiteten und an ALE versendeten Daten sind syntaktisch falsch. Das
IDoc wird zwar von ALE übernommen und gesichert, kann aber nicht versendet werden.
Weitere Informationen zu diesem Fehler finden Sie unter SAP-Systemeinstellungen und
Modifikationskonzept [Seite 215].
2. Die Partnervereinbarung des Ausgangs ist für den Empfänger und Nachrichtentyp des
IDocs im ALE nicht definiert. Das IDoc wird zwischengesichert, kann aber nicht
versendet werden. Weitere Informationen zu diesem Fehler finden Sie unter SAP-
Systemeinstellungen und Modifikationskonzept [Seite 215].

Keine Verbindung
Wenn ein IDoc erzeugt wurde, aber die Verbindung nicht aufgebaut werden kann, so stellt ein im
Batch-Processing laufender Report sicher, daß der Kommunikationsanstoß von Zeit zu Zeit
erfolgt. Wird die Verbindung wieder hergestellt, so werden anhängige IDocs automatisch
versendet.

148 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Empfangen von Transportaufträgen

Empfangen von Transportaufträgen


Die folgende Übersicht zeigt, wie Transportaufträge empfangen werden.

Fremdsystem
Fremdsystem
Fremdsystem
Daten aufbereiten

Versenden IDoc
IDoc

RFC tRFC
tRFC
Daten empfangen

ALE IDoc
IDoc
IDoc erzeugen

WM WM
Verarbeiten IDoc
WM

Aufbereitung und Versendung von Daten


Hauptaufgabe des Fremdsystems ist selbstverständlich die Kommunikation mit den Endgeräten,
beispielsweise Staplerleitsysteme, Steuersysteme allgemein, mobile Datenerfassungsgeräte
usw. Gegenstand dieser Abhandlung soll aber die Kommunikation mit dem SAP-R/3-System
sein, nachdem die Daten auf dem Fremdsystem erzeugt wurden. Dabei ergeben sich folgende
Aufgaben:

Zwischensicherung und Aufbereitung der Daten im IDoc-Format


Informationen zur Definition des IDocs bzw. zum Aufbau der verschiedenen IDocs finden Sie in
der entsprechenden Dokumentation.

Aufruf eines zentralen Funktionsbausteins im R/3 mittels Versendeprogramm


Auch für das Versendeprogramm benötigen Sie die RFC-Bibliothek zur Unterstützung Ihrer
Programmierung. Der zentrale Funktionsbaustein gehört wieder zur ALE-Schicht.
In einem Kommunikationsvorgang, d.h. in einem Aufruf des R/3-Funktionsbausteins, können
grundsätzlich mehrere IDocs übergeben werden. Es gibt aber IDoc-Typen, die nur einzeln
versendet werden können. Bei diesen IDocs wird in der weiteren Beschreibung explizit darauf
hingewiesen.

April 2001 149


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Empfangen von Transportaufträgen

Fortschreibung der IDocs nach dem Versenden


Auch beim Versenden muß das Fremdsystem eine Statusverwaltung der versendeten Daten
vorsehen. Sollte das IDoc nicht erfolgreich versendet worden sein, muß es nachversendet
werden.
Auf der SAP-Seite muß die doppelte Übertragung der IDocs auch verhindert werden. Hierfür wird
die Transaktions-ID verwendet, die pro Kommunikationsvorgang auf der SAP-Seite vergeben
wird. Die Daten, die vom Fremdsystem übergeben werden, müssen immer mit dieser
Transaktions-ID versendet werden (siehe auch technische Dokumentation des RFC). Auch beim
Nachversenden muß die gleiche Transaktions-ID mitübergeben werden.
Die IDoc-Nummer wird auf der SAP-Seite zum Prüfen der doppelten Übertragung nicht benutzt.

Empfang und Verbuchung der Daten


ALE empfängt das IDoc und schreibt es in die Datenbank. Nach dieser Zwischensicherung geht
eine Empfangsbestätigung zurück ans Fremdsystem. Danach (asynchron zum Empfangen) wird
das IDoc an die Anwendung weitergereicht, wo die Verarbeitung erfolgt.
Die Anwendung, hier das Erstellen des Transportauftrags, liefert pro IDoc einen Status an ALE
zurück. Dieser IDoc-Status ist Grundlage für das Anstoßen einer möglichen Fehlerbearbeitung.

Fehlerbearbeitung
Folgende Fehler könnten auftreten:

Verbindung kann temporär nicht hergestellt werden


Auch das Fremdsystem sollte über eine Statusverwaltung sicherstellen, daß eine
Nachbuchmöglichkeit besteht.

Fehler in der ALE-Schicht


Ein IDoc wurde erzeugt, aber die Verarbeitung kann nicht angestoßen werden.
Dieser Fehler tritt auf (wie beim Senden vom WM aus), wenn das angekommene IDoc
syntaktisch nicht richtig ist oder die Partnervereinbarung des Eingangs für den Sender und
Nachrichtentyp dieses IDocs fehlt. Weitere Informationen zu diesem Fehler finden Sie unter
SAP-Systemeinstellungen und Modifikationskonzept [Seite 215].

Fehler in der Anwendung (z.B. beim Verbuchen eines Transportauftrags)


Hierbei handelt es sich um einen logischen Fehler in der Anwendung. Anhand des oben
erwähnten Status im IDoc wird eine Nachricht an eine Planstelle versendet. Einer Planstelle
können mehrere Benutzer zugeordnet sein. Jeder der Benutzer erhält in seinem SAP-OFFICE-
Eingangskorb die Fehlernachricht. Sobald ein Benutzer sich die Meldung greift und verarbeitet,
verschwindet die Mitteilung aus den anderen Eingängen.

150 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Programmtechnische Realisierung

Programmtechnische Realisierung
In diesem Abschnitt erhalten Sie einen Überblick über die technische Realisierung einer
Anbindung.
Die Kommunikation basiert auf der SAP-Schnittstelle Remote Function Call (RFC).
Ab dem Release 3.0 können Daten zwischen R/3-Systemen und externen Programmen sicher
und zuverlässig über den transaktionalen Remote Function Call (tRFC) übertragen werden.
Der gerufene Funktionsbaustein wird im RFC-Server-System genau einmal ausgeführt. Das
entfernte System muß zu dem Zeitpunkt, in dem das RFC-Client-Programm einen tRFC ausführt,
nicht verfügbar sein. Die tRFC-Komponente speichert die gerufene RFC-Funktion zusammen mit
den zugehörigen Daten in der R/3-Datenbank unter einer eindeutigen Transaktionskennung
(TID).
Eine ausführliche Beschreibung zur RFC-Schnittstelle finden Sie in der Dokumentation, Remote
Communications [Extern].
Einzelheiten zu TCP/IP-Einstellungen finden Sie in BC - SAP-Kommunikation: Konfiguration
[Extern].
Der vorliegende Abschnitt gibt Ihnen einen Einblick in die Programmtechnik. Er erhebt keinen
Anspruch auf Vollständigkeit.
Wenn Sie selbst eine Anbindung realisieren möchten, sollten Sie unbedingt die weiterfürhrende
Dokumentation lesen.

April 2001 151


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Senden von IDocs an ein Fremdsystem

Senden von IDocs an ein Fremdsystem


Das folgende Schaubild verdeutlicht die Programmablauflogik.

ABAP-Programm
ABAP-Programm
ABAP-Programm



call
callfunction
function‘IDOC_INBOUND_ASYNCHRONOUS‘
‘IDOC_INBOUND_ASYNCHRONOUS‘ TCP/IP-Verbindungen
TCP/IP-Verbindungen
TCP/IP-Verbindungen
ininbackground (Transaktion SM59)
backgroundtask
task (Transaktion SM59)
destination
destinationSubsystem
Subsystem
tables
tables RFC-Destination
RFC-Destination Subsystem
Subsystem
idoc_control_rec_40
idoc_control_rec_40==header
header
idoc_data
idoc_data_rec_40
_rec_40 ==segment
segment
…… Zielmaschine
Zielmaschine hs1022.wdf.sap-ag.de
hs1022.wdf.sap-ag.de
Programm
Programm /users/d11adm/tmp/wmtestl
/users/d11adm/tmp/wmtestl

Fremdprogramm
Fremdprogramm
wmtestl
wmtestl

rfc_handle
rfc_handle==RfcAccept(...);
RfcAccept(...);
… …
rfc_rc
rfc_rc==RfcInstallFunction(...);
RfcInstallFunction(...);
… … RFC-Library
/ /** RFC-Library
**function IDOC_INBOUND_ASYNCHRONOUS
function IDOC_INBOUND_ASYNCHRONOUS saprfc.h
saprfc.h
**/ / sapitab.h
sapitab.h
static
staticRFC_RC
RFC_RCidoc_
idoc_inbound_
inbound_asynchronous
asynchronous(RFC_HANDLE
(RFC_HANDLErfc_handle
rfc_handle) ) librfc.a
librfc.a/ /librfc.dll
librfc.dll/ /ntlibrfc.lib
ntlibrfc.lib…

char
char filenam1
filenam1 == “/users/d11adm/tmp/output1”;
“/users/d11adm/tmp/output1”;
……

Aus dem R/3 werden IDocs über den Aufruf eines der beiden folgenden Funktionsbausteine mit
einer Destination versendet:
· IDOC_INBOUND_ASYNCHRONOUS
Diesen Funktionsbaustein müssen Sie ab Release 4.0 verwenden. Er verarbeitet IDocs
in Satzarten, die zu 4.x gültig sind. Längere IDoc-Segmentnamen werden damit
unterstützt.
· INBOUND_IDOC_PROCESS
Diesen Funktionsbaustein müssen Sie in Releases vor 4.0 verwenden. Er verarbeitet
IDocs in Satzarten, die zu 3.x gültig waren. Aus Gründen der Abwärtskompatibiltät muss
er auch in 4.x verwendet werden können. Auch externe Programme müssen diesen
Funktionsbaustein unterstützen.

152 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Senden von IDocs an ein Fremdsystem

Der Zusatz IN BACKGROUND TASK beim Funktionsaufruf kennzeichnet den transaktionalen


RFC.
Wie bei synchronen Aufrufen definiert der Parameter DESTINATION über eine Tabelle im R/3
die Zielmaschine und das Zielprogramm mit Pfad (Programmkontext) im fernen System.
Beachten Sie auch das ABAP-Testprogramm SRFCTEST.
Im Fremdsystem muß das in der SM59 gepflegte Zielprogramm existieren, welches seinerseits
eine Funktion mit dem Namen des Funktionsbausteinaufrufs beinhaltet.
Im R/3 werden die Anwendungsdaten in der internen Tabelle der Struktur EDI_DD40 (EDI_DD
vor 4.0) übergeben. Pro IDoc wird zusätzlich ein Kontrollsatz der Struktur EDI_DC40 (EDI_DC
vor 4.0) mit den Verwaltungsdaten des IDocs mitgegeben. Im Beispiel werden diese Daten in
Form von internen Tabellen übergeben.
Weitere Informationen dazu finden Sie in der Dokumentation RFC-Programmierung in ABAP
[Extern].
Beispiele für tRFC-Programme finden Sie im RFC Software Development Kit (RFC-SDK):
· trfctest.c (Client-Programm)
· trfcserv.c (Server-Programm)
Einzelheiten zu den erforderlichen Funktionen finden Sie in der Dokumentation The RFC API
[Extern] oder in der Dokumentation des RFC-SDK.
Diese Programme können Sie als Vorlage für Ihre eigenen Programme verwenden.
Zur Interpretation der Nutzdaten im IDoc brauchen Sie auch die Datenstrukturen der IDocs auf
C-Programmebene. Wenn Sie ein R/3-System zur Verfügung haben, können Sie sich direkt aus
der Transaktion WE60 (Dokumentation zu IDoc-Typen) eine Header-Datei des IDocs
generieren lassen.

April 2001 153


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
TCP/IP-Einstellungen

TCP/IP-Einstellungen
Als Voraussetzung für die Kommunikation müssen Sie folgende TCP/IP-Einstellungen
vornehmen:
· Damit das R/3-System den Zielrechner findet, müssen die TCP/IP Voraussetzungen
geschaffen sein, insbesondere die IP-Adressen in der jeweiligen Datei hosts bekannt sein.
· Der Name des Gateways und des Dispatchers in die Datei services eingetragen werden, z.B.
sapgw00 und sapdp00.
· Im R/3-System werden standardmäßig IDocs aus der Verbuchung heraus versendet. Daher
muß der TCP/IP-Link auch für die Verbuchungsmaschine erzeugt werden.
· Das SAP-Gateway muß das Recht haben, das externe Programm (RFC-Server) über
Remote Shell zu starten.
Ab Release 3.0C kann im Registriermodus gearbeitet werden. Dabei bleibt die Verbindung
zwischen Fremdsystemprogramm und Gateway offen (siehe Registering Server Programs
with the SAP Gateway [Extern] in The RFC API).
Einzelheiten zu den TCP/IP-Einstellungen finden Sie in der Dokumentation BC - SAP-
Kommunikation: Konfiguration [Extern].

154 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Senden von IDocs vom Fremdsystem an SAP

Senden von IDocs vom Fremdsystem an SAP


Das folgende Schaubild verdeutlicht die Programmablauflogik.

Externes
Externes Programm
Programm
(( Client
Client ))
……
/ /**
**Transaktionsverwaltung
TransaktionsverwaltungTIDTID) )
**/ / RFC
RFC -- Library
Library
rfc_rc
rfc_rc==RfcCreateTransID(...)
RfcCreateTransID(...)
… saprfc.h
saprfc.h
… sapitab.h
/ /** sapitab.h
**Aufruf librfc.a
librfc.a/ /librfc.dll
librfc.dll/ /ntlibrfc.lib
ntlibrfc.lib…
Aufrufdes
desFunktionsbausteins
FunktionsbausteinsIDOC_INBOUND_ASYNCHRONOUS
IDOC_INBOUND_ASYNCHRONOUS …
**/ /
rfc_rc
rfc_rc==RfcIndirectCall
RfcIndirectCall(handle,
(handle,
“IDOC_INBOUND_ASYNCHRONOUS”
“IDOC_INBOUND_ASYNCHRONOUS”
Exporting;
Exporting;Tables;TransID);
Tables;TransID);

SAP
SAP -- Funktionsbaustein
Funktionsbaustein
IDOC_
IDOC_ INBOUND_
INBOUND_ ASYNCHRONOUS
ASYNCHRONOUS::
(( Server
Server ))

Lokale
LokaleSchnittstelle:
Schnittstelle:
TABLES
TABLES
IDOC_CONTROL_REC_40
IDOC_CONTROL_REC_40 STRUCTURE
STRUCTUREEDI_DC40
EDI_DC40
IDOC_DATA _REC_40
IDOC_DATA _REC_40 STRUCTURE
STRUCTUREEDI_DD40
EDI_DD40
Remote
RemoteFunction
FunctionCall
Callunterstützt
unterstützt
Aufgabe:
Aufgabe:
IDOCs
IDOCsverbuchen
verbuchen
Verarbeitung
Verarbeitunganstoßen
anstoßen

Das aufrufende, externe Programm verwendet die folgenden Funktionen des RFC Software
Development Kit (RFC-SDK):
· RfcOpen
Mit diesem Aufruf wird eine RFC-Verbindung zum Server-System aufgebaut. Die
Anmeldung am SAP-System inklusive Servername des SAP-Zielrechners, SAP-Logon,
Benutzer, Kennwort, etc. können Sie im C-Programm oder in der Datei saprfc.ini
definieren.
Nach dem Verbindungsaufbau zum Server-System müssen im Client-Programm die beiden
folgenden Funktionen für den tRFC aufgerufen werden:
· RfcCreateTransID
Mit diesem Aufruf wird die Transaktionskennung (TID) ermittelt, die im Server-System
angelegt wurde.

April 2001 155


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Senden von IDocs vom Fremdsystem an SAP

· RfcIndirectCall
Mit diesem Aufruf werden die RFC-Daten zusammen mit der TID an das Server-System
übermittelt.
Im Fehlerfall wiederholt das Client-Programm diesen Aufruf.
Dabei muss es mit dem Aufruf RfcCreateTransID die alte TID verwenden. Andernfalls ist
nicht sichergestellt, dass die RFC-Funktion nur ein einziges Mal im R/3-System ausgeführt
wird.
Nach der erfolgreichen Ausführung dieses Aufrufs wird die Transaktion beendet. Das
aufrufende Programm kann dann seine eigene TID-Verwaltung aktualisieren (z.B. den TID-
Eintrag löschen).
Weitere Informationen finden Sie in der Dokumentation The RFC API [Extern] oder in der
Dokumentation des RFC-SDK..
Die Nutzdaten sind in IDoc-Form aufzubereiten und in eine interne Tabelle der Struktur
EDI_DD40 (EDI_DD vor 4.0) zu stellen. Pro IDoc muß auch der Kontrollsatz aufgebaut und in
eine interne Tabelle der Struktur EDI_DC40 (EDI_DC vor 4.0) gestellt werden. Auch die Form
der Datenübergabe ist in der Dokumentation beschrieben.

156 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Verwaltung von Transaktionsidentifikatoren (TID)

Verwaltung von Transaktionsidentifikatoren (TID)


Um die Sicherheit der zu übertragenden Daten zu gewährleisten, muß mit einer eindeutigen
Kennung für einen Kommunikationsvorgang gearbeitet werden. Anhand dieser Kennung kann
das empfangende System entscheiden, ob diese Daten bereits empfangen und bearbeitet
wurden.

Beispielsweise könnte bei der mobilen Erfassung von Wareneingängen während des
Versendens der Daten die Kommunikation zusammenbrechen. Der Bearbeiter würde
nochmals die Daten versenden, um ihre Verbuchung im SAP-System
sicherzustellen. Wenn aber die Daten bereits beim erstmaligen Senden im SAP-
System empfangen und verarbeitet wurden, muß das System dies erkennen können.
Es darf die Daten nicht nochmals verarbeiten.
Aus diesem Beispiel ergibt sich zwangsläufig folgender schematischer Ablauf zwischen Sende-
und Empfangssystem.

Sender
Sender Empfänger
Empfänger
( (Client
Client) ) ( (Server
Server) )

TID
TIDerzeugen
erzeugen//holen
holen
(weltweit
(weltweiteindeutige
eindeutigeNummer)
Nummer)

TID
TIDmit
mitzu
zuübertragenden
übertragenden
Datensätzen
Datensätzensichern
sichern

Call
Callauf
aufden
denServer:
Server: Sichern
Sichernvon
vonDaten
Daten
Übertragen
Übertragenvon
von und
undTID
TID
Daten
Datenund
undTID
TID

Bestätigung
Bestätigung Bestätigung:
Alles
Alleso.k.
o.k. Bestätigung:
nicht
nichto.k. Daten
o.k. Status
Status DatenEmpfangen
Empfangen
fortschreiben
fortschreiben
Nochmals
Nochmals TID
TIDund
undDaten
Daten Prüfung:
Prüfung:TID
TIDschon
schon
versenden
versenden sofort
sofortoder
oder vorhanden
vorhanden//bearbeitet?
bearbeitet?
mit
mitgleicher
gleicher später
späterlöschen
löschen
TID
TID

Ja
Ja Nein
Nein
nichts
nichtstun
tun Daten
Datenverarbeiten
verarbeiten

Status
StatusTID
TID
fortschreiben
fortschreiben

April 2001 157


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Verwaltung von Transaktionsidentifikatoren (TID)

158 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Datenaufbereitung

Datenaufbereitung
Verwendung
Die Strukturen EDI_DC und EDI_DD werden im folgenden für den Ausgang beschrieben. Da
diese Strukturen auch für EDI genutzt werden, haben sie einige für uns redundante Felder.
Die eigentlichen Nutzdaten verbergen sich allgemein im Feld EDI_DD-SDATA. Senden Sie
beispielsweise zwei IDocs Transportaufträge mit je drei Positionen, so müssen Sie pro IDoc
einen EDI_DC-Satz, also zwei EDI_DC-Sätze und acht EDI_DD-Sätze versenden, je ein Kopf-
Segment und drei Positions-Segmente. Die vier Segmente eines IDocs werden dabei über die
eindeutige Nummer des IDocs oder Zwischenbelegs geklammert. Über die DOCNUM wird auch
der zugehörige EDI_DC-Satz identifiziert.
(Rel = Relevant für das Empfangen von IDocs in SAP. Nicht Relevant heißt: muß beim
Empfangen des IDocs nicht gefüllt werden. Bei Senden an das Fremdsystem werden alle Daten
bis auf TABNAM übergeben.)

EDI_DD

Feld Format Bezeichnung Rel Bemerkung


TABNAM CHAR 10 Name der Nicht relevant
Tabellenstruktur
MANDT CLNT 3 Mandant Nicht relevant, wird aber an
Fremdsystem übergeben
DOCNUM CHAR 16 Nummer des IDocs X Eindeutige
Kommunikationsnummer
SEGNUM CHAR 6 Nummer des SAP- Fortlaufende Numerierung von
Segments IDoc-Segementen, wird an
Fremdsystem übergeben, aber
beim Empfangen nicht gefordert
SEGNAM CHAR 10 Name des SAP- X IDoc-Segmentname
Segments
PSGNUM CHAR 6 Nummer des Wird an Fremdsystem
übergeordneten SAP- übergeben, aber nicht zwingend
Segments bei Eingang
HLEVEL CHAR 2 Hierarchieebene des Wird an Fremdsystem
SAP-Segements übergeben, aber nicht zwingend
bei Eingang
DTINT2 CHAR 2 Leerfeld für EDI_DD Nicht relevant
SDATA LCHR 1000 Anwendungsdaten X Eigentliche Nutzdaten in Form
der IDoc-Segmente

EDI_DC

Feld Format Bezeichnung Rel Bemerkung


TABNAM CHAR 10 Name der
Tabellenstruktur

April 2001 159


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Datenaufbereitung

MANDT CLNT 3 Mandant


DOCNUM CHAR 16 Nummer des IDocs X Eindeutige
Kommunikationsnummer
DOCREL CHAR 4 SAP-Release des IDocs Wird an Fremdsystem übergeben,
ist beim Eingang nicht gefordert
STATUS CHAR 2 Status des IDocs
DOCTYP CHAR 8 Zwischenstruktur Empfohlen wie IDOCTYP
DIRECT CHAR 1 Richtung
RCVPOR CHAR 10 Empfängerport Nicht relevant
RCVPRT CHAR 2 Partnerart des X Wert: „LS“
Empfängers
RCVPRN CHAR 10 Partnernummer des X z.B.: „WM_SUB_001“ für SAP an
Empfängers SUB
RCVSAD CHAR 21 EDI: SADR-Felder
insgesamt
RCVLAD CHAR 70 Logische Adresse des
Empfängers
STD CHAR 1 EDI-Standard
STDVRS CHAR 6 Version des EDI-
Standards
STDMES CHAR 6 EDI-Nachrichtentyp
MESCOD CHAR 3 Logische * siehe Text unten
Nachrichtenvariante
MESFCT CHAR 3 Logische * siehe Text unten
Nachrichtenfunktion
OUTMOD CHAR 1 Ausgabemodus
TEST CHAR 1 Test-Kennzeichen
SNDPOR CHAR 10 Absenderport Nicht relevant
SNDPRT CHAR 2 Partnerart des Absenders X Wert: „LS“
SNDPRN CHAR 10 Partnernummer des X z.B.: „S11MAND000“ falls S11 das
Absenders sendende SAP-System ist

SNDSAD CHAR 21 EDI: SADR-Felder


insgesamt
SNDLAD CHAR 70 Logische Adresse des
Absenders
REFINT CHAR 14 Referenz auf
Übertragungsdatei
REFGRP CHAR 14 Referenz auf
Nachrichtengruppe

160 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Datenaufbereitung

REFMES CHAR 14 Referenz auf Nachricht


ARCKEY CHAR 70 Schlüssel des EDI-
Archivs
CREDAT DATS D 8 Erstellungsdatum des
IDocs
CRETIM TIMS T 6 Erstellungsuhrzeit des
IDocs
MESTYP CHAR 6 Logischer Nachrichtentyp X z.B WMTORD für
Transportaufträge
IDOCTYP CHAR 8 Name der Basis- X z.B. WMTOID01 für TAs
Zwischenstruktur
CIMTYP CHAR 8 Name der
Zwischenstruktur
RCVPFC CHAR 2 Partnerrolle des
Empfängers
SNDPFC CHAR 2 Partnerrolle des Senders
SERIAL CHAR 20 EDI/ALE:
Serialisierungsfeld
EXPRSS CHAR 1 Übersteuerung im
Eingang
* Beide Felder können genutzt werden, um in der ALE-Serviceschicht in der Tabelle der
Eingangsmethoden einen anderen als den Standard-Funktionsbaustein zur Verarbeitung des
IDocs vorzusehen.
Nicht alle Felder der EDI_DC- bzw.EDI_DD-Felder sind zu füllen. Achten Sie bitte darauf, daß
Sie nicht zu füllende Felder zuvor initialisieren.
Senden Sie ein IDoc vom Fremdsystem an SAP, dann müssen Sie im System ein logisches
System definieren (/nSALE ->Verteilungsmodell->Logische Systeme) und eine
Partnervereinbarung Eingang mit dieser Partnernummer treffen. Die Partnernummer des
Zielsystems (hier SAP) ist eigentlich nicht zwingend. Wir empfehlen aber sie anzugeben, damit
Kommunikationsvorgänge nachvollzogen werden können. Das logische System des SAP-
Systems wird pro Mandant in der Tabelle T000 (/nSM31) gepflegt.
Bei der Anlage der IDocs im R/3-System mit der Transaktion /nWE30 werden zu jedem IDoc-
Segment automatisch drei Strukturen angelegt, die auch durchnumeriert werden, also z.B. für die
Transportauftragsposition E1LTORI, E2LTORI und E3LTORI. E1LTORI ist releaseunabhängig,
E2LTORI releaseabhängig, und E3LTORI wird für die Dokumentation verwendet.
Bei der Übergabe von Segmentnamen müssen Sie die E2-Segmentnamen angeben, um
unabhängig vom SAP-Release zu werden.
Im obigen Transportauftragsbeispiel (zwei TAs mit je drei Positionen) würden also zwei interne
Tabellen mit folgendem Aufbau übergeben:

EDI_DD
9000000000123456 E2LTORH 00112345678905011E ... (TA Kopfdaten)
9000000000123456 E2LTORI 0001FRASCATI ... (Position)

April 2001 161


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Datenaufbereitung

9000000000123456 E2LTORI 0002BORDEAUX ... (Position)


9000000000123456 E2LTORI 0003CHIANTI ... (Position)
9000000000123457 E2LTORH 00112345678912011A ... (TA Kopfdaten)
9000000000123457 E2LTORI 0001CHATEAU-NEUF ... (Position)
9000000000123457 E2LTOR 0002BORDEAUX ... (Position)
9000000000123457 E2LTORI 0003SOAVE ... (Position)

EDI_DC
9000000000123456 LS S11MAND002 LS SUBSYSTEM1 WMTORD WMTOID01
9000000000123457 LS S11MAND002 LS SUBSYSTEM1 WMTORD WMTOID01

162 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Übergabe-Formate der Daten

Übergabe-Formate der Daten


Daten werden über die Schnittstelle nur in CHAR-Format weitergegeben. Daraus ergeben sich
Konvertierungen in SAP mit damit verbundenen Normierungen für die Eingabefelder in CHAR-
Formaten. Die nachstehende Tabelle gibt für die interessantesten Fälle diese erwarteten
Eingaben wieder.
Feld Format Bezeichnung
MATNR 18 ‘000000000012345678’ numerisch mit führenden Nullen
18 ‘Bordeaux__________‘ wenn string
LENUM 20 ‘00000000001234567891’ falls mit 10stelligen LE-Nummern
in SAP gearbeitet wird
DATUM 8 JJJJMMDD z.B.: 19951231
UZEIT 6 HHMMSS
Mengenfelder 15 13 Ziffern, 1 Punkt und 1 Vorzeichen linksbündig, z.B.
allgemein ‘302.35_________’ oder ‘302.35-________’

April 2001 163


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Beschreibung der IDocs

Beschreibung der IDocs


Beschrieben sind die Standard-IDocs, die SAP mit den Release-Ständen 3.0A und 4.0A
ausliefert. Folgende Tabelle gibt eine Übersicht über Benennungen der IDocs:
IDoc E/A Nachrichtenty Appl. Segmente Bezeichnung Komp
p
WMMBID01 E WMMBXY IM E2MBXYH Warenbewegung MOB
E2MBXYI en
SDPIOD01 A PICKSD SD E2VPPIH Kommissionierm MOB
E2VPPII eldung an
Fremdsystem
SDPIID01 E SDPICK SD E2VPDLH Kommissionierrü MOB
E2VPDLI ckmeldung
SDPAID01 E SDPACK SD E2VPACD Versandelementr MOB
E2VPACH ückmeldung
E2VPPACI
WMTOID01 B WMTORD WM E2LTORH Transportaufträg LSR
E2LTORI e
WMTCID01 E WMTOCO WM E2LTCOX Transportaufträg LSR
E2LTCOH e quittieren
E2LTCOI
WMCAID01 B WMCATO WM E2LTCAH Stornoanforderu LSR
E2LTCAI ng TA / TA
stornieren
WMTRID01 E WMTREQ WM E2LTRQH Transportbedarf LSR
E2LTRQI e erzeugen
WMBIID01 E WMBBIN WM E2LBINH Lagerplätze LSR
E2LBINI sperren
WMRRID01 A WMRREF WM E2LRRFX Freigabe von LSR
Gruppen
WMSUID01 E WMSUMO WM E2LSUMX Lagereinheit LSR
bewegen
WMIVID01 E WMINVE WM E2LINVX Inventurbelege LSR
und
Zähldatenerfass
ung
WMINID01 E WMINFO WM E2LINFX Informationstext LSR
WMTCID02 E WMTOCO WM E2LTCOX, Transportaufträg LSR
2LTCOG, e quittieren
E2LTCOH,
E2LTCOI
WMMBID02 E WMMBXY IM E2MBXYH, Warenbewegung MOB
E2MBXYI en
E2MBXYJ
E = Eingang in SAP
A = Ausgang an Fremdsystem
B = bidirektional verwendbar

164 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Beschreibung der IDocs

SD = Versand
IM = Bestandsführung
WM= Lagerverwaltung
Die Spalte “Komp.” (Komponente) gibt die Zuordnung zur entsprechenden
Schnittstellenkomponente an.
Viele Segmente der Schnittstellen-IDocs haben zu Release 4.0 Segmenterweiterungen
bekommen. Diese sind insoweit aufwärtskompatibel, als in der Partnervereinbarung explizit der
Releasestand der verwendeten IDocs definiert wird. Soll weiterhin mit den 3.0-
Segmentdefinitionen für den Austausch mit dem Fremdsystem gearbeitet werden, muß der
Releasestand 3.0a in die Partnervereinbarung mit aufgenommen werden.
Die IDocs WMTCID02 und WMMBID02 sind den gleichen Nachrichtentypen zugeordnet. Wenn
Sie mit diesen IDocs arbeiten wollen, müssen Sie lediglich in der Partnervereinbarung den alten
IDoc-Namen durch den neuen ersetzen. Beim IDoc Quittieren wurde zusätzlich das Segment
E2LTCOH geändert, d.h. Sie müßten außerdem noch den Releasestand in der
Partnervereinbarung ergänzen: 3.0a für die "alte" Version, 4.0a für das neue Segment.

April 2001 165


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Warenbewegungen

Warenbewegungen
Verwendung
In diesem Abschnitt wird das IDoc WMMBID01 (WMMBID02 ab Release 4.0) beschrieben
sowie eine Matrix der Mußfelder für verschiedene Bewegungsarten, mit denen in der SAP-
Bestandsführung gebucht werden soll. Das IDoc WMMBID01 besteht aus zwei Segmenten:
E2MBXYH für die Kopfdaten und E2MBXYI für die Positionsdaten. Zusätzlich gibt es
E2MBXYJ für neue Felder in Release 4.0
Die Partnervereinbarung Eingang muß für den Nachrichtentyp WMMBXY gepflegt werden.
Im Prinzip lassen sich mit diesem IDoc alle Warenbewegungen buchen, die Sie mit den
üblichen Standardtransaktionen (MB01, MB1A, MB1B, MB1C, MB31) auch online direkt
ausführen können. Für die Entscheidung, welche Felder des IDocs Mußfelder sind, können
Sie die entsprechende Buchung direkt im System durchführen und sich die Mußfelder
merken. Als Beispiel sei untenstehende Matrix für die wichtigsten Bewegungen genannt (M =
Mußfeld).

Mußfeld-Tabelle - Warenbewegungen (M = Mußfeld)

Felder BWA BWA BWA BWA BWA BWA BWA


101 101 102 201 321 501 301
E2MBXYH-BLDAT M M M M M M M
E2MBXYH-BUDAT M M M M M M M
E2MBXYH-TCODE MB31 MB01 MB01 MB1A MB1B MB1C MB1B
E2MBXYI-WERKS M M M M M M M
E2MBXYI-LGORT M M M M M M M
E2MBXYI-MATNR M M M M M
E2MBXYI-BWART M M M M M M M
E2MBXYI-INSMK M M
E2MBXYI-EBELN M M
E2MBXYI-EBELP
E2MBXYI-ERFMG M M M M M M M
E2MBXYI-ERFME M M M M M M M
E2MBXYI-VFDAT
E2MBXYI-KZBEW M ‘F’ M ‘B’ M ‘B’
E2MBXYI-KOSTL M
E2MBXYI-UMWRK M
E2MBXYI-UMLGO M
E2MBXYI-AUFNR M

166 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Warenbewegungen

E2MBXYI- AUFPS M

Legende Bewegungsarten

Bewegungsart Transaktionscode Bezeichnung


101 MB01 Wareneingang zur Bestellung
101 MB31 Wareneingang zum Fertigungsauftrag
102 MB01 Wareneingang zur Bestellung - Storno
201 MB11 Warenausgang zur Kostenstelle
321 MB11 Freigabe aus Qualitätsprüfung
501 MB11 Wareneingang ohne Bestellung
301 MB11 Umlagerung Werk an Werk
... Siehe auch Customizing der Bestandsführung

Anmerkungen
1. Zum Buchen von Wareneingängen zur Bestellung in die Qualitätskontrolle müssen Sie
das Feld E2MBXYI-INSMK = ‘X’ mitgeben. Verwenden Sie Bewegungsart 101.
2. Beim Wareneingang zur Bestellung ist das Kennzeichen KZBEW mit dem Wert ‘B’ zu
füllen, bei Wareneingängen zum Fertigungsauftrag mit dem Wert ‘F’.
3. Ist das Material mindesthaltbarkeitsdatumpflichtig, muß das Feld E2MBXYI-VFDAT
mitgegeben werden.
4. Die Stornobuchungen benötigen in der Regel die gleichen Mußfelder und unterscheiden
sich daher nur durch die Bewegungsart von der Originalbuchung.
5. Zum Test steht der Report RLMBXY00 zur Verfügung. Bitte sehen Sie sich die
entsprechende Reportdokumentation an.
6. In der Verarbeitung der Sätze führen einige Fehlermeldungen zu Abbrüchen. Diese
Fehlermeldungen können aber in Tabelle T160M zu nicht störenden Warnmeldungen
umgeändert werden. Dies betrifft zum Beispiel eine Meldung wie: ‘Vorsicht
Unterlieferung’ oder ähnliches. 'Wirkliche' Fehler werden von der logischen
Fehlerbearbeitung (siehe SAP-Systemeinstellungen und Modifikationskonzept [Seite
215]) abgefangen.
7. Bei der technischen Realisierung ist zu berücksichtigen, daß Sie nicht mehrere IDocs
gleichzeitig versenden können. Bei vielen Daten können Sie aber dem IDoc-Kopf
beliebig viele Positionen mitgeben, d.h. ein großes IDoc versenden.
In der folgenden Tabelle sind die Segmente des IDocs WMMBID01 beschrieben.

E2MBXYH

Felder Format Bezeichnung Muß Beispielwert


BLDAT DatC 8 Belegdatum im Beleg X 19951231
BUDAT DatC 8 Buchungsdatum im Beleg X 19951231

April 2001 167


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Warenbewegungen

XBLNR CHAR 16 Referenzbelegnummer


BKTXT CHAR 25 Belegkopftext
FRBNR CHAR 16 Nummer des Frachtbriefs des Wareneingangs
XABLN CHAR 10 Warenbegleitscheinnummer
TCODE CHAR 4 Mappe: Transaktionscode X MB11
USNAM CHAR 12 Benutzername (Release 4.0)
VBUND CHAR 6 Gesellschaftsnummer (Release 4.0)

E2MBXYI

Felder Format Bezeichnung Muß Beispielwert


BEAKZ CHAR 1 Kennzeichen: Zeile bereit
XSTOB CHAR 1 Kz. Stornobuchung
MATNR CHAR 18 Materialnummer X 0000000010234
5
WERKS CHAR 4 Werk X 0001
LGORT CHAR 4 Lagerort X 0087
CHARG CHAR 10 Chargennummer
BWART CHAR 3 Bewegungsart (Bestandsführung) X 501
INSMK CHAR 1 Bestandsart
SOBKZ CHAR 1 Sonderbestandskennzeichen
KZVBR CHAR 1 Kennzeichen: Verbrauchsbuchung
LIFNR CHAR 10 Kontonummer des Lieferanten
KUNNR CHAR 10 Debitorennummer
KDAUF CHAR 10 Kundenauftragsnummer
KDPOS CHAR 6 Positionsnummer im Kundenauftrag
KDEIN CHAR 4 Einteilung Kundenauftrag
SHKZG CHAR 1 Soll-/Haben-Kennzeichen
WAERS CHAR 5 Währungsschlüssel
DMBTR CHAR 15 Betrag in Hauswährung
BWTAR CHAR 10 Bewertungsart
ERFMG CHAR 15 Menge in Erfassungsmengeneinheit
ERFME CHAR 3 Erfassungsmengeneinheit
BPMNG CHAR 15 Menge in Bestellpreismenge
BPRME CHAR 3 Bestellpreismengeneinheit

168 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Warenbewegungen

EBELN CHAR 10 Belegnummer des Einkaufsbelegs


EBELP CHAR 5 Positionsnummer des Einkaufsbelegs
ELIKZ CHAR 1 Endlieferungskennzeichen
SGTXT CHAR 50 Positionstext
WEMPF CHAR 12 Warenempfänger
ABLAD CHAR 25 Abladestelle
KOSTL CHAR 10 Kostenstelle
AUFNR CHAR 12 Auftragsnummer
ANLN1 CHAR 12 Anlagenhauptnummer
ANLN2 CHAR 4 Anlagenunternummer
RSNUM CHAR 10 Nummer der Reservierung
RSPOS CHAR 4 Positionsnummer der Reservierung
KZEAR CHAR 1 Kennzeichen: Endausfassung
UMMAT CHAR 18 Empfangendes/Abgebendes Material
UMWRK CHAR 4 Empfangendes/Abgebendes Werk
UMLGO CHAR 4 Empfangender/Abgebender Lagerort
UMCHA CHAR 10 Empfangende/Abgebende Charge
KZBEW CHAR 1 Bewegungskennzeichen
WEUNB CHAR 1 Kennzeichen: Wareneingang
LGNUM CHAR 3 Lagernummer
LGTYP CHAR 3 Lagertyp
LGPLA CHAR 10 Lagerplatz
GRUND CHAR 4 Kennzeichen: Grund der Bewegung
EVERS CHAR 2 Versandvorschrift
EVERE CHAR 2 Einhaltung der Versandvorschrift
IMKEY CHAR 8 Interner Schlüssel für Immobilienobjekt
KSTRG CHAR 12 Kostenträger
PAOBJN CHAR 10 Nummer für Ergebnisobjekt
R
PRCTR CHAR 10 Profit Center
PS_PSP_ CHAR 8 Projektstrukturplanelement
PNR
NPLNR CHAR 12 Netzplannummer für Kontierung
AUFPL CHAR 10 Plannummer zu Vorgängen

April 2001 169


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Warenbewegungen

APLZL CHAR 8 Fortlaufender Zähler


AUFPS CHAR 4 Nummer der Auftragsposition
VPTNR CHAR 10 Kundennummer des Partners
FIPOS CHAR 14 Finanzposition
GSBER CHAR 4 Geschäftsbereich
BSTMG CHAR 15 Wareneingangsmenge in
Bestellmengeneinheit
BSTME CHAR 3 Bestellmengeneinheit
EXBWR CHAR 15 Extern eingegebener Buchungsbetrag in
Hauswährung
KONTO CHAR 10 Nummer des Sachkontos
RSHKZ CHAR 1 Soll-/Haben-Kennzeichen
BDMNG CHAR 15 Bedarfsmenge
ENMNG CHAR 15 Entnommene Menge
QPLOS CHAR 12 Prüflosnummer
UMZST CHAR 1 Zustand der Umlagercharge
UMZUS CHAR 1 Zustandsschlüssel der Umlagerung
UMBAR CHAR 10 Bewertungsart der Umlagerung
UMSOK CHAR 1 Sonderbestandskennzeichen
LFBJA CHAR 4 Geschäftsjahr eines Referenzbelegs
LFBNR CHAR 10 Belegnummer eines Referenzbelegs
LFPOS CHAR 4 Position eines Referenzbelegs
SJAHR CHAR 4 Materialbelegjahr
SMBLN CHAR 10 Nummer eines Materialbelegs
SMBLP CHAR 4 Position im Materialbeleg
EXVKW CHAR 15 Extern eingegebener Verkauf
QM_ZUS CHAR 1 Chargenzustand bei Zustandsänderung im
TD QM (intern)
POSNR CHAR 6 Lieferposition für Fremdsystem
VBELN CHAR 10 Lieferung
QM_UMZ CHAR 1 Umlagerchargenzustand bei
ST Chargenzustandsänderung im QM
BWLVS CHAR 3 Bewegungsart im LVS
UMREZ CHAR 5 Zähler Umrechnungsfaktor
UMREN CHAR 5 Nenner für die Umrechnung

170 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Warenbewegungen

VFDAT CHAR 8 Verfallsdatum oder


Mindesthaltbarkeitsdatum

E2MBXYJ

Felder Format Bezeichnung


PARGB CHAR 4 Geschäftsbereich des Geschäftspartners
PARBU CHAR 4 Verrechnender Buchungskreis
CLASS CHAR 18 Klassennummer
UMCLA CHAR 18 Klassennummer
XCLAS CHAR 1 Feld zum Markieren
UMXCL CHAR 1 Feld zum Markieren
XNIBU CHAR 1 Feld zum Markieren
BDTER CHAR 8 Bedarfstermin der Komponente
TBBEL CHAR 10 Materialbelegnummer des zu stornierenden Transportbedarfs
TBBPO CHAR 4 Materialbelegnummer der zu stornierenden
Transportbedarfsposition
TBBJR CHAR 4 Materialbelegjahr des zu stornierenden Transportbedarfs
OBJNR CHAR 22 Objektnummer
AUTYP CHAR 2 Auftragstyp
QPLOA CHAR 12 Prüflos, aus dem Verwendungsentscheid getroffen wurde
TBPKZ CHAR 1 Kennzeichen: keinen Transportbedarf erzeugen
TAFKZ CHAR 1 Kennzeichen: automatische TA-Erstellung nicht ansteuern
KZEAR_OLD CHAR 1 Kennzeichen: Endausfassung
RSART CHAR 1 Satzart
PPRCTR CHAR 10 Partner-Profit Center
XMEVO CHAR 1 Kennzeichen: Menge vorschlagen
UMLGT CHAR 3 Lagertyp
UMLGP CHAR 10 Lagerplatz
MENGE CHAR 15 Menge
MEINS CHAR 3 Basismengeneinheit
FKBER CHAR 4 Funktionsbereich
MHDAT CHAR 8 Verfallsdatum/Mindesthaltbarkeitsdatum oder Herstelldatum
BSSKZ CHAR 1 Bewegungssonderkennzeichen Lagerverwaltung
EXIDV CHAR 20 Externe Versandelementidentifikation
BERKZ CHAR 1 Bereitstellungskennzeichen für Produktionsversorgung

April 2001 171


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Warenbewegungen

PRVBE CHAR 10 Produktionsversorgungsbereich


KZECH CHAR 1 Steuerung der Chargenerfassung im Fertigungs-/Prozeßauftrag
UPTYP CHAR 1 Unterpositionstyp Einkaufsbeleg
REFIX CHAR 11 Feld analog zu SY-TABIX definiert
VLIEF_AVIS CHAR 10 Lieferung
VBELP_AVIS CHAR 6 Lieferposition
XWAIT CHAR 1 Feld zum Markieren
XNOEQ CHAR 1 Feld zum Markieren
ILINR CHAR 6 Hinzufügen Warenbewegung von Fremdsystem: Position ++
VOLUM CHAR 17 Volumen
VOLEH CHAR 3 Volumeneinheit
ANZL1 CHAR 4 Anzahl einzulagernder Lagereinheiten
ANZL2 CHAR 4 Anzahl einzulagernder Lagereinheiten
LMEN1 CHAR 15 Menge pro einzulagernder Lagereinheit in AME
LMEN2 CHAR 15 Menge pro einzulagernder Lagereinheit in AME
LETY1 CHAR 3 Lagereinheitentyp
LETY2 CHAR 3 Lagereinheitentyp
KZKUB CHAR 1 Kennzeichen: keine Umbuchungsanweisung anlegen
UBTYP CHAR 3 Lagertyp
UBLGP CHAR 10 Lagerplatz
MBLNR CHAR 10 Nummer des Materialbelegs
MBLPO CHAR 4 Position im Materialbeleg
MJAHR CHAR 4 Materialbelegjahr
URZEI CHAR 4 Ursprungszeile im Materialbeleg
GEBER CHAR 10 Fonds
FISTL CHAR 16 Finanzstelle
KZBWS CHAR 1 Kennzeichen: Bewertung Sonderbestand
KDAUF_SD CHAR 10 Kundenauftragsnummer
KDPOS_SD CHAR 6 Positionsnummer im Kundenauftrag

L_PO_READ_MDE
Im Szenario ‘Wareneingang zur Bestellung’ können Sie, bevor die Wareneingangsdaten mit
dem mobilen Terminal erfaßt werden, die Bestelldaten zur Bestellnummer mittels eines
sRFC auf den Funktionsbaustein ‘L_PO_READ_MDE’ auf das Fremdsystem herunterladen.

172 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Warenbewegungen

Der ‘L_PO_READ_MDE’ ist ein Beispielfunktionsbaustein im SAP-System für diese Art der
Kopplung. Sollte auch in anderen Bereichen Notwendigkeit zur Informationsbeschaffung
bestehen, kann auch in diesen Bereichen ein synchroner RFC auf bestehende oder zu
erstellende Funktionsbausteine genutzt werden. Der synchrone RFC sollte grundsätzlich nur
zur Informationsbeschaffung herangezogen werden. Sollen Daten im Partnersystem
verbucht werden, sollte das mit einem IDoc und einem transaktionalem RFC geschehen.
Die Parameter des Funktionsbausteins ‘L_PO_READ_MDE’ können mit dem Editor /nSE37
im SAP-System angezeigt werden. Ebenfalls aus der /nSE37 kann direkt aus dem SAP-
System C- oder Visual Basic-Code erzeugt werden. Nach dem Kompilieren ist dieser Code
fähig, den SAP-Funktionsbaustein aufzurufen, d.h. es wird automatisch der Client erzeugt,
der dann von Ihnen in Ihr Programm eingebunden werden kann.

April 2001 173


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Rückmeldung von Versandelementdaten

Rückmeldung von Versandelementdaten


Das IDoc SDPAID01 dient zum Rückmelden von Verpackungen an die Lieferung.
Es besteht aus den drei Segmenten E2VPACD (Lieferungsbezug), E2VPACD (Kopfdaten
Versandelement) und E2VPACI (Positionsdaten).
Sie müssen die Partnervereinbarung Eingang zum Nachrichtentyp SDPACK pflegen. Im
folgenden werden die Segmente und deren Einsatzmöglichkeiten beschrieben.

E2VPACD

Felder Format Bezeichnung Muß Bemerkung


VBELN CHAR 10 Lieferung X Stellt den Bezug zur Lieferung her.

E2VPACH

Felder Format Bezeichnung Muß Bemerkung


EXIDV CHAR 20 Externe X
Versandelementidentifikation
EXIDA CHAR 1 Art der externen
Versandelementidentifikation
VSTEL CHAR 4 Versandstelle
LSTEL CHAR 2 Ladestelle
BRGEW CHAR 15 Gesamtgewicht Einheit GEWEI_MAX
NTGEW CHAR 15 Ladungsgewicht Einheit GEWEI_MAX
MAGEW CHAR 15 Maximales Gewicht Einheit GEWEI_MAX
TARAG CHAR 15 Eigengewicht Einheit GEWEI
GEWEI CHAR 3 Gewichtseinheit
BTVOL CHAR 15 Gesamtvolumen Einheit VOLEH_MAX
NTVOL CHAR 15 Ladungsvolumen Einheit VOLEH_MAX
MAVOL CHAR 15 Maximales Volumen Einheit VOLEH_MAX
TAVOL CHAR 15 Eigenvolumen Einheit VOLEH
VOLEH CHAR 3 Volumeneinheit
ANZGL CHAR 5 R/2-Tabelle ohne Funktion
ERNAM CHAR 12 Name des Sachbearbeiters
ERDAT DATS D 8 Datum an dem Satz hinzugefügt
wird
ERUHR TIMS T 6 Erfassungszeit
AENAM CHAR 12 Name d. ändernden ohne Funktion
Sachbearbeiters
AEDAT DATS D 8 Änderungsdatum ohne Funktion
AEZET TIMS T 6 Zeitpunkt der letzten Änderung ohne Funktion
SORTL CHAR 10 Sortierfeld
VEGR1 CHAR 5 Versandelementgruppe 1 Kundeneigene Reserve
VEGR2 CHAR 5 Versandelementgruppe 2 Kundeneigene Reserve
VEGR3 CHAR 5 Versandelementgruppe 3 Kundeneigene Reserve
VEGR4 CHAR 5 Versandelementgruppe 4 Kundeneigene Reserve
VEGR5 CHAR 5 Versandelementgruppe 5 Kundeneigene Reserve
VHILM CHAR 18 Versandhilfsmittel X Materialnummer des
Versandhilfsmittel

174 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Rückmeldung von Versandelementdaten

LAENG CHAR 13 Characterfeld 13 Stellen ohne Funktion


BREIT CHAR 13 Characterfeld 13 Stellen ohne Funktion
HOEHE CHAR 13 Characterfeld 13 Stellen ohne Funktion
MEABM CHAR 3 Feld der Laenge 3 Bytes ohne Funktion
ERLKZ CHAR 1 Status (zur Zeit ohne Funktion) ohne Funktion
GEWTO CHAR 3 Gewichtstoleranz ohne Funktion
VOLTO CHAR 3 Volumentoleranz ohne Funktion
MEINS CHAR 3 Mengeneinheit ohne Funktion
VOLEH_MAX CHAR 3 Volumeneinheit
GEWEI_MAX CHAR 3 Gewichtseinheit
INHALT CHAR 40 Beschreibung des Textfeld, frei verfügbar
Versandelements
WERKS CHAR 4 Werk siehe Hinweis
PSTYV CHAR 4 Positionstyp Vertriebsbeleg siehe Hinweis
LADLG CHAR 6 Ladungsgewicht in Lade-Längeneinheit
LADEH CHAR 3 Lade-Längeneinheit
FARZT CHAR 6 Fahrzeit
FAREH CHAR 3 Fahrzeiteinheit
ENTFE CHAR 6 Gefahrene Entfernung
EHENT CHAR 3 Entfernungseinheit
LGORT CHAR 4 Lagerort siehe Hinweis
GEWFX CHAR 1 Gewichte und Volumina fix

E2VPACI

Felder Format Bezeichnung Versionen


EXIDV_OB CHAR 20 Übergeordnetes Versandelement 1 2 3
EXIDV CHAR 20 Untergeordnetes Versandelement 1
VBELN CHAR 10 Lieferung 2 3
POSNR NUMC N 6 Lieferposition 2
TMENG CHAR 15 Verpackte Menge 2 3
VRKME CHAR 3 Feld der Laenge 3 Bytes
MATNR CHAR 18 Materialnummer 3
CHARG CHAR 10 Chargennummer 3
Die folgende Matrix spiegelt die Möglichkeiten des IDocs wider.
· E2VPACD = D
E2VPACH = H
E2VPACI = I
Mindestens ein E1VPACD und ein E1VPACH müssen gesendet werden.

Optionen des SDPAID01

Segmente Version Bedeutung


D+H Rückmelden eines Packstücks ohne Bezug zur Lieferposition
D+H+ I 1 Rückmelden eines Packstücks im Packstück (EXIDV im EXIDV_OB)
D+H+I 2 Rückmelden von verpackten Lieferungspositionen. Bei Angabe der
Position erübrigt sich die Angabe der Materialnummer und Charge.

April 2001 175


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Rückmeldung von Versandelementdaten

D+H+I 3 Rückmelden von verpackten Materialien mit Mengen und Charge.


Version 3 ist notwendig, da im Falle des Chargensplitts zusätzliche
Lieferpositionen erzeugt werden, die dem Fremdsystem noch nicht
bekannt sein können.
Ein Versandelement besteht aus einem Verpackungsmaterial, dem Versandhilfsmittel (VHM).
Ein Versandhilfsmittel ist ein Material mit Materialart VERP. Jedes Material (beliebige
Materialart), daß verpackt werden soll, muß einer VHM-Materialgruppe, kurz VHM-Gruppe,
zugeordnet werden. Diese Partitionierung der Materialien erfolgt im Materialstamm. Damit wird
überprüft, ob eine bestimmte Verpackung für ein Material überhaupt zulässig ist. Dazu werden
auf der anderen Seite die Versandhilfsmittel einer Versandhilfsmittelart (VHM-Art) zugeordnet.
Die Pflege dieser Eigenschaft erfolgt ebenfalls im Materialstamm. Die Zulässigkeit wird nun
durch Zuordnung VHM-Gruppe zu VHM-Art realisiert. Definition von VHM-Gruppen und VHM-
Arten sowie deren Verknüpfung erfolgt im Customizing (Versand/Verpacken).

Packaging [Seite 185]

Gänzlich unberührt von der Packstückrückmeldung kann im Customizing eingestellt


werden, ob ein Packstück eine Lieferposition erzeugen soll und damit fakturierbar
bzw. bestandsführbar oder nur als Information in der Lieferung vermerkt wird. Dabei
wird typischerweise das zugehörige Werk sowie der Lagerort automatisch ermittelt.
Diese Daten können aber explizit in den Feldern WERKS und LGORT mitgegeben
werden. Soll das Werk (und damit auch der Lagerort) automatisch bestimmt werden,
muß in der VHM-Art (s.o.) eine Findungsregel hinterlegt werden. Ebenso kann der
Positionstyp automatisch bestimmt oder im Feld PSTYV mitgegeben werden. Für
die Vergabe des Positionstyp muß im Customizing
(Versand/Lieferung/Positionstypenfindung) für die Verwendung PACK ein
Positionstyp hinterlegt werden.

176 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Rückmeldung von Versandelementdaten

Beispiel: Struktur für Rückmeldungen


Die Lieferung 80001234 enthält zwei Positionen 10 und 20 mit jeweils 50 Stück der Materialien
MAT1 und MAT2. An das Fremdsystem wurde der Kommissionierauftrag 765 mit der vollen
Liefermenge gesendet. Im Lager werden 50 ST des Materials MAT1 und 40 ST des Materials
MAT2 kommissioniert. Die Differenz von 10 ST ist definitiv nicht vorhanden. Deshalb soll die
Liefermenge angepaßt werden. Die Struktur für die Rückmeldung muß dann wie folgt gefüllt
werden.

E2VPDLH
· VBELN_VL 80001234
VBELN 765
KOMUE X
E2VPDLI
· VBELN_VL 80001234
· POSNR_VL 10
· VBELN 765
POSNN 10
PIKMG 50
MATNR MAT1
E2VPDLI
VBELN_VL 80001234
POSNR_VL 20
VBELN 765
POSNN 20
PIKMG 40
MATNR MAT2

Soll zusätzlich Warenausgang gebucht werden, so muß das entsprechende Kennzeichen


WABUC gesetzt werden. Für den Fall, daß keine Anpassung der Liefermengen erfolgt, wird über
die Differenzen eine neue Kommissioniernachricht erzeugt. Erfolgt zwischenzeitlich eine
Rückmeldung mit Kennzeichen KOMUE, so wird eine offene Nachricht wieder verworfen. Eine
Anpassung der Liefermengen ist nur möglich, falls alle Positionen bezüglich
Kommissionieraufträgen quittiert sind.
Das obige Bespiel wird erweitert. Die fehlende Menge für Position 20 ist eventuell doch
vorhanden. Dieses soll in einer separaten Meldung erfolgen. Dazu erfolgt die erste Rückmeldung
mit einer neuen Position. Diese ist frei wählbar, muß aber eindeutig sein. Die vollständige
Nachricht sieht dann wie folgt aus:

April 2001 177


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Rückmeldung von Versandelementdaten

E2VPDLH
· VBELN_VL 80001234
VBELN 765
E2VPDLI
VBELN_VL 80001234
POSNR_VL 10
VBELN 765
POSNN 10
PIKMG 50
MATNR MAT1
E2VPDLI
VBELN_VL 80001234
POSNR_VL 20
VBELN 765
POSNN 21
ORPOS 20
PIKMG 40
NDIFM 0
MATNR MAT2

Die neue Position ist in diesem Fall 21 und zeigt auf die alte Kommissionierposition 20 (ORPOS).
Durch die Differenzmenge Null wird keine neue Kommissioiernachricht erzeugt. Damit ist es
möglich, die noch offenen Menge (10 ST) zur alten Position 20 zurückzumelden.

E2VPDLH
· VBELN_VL 80001234
VBELN 765
E2VPDLI
VBELN_VL 80001234
POSNR_VL 20
VBELN 765
POSNN 20
PIKMG 10
MATNR MAT2

178 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Rückmeldung von Versandelementdaten

April 2001 179


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Senden von Kommissionieraufträgen

Senden von Kommissionieraufträgen


Mit dem IDoc SDPIOD01 können Sie pro Versandstelle die Daten der Kommissionierliste an ein
Fremdsystem übergeben.
Hierzu muß die Nachrichtenfindung im Customizing Vertrieb geändert werden. Der Versandstelle
wird anstelle der Nachricht EK00, die auf die Kommissionierliste verweist, die Nachricht EKSU
mit dem Medium 8 und ein Fremdsystem (Logisches System) zugewiesen. Dadurch wird die
Übermittlung an das Fremdsystem angestoßen. Zusätzlich muß für den Nachrichtentyp PICKSD
die Partnervereinbarung Ausgang gepflegt sein.
Das IDoc SDPIOD01 besteht aus den Segmenten E2VPPIH (Kopfdaten) und E2VPPII
(Positionsdaten). Der Aufbau dieser Segmente wird im folgenden beschrieben.

E2VPPIH

Felder Format Bezeichnung Muß Bemerkung


VBELN CHAR 10 Lieferung
VSTEL CHAR 4 Versandstelle
ROUTE CHAR 6 Route
BEROT CHAR 20 Bereitstellungsort Textfeld aus Lieferkopf
LPRIO NUMC N 2 Lieferpriorität
KODAT DATS D 8 Kommissionierdatum
LDDAT DATS D 8 Ladedatum
BTGEW CHAR 15 Bruttogewicht
GEWEI CHAR 3 Gewichtseinheit
VOLUM CHAR 15 Volumen
VOLEH CHAR 3 Volumeneinheit
ANRED CHAR 15 Anrede Lieferant
NAME1 CHAR 35 Name 1 Lieferant
NAME2 CHAR 35 Name 2
NAME3 CHAR 35 Name 3
NAME4 CHAR 35 Name 4
STRAS CHAR 35 Straße und Hausnummer
PFACH CHAR 10 Postfach
PSTL2 CHAR 10 Postleitzahl des Postfach
LAND1 CHAR 3 Länderschlüssel
PSTLZ CHAR 10 Postleitzahl
ORT01 CHAR 35 Ort

180 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Senden von Kommissionieraufträgen

ORT02 CHAR 35 Ortsteil


REGIO CHAR 3 Region
KUNNR CHAR 10 Warenempfänger
KOMAU CHAR 10 Kommissionierauftrag Wichtig für Rückmeldung

E2VPPII (Die Felder entsprechen im wesentlichen den Positionsdaten der Lieferung


(/nVL02 Positionen)

Felder Format Bezeichnung Muß Bemerkung


VBELN CHAR 10 Lieferung
POSNR NUMC N 6 Lieferposition
SORTKRI CHAR 20 Sortierkriterium
KDMAT CHAR 22 Material des Kunden Material-ID des Kunden (z.B. aus
Mat.stamm)
MATNR CHAR 18 Materialnummer
ARKTX CHAR 40 Kurztext der
Kundenauftragspos.
WERKS CHAR 4 Werk
LGORT CHAR 4 Lagerort
BWTAR CHAR 10 Bewertungsart
CHARG CHAR 10 Chargennummer
LFIMG CHAR 15 Liefermenge in Verkaufs-Meh
LGMNG CHAR 15 Liefermenge in Lager-Meh
KOMNG CHAR 15 Zu kommissionierende Menge
VRKME CHAR 3 Verkaufsmengeneinheit
MEINS CHAR 3 Lagermengeneinheit wie in VL02 bzw. in Datenbank-
UMVKZ CHAR 5 Zähler für die Umrechnung Tabelle LIPS
UMVKN CHAR 5 Nenner für die Umrechnung -“-
BWART CHAR 3 Bewegungsart -“-
(Bestandsführung)
BWLVS NUMC N 3 Bewegungsart nicht relevant
Lagerverwaltung
LGNUM CHAR 3 Lagernummer nicht relevant
LGTYP CHAR 3 Lagertyp nicht relevant
LGPLA CHAR 10 Lagerplatz nicht relevant

April 2001 181


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Senden von Kommissionieraufträgen

KZDLG CHAR 1 Kennzeichen dynamischer nicht relevant


Lagerplatz
LGPBE CHAR 10 Lagerplatz nicht relevant
MBDAT DATS D 8 Materialbereitstellungsdatum spätester Beginn der
Kommissionierung
SOBKZ CHAR 1 Sonderbestandskennzeichen
VGBEL CHAR 10 Belegnummer des
Vorlagebelegs
BRGEW CHAR 15 Bruttogewicht
NTGEW CHAR 15 Nettogewicht
GEWEI CHAR 3 Gewichtseinheit
VOLUM CHAR 15 Volumen
VOLEH CHAR 3 Volumeneinheit
XCHPF CHAR 1 Kennzeichen für Material ist chargenpflichtig
Chargenpflicht
XCHAR CHAR 1 Kennzeichen für Bewertugsart muß
Chargenführung zurückgemeldet werden

Die Felder werden entsprechend der Definition im Lieferbeleg gefüllt.


Zu jedem Lieferbeleg erzeugt SAP einen Kommissionierauftrag. Dieser legt im wesentlichen die
zu diesem Zeitpunkt zu kommissionierenden Materialien und Mengen fest und wird mit dem IDoc
SDPIOD01 an das Fremdsystem übergeben. Wird dem Lieferbeleg zu einem späteren Zeitpunkt
eine Position hinzugefügt bzw. eine Menge in einer alten Position erhöht, so wird ein neuer
Kommissionierauftrag für die Änderungen erzeugt und versendet.

Wenn Sie Lieferbelege versenden und Kommissionierrückmeldungen an SAP


melden, können Sie nicht mehr mit chaotischer Kommissioniertechnik in der
Lagerverwaltung (WM) arbeiten, d.h. es können keine Transportaufträge zur
Lieferung mehr erstellt werden. Wenn Sie Ihre Materialien also trotzdem im WM
verwalten wollen, geht das nur mit Kommissioniertechnik ‘Festplatz’. Dann wird
beim Warenausgang der Lieferpositionen direkt der Bestand im entsprechenden
Festplatzlagertyp abgebucht (zum Thema Kommissioniertechnik siehe auch Online-
Dokumentation WM.

182 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Rückmeldung Kommissionierauftrag an Lieferung

Rückmeldung Kommissionierauftrag an Lieferung


Mit dem IDoc SDPIID01 können Sie quittierte Mengen, Chargensplitts und
Bewegungsartensplitts an die Lieferung zurückmelden.
Dazu muß die Partnervereinbarung Eingang für den Nachrichtentyp SDPICK gepflegt werden.
Das IDoc SDPIID01 besteht aus den Segmenten E2VPDLH (Kopfdaten) und E2VPDLLI
(Positionsdaten). Der Aufbau dieser Segmente wird im folgenden beschrieben.

E2VPDLH
Felder Format Bezeichnung Muß Bemerkung
VBELN_VL CHAR 10 Lieferung X
VBELN CHAR 10 Folgevertriebsbeleg X Kommissionierauftrag, Feld
KOMAU
LGNUM CHAR 3 Lagernummer ohne Funktion
TANUM NUMC N Transportauftragsnummer X zu füllen wie VBELN
10
KODAT DATS D 8 Kommissionierdatum
KOUHR TIMS T 6 Erfassungszeit
BRGEW CHAR 15 Bruttogewicht geplant, z.Zt. ohne Funktion
NTGEW CHAR 15 Nettogewicht geplant, z.Zt. ohne Funktion
GEWE CHAR 3 Gewichtseinheit geplant, z.Zt. ohne Funktion
VOLUM CHAR 15 Volumen geplant, z.Zt. ohne Funktion
VOLEH CHAR 3 Volumeneinheit geplant, z.Zt. ohne Funktion
KOMUE CHAR 1 Automatische Anpassung der falls keine weiteren Mengen zur
Liefermenge Position zurückgemeldet werden
WABUC CHAR 1 Automatischer Warenausgang Kennzeichen X

E2VPDLI
Felder Format Bezeichnung Muß Bemerkung
VBELN_VL CHAR 10 Lieferung X
POSNR_VL NUMC N 6 Lieferposition X
VBELN CHAR 10 Folgevertriebsbeleg X s.o. zu füllen mit KOMAU
POSNN NUMC N 6 Folgeposition eines X neue Position bei Chargensplitt
Vertriebsbelegs
VBTYP_N CHAR 1 Folgevertriebsbelegtyp wird immer mit Wert ‘Q’ gefüllt
PIKMG CHAR 15 Kommissionierte Menge X
MEINS CHAR 3 Mengeneinheit ohne Funktion
NDIFM CHAR 15 Differenzmenge Menge 0 erlaubt
TAQUI CHAR 1 Quittierung wird immer quittiert
BRGEW CHAR 15 Bruttogewicht ohne Funktion
NTGEW CHAR 15 Nettogewicht ohne Funktion
GEWEI CHAR 3 Gewichtseinheit ohne Funktion
VOLUM CHAR 15 Volumen ohne Funktion
VOLEH CHAR 3 Volumeneinheit ohne Funktion
CHARG CHAR 10 Chargennummer
MATNR CHAR 18 Materialnummer X für Prüfzwecke

April 2001 183


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Rückmeldung Kommissionierauftrag an Lieferung

ORPOS NUMC N 6 Referenz auf siehe Beispiele


Kommissionierposition
Die Rückmeldung muß sich immer auf einen Kommissionierauftrag beziehen, der an das
Fremdsystem gesendet wurde (über das Feld KOMAU im Segment E2VPPIH). Dabei wird keine
neue Positionsnummer für den Kommissionierauftrag vergeben, da sie der Positionsnummer in
der Lieferung entspricht. Somit stimmen die Felder POSNN und POSNR_VL überein, falls ohne
Positionssplitt gearbeitet wird. Sollen dagegen zu einer Position mehrere Sätze zurückgemeldet
werden, z.B. weil ein Chargensplitt vorliegt, so müssen die Sätze im Feld POSNN eine neue
Positionsnummer erhalten. In diesem Fall enthält das Feld ORPOS die Referenz auf die alte
Positionsnummer, also auf den Inhalt von POSNR_VL.
Das Feld NDIFM stellt die Menge dar, die nicht kommissioniert werden kann. Das Feld wird nur
ausgewertet, falls mit Positionssplitt (also Feldern POSNN und ORPOS) gearbeitet wird (siehe
Beispiel). Falls keine neuen Positionen zurückgemeldet werden, wird die Differenz aus
angeforderter und zurückgemeldeter Menge automatisch berechnet. Existieren nach der
Rückmeldung in der Lieferung Positionen, die voll erfüllt sind, so wird eine neue
Kommissioniernachricht erzeugt. Deren Verarbeitung führt zu einem weiteren
Kommissionierauftrag. Soll das verhindert werden, so muß das Kopffeld KOMUE gesetzt
werden. Dadurch werden in allen Positionen die Liefermengen an die Kommissioniermengen
angepaßt. Eine vorhandene offene Kommissioniernachricht wird gelöscht.

Struktur für Rückmeldungen [Seite 177]

Die Reaktion auf die Felder XCHPF und XCHAR im Kommissionierauftrag ist wie
folgt: Ist das Kennzeichen XCHPF gesetzt, dann ist das Material chargenpflichtig und
das Fremdsystem muß bei der Rückmeldung die Charge im Feld CHARG der
Position mitgeben. Hierbei kann im Kommissionierauftrag bereits eine bestimmte
Charge vorgegeben sein. Andernfalls muß eine Chargenfindung im Fremdsystem
erfolgen. Ist das Kennzeichen XCHAR gesetzt, handelt es sich nicht um eine
geforderte Charge, sondern um eine spezielle Bewertungsart. Dann muß vom
Fremdsystem die Bewertungsart im Feld CHARG mitgeliefert werden.

184 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Rückmeldung Kommissionierauftrag an Lieferung

Beispiel: Verpackung
Die Funktionalität wird an folgendem Beispiel erläutert. Die Lieferung 80001234 enthält eine
Position 10 mit 10 ST des Materials MATERIAL. Dieses Material wird in 2 Kartons mit 6 ST und 4
ST verpackt. Die beiden Kartons sind in einer Kiste enthalten. Diese Information soll vom
Fremdsystem zurückgemeldet werden.
Die beiden Verpackungen Karton und Kiste sind als Materialien KARTON und KISTE mit
Materialart VERP im Materialstamm vorhanden. Damit sind sie als Versandhilfsmittel nutzbar.
Dem Material MATERIAL ist die VHM-Gruppe INNEN, dem Versandhilfsmittel KARTON die
VHM-Gruppe AUSSEN zugeordnet. Dem Versandhilfsmittel KISTE ist keine VHM-Gruppe
zugeordnet. Damit ist es nicht weiter verpackbar.
Die einzelnen Felder der Segmente sind wie folgt zu füllen:

· E2VPACD
VBELN 0080001234
· E2VPACH
EXIDV VP1
VHILM KARTON
· E2VPACH
EXIDV VP2
VHLIM KARTON
· E2VPACH
EXIDV VP3
VHLIM KISTE
· E2VPACI
EXIDV_OB VP1
VBELN 00800001234
POSNR 000010
TMENG 30
· E2VPACI
EXIDV_OB VP2
VBELN 00800001234
POSNR 000010
TMENG 20
· E2VPACI
EXIDV_OB VP3
EXIDV VP2

April 2001 185


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Rückmeldung Kommissionierauftrag an Lieferung

· E2VPACI
EXIDV_OB VP3
EXIDV VP2

Das Feld EXIDV bzw. EXIDV_OB enthält die externe Identfikation eines Versandelements. Diese
werden benötigt, um den Verpackungsinhalt eindeutig zuzuordnen. Bei der Rückmeldung wird
zusätzlich eine systeminterne Identifikation vergeben. Einem Versandhilfsmittel können
packbares Gewicht und Volumen zugeordnet werden. Diese Information wird verwendet, um die
Plausibilität einer Verpackung zu gewährleisten. In obigem Beispiel besitzt das Material
MATERIAL das Bruttogewicht 0.5 KG, das Versandhilfsmittel KARTON das Packgewicht 4KG.
Somit können tatsächlich 6 Stück MATERIAL in das Versandelement VP1 gepackt werden (die
Ungleichung 3 KG < 4 KG ist erfüllt). Eine analoge Betrachtung erfolgt für das Volumen. Dabei ist
zu beachten, daß keine Abmessungen (Breite, Höhe, Tiefe) überprüft werden.

186 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Transportaufträge

Transportaufträge
Empfangen / Senden von Transportaufträgen
Das IDoc WMTOID01 wird sowohl zum Versenden als auch zum Empfangen von
Transportaufträgen verwendet. Es besteht aus den Segmenten E2LTORH für den
Transportauftragskopf und dem E2LTORI für die Transportauftragspositionen.
Der zugehörige Nachrichtentyp zur Pflege der Partnervereinbarungen Eingang bzw. Ausgang
heißt WMTORD.
Mittels des Transportauftrags werden im WM sämtliche Lagerbewegungen innerhalb einer
Lagernummer erfaßt. Der Transportauftrag enthält Informationen über diese Bewegungen und
den Transport einer bestimmten Menge eines Materials von einem Lagerplatz zu einem anderen.
Unabhängig davon, ob es sich um eine Einlagerung, eine Auslagerung oder Umlagerung
handelt, werden alle diese Lagerbewegungen als Transportaufträge abgebildet.
Oft ist für ein Fremdsystem die genaue Trennung der Lagerbewegungen nach Ein-, Aus-,
Umlagerung und Umbuchung unbedingt notwendig. Im WM gibt es grundsätzlich keine
Aufteilung der einzelnen Lagerbewegungen, d.h. unabhängig von der ‘Art’ der Bewegung wird
immer der Transportauftrag erstellt, der die einzelnen Daten stets in Form des IDocs WMTOID01
an das Fremdsystem übergibt. Um die versendeten Transportaufträge auf der Fremdsystemseite
nach der ‘Art’ der Lagerbewegung zu unterscheiden, können folgende Daten des
Transportauftrags benutzt werden:
1. Bewegungsart
2. Transportart
3. beteiligte Lagertypen
Außer den Transportauftragsdaten kann für die Bestimmung der Art der Lagerbewegung noch
die Variante der WM-Nachricht, die bei der Definition der Bewegungen für die Anbindung an
diese Schnittstelle festgelegt wird, benutzt werden.

Senden von Transportaufträgen von WM an ein Fremdsystem


Zum Versenden von Transportaufträgen an ein Fremdsystem sind lagerspezifische Daten zu
pflegen, z.B. für welche Bewegungen in welchen Lagertyp überhaupt ein IDoc versendet werden
soll. Die notwendigen Customizing-Einstellungen entnehmen Sie bitte dem
Einführungsleitfaden (IMG).
Beim Senden eines Transportauftrags an das Fremdsystem werden alle im Transportauftrag
gefüllten Felder in das IDoc übernommen. Welche Felder mit dem IDoc versendet werden, hängt
von mehreren Kriterien ab:
1. Art des Transportauftrags, d.h ob es sich um Ein-, Aus-, Umlagerung bzw. Umbuchung
handelt.
2. Definition der Bewegungsart, z.B. beim Einlagern, ob das WE-Datum gesetzt werden
soll.
3. Verursacher der Transportaufträge:
- manueller Transportauftrag
- Transportauftrag zur Lieferung

April 2001 187


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Transportaufträge

- Transportauftrag zum Transportbedarf


- Transportauftrag zum Materialbeleg
4. Art der Lagerverwaltung, d.h. ob die Lagerverwaltung innerhalb des Lagers mit oder
ohne Lagereinheitenverwaltung ( LE)erfolgt.
Bei einem LE-verwalteten Lager werden die Lagereinheiten über die Felder VLENR’ und
‘NLENR’ übergeben. Dabei ist folgendes zu beachten:
- handelt es sich um eine Einlagerung in ein LE-verwaltetes Lager, wird die LE-
Nummer im Feld ‘NLENR’ versendet
- bei Auslagerung aus einem LE-verwalteten Lager erscheint die LE-Nummer im Feld
‘VLENR’
- bei Umlagerungen zwischen zwei LE-verwalteten Lagern wird in beiden Feldern die
LE-Nummer übergeben. Wird eine Lagereinheit vollständig umgelagert, sind die
beiden LE-Nummern gleich. Wird die Ware von einer Lagereinheit auf eine andere
Lagereinheit umgelagert, werden beide beteiligten LE-Nummern übergeben.
Der Inhalt dieses IDoc muß kundenindividuell bestimmt werden. Nachdem alle Customizing-
Einstellungen der WM-Abwicklung durchgeführt wurden, ist es daher sinnvoll, Transportaufträge
zu erstellen, die an das Fremdsystem versendet werden sollen, und den Inhalt der erstellten
IDocs über die IDoc-Anzeige zu prüfen.
Beispielsweise ist die übergebene Mengeneinheit, in welcher die TA-Menge gemeldet wird,
diejenige, in der der TA erstellt wurde. Ist z.B. im SAP-System für ein Material mit Basis-ME ‘ST
‘ auch eine Alternativ-ME ‘L‘ gepflegt, kann ein im SAP-System erstellter TA sowohl eine ‘L‘- als
auch eine ‘ST‘-ME übergeben, abhängig davon, in welcher Einheit der TA selbst erstellt wurde.

Senden von Transportaufträgen von einem Fremdsystem an WM


Werden bestimmte Lagerbewegungen im Fremdsystem angestoßen, d.h. erfolgt zuerst der
physische Transport, der vom Fremdsystem bestimmt wurde, dann müssen diese auch dem
WM-System bekanntgegeben werden. In diesem Fall wird das IDoc WMTOID01 im
Fremdsystem aufgebaut und an das WM versendet. Im WM wird aus dem IDoc ein
Transportauftrag erzeugt, der den durchgeführten Transport im System abbildet und die
notwendigen Buchungen auf den beteiligten Lagerplätzen durchführt.
Das IDoc WMTOID01 wird im folgenden beschrieben. Die Spalten “Muß” und “Bemerkungen”
beziehen sich dabei auf Mußfelder, die beim Versenden des IDocs vom Fremdsystem an WM
gefüllt werden müssen.
Im folgenden werden die einzelnen Segmente beschrieben.

E2LTORH
Felder Format Bezeichnung Muß Bemerkung
LGNUM CHAR 3 Lagernummer X Kopplung in Lagernummer
einschalten
TANUM CHAR 10 Transportauftragsnummer

BWLVS CHAR 3 Bewegungsart Lagerverwaltung X

TBPRI CHAR 1 Transportpriorität

TRART CHAR 1 Transportart E = Einlagerung, A =


Auslagerung; U = Umlagerung

188 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Transportaufträge

REFNR CHAR 10 Gruppe Klammern einzelner TAs


möglich
BETYP CHAR 1 Bedarfstyp

BENUM CHAR 10 Bedarfsnummer

KZPLA CHAR 1 Indicator: Vorgeplanter TA

PLDAT CHAR 8 Geplantes Ausführungsdatum

PLZEI CHAR 6 Geplante Ausführungszeit

LZNUM CHAR 20 Zusätzliche Bezugsnummer Zusätzliches Referenzfeld

BNAME CHAR 12 Benutzername

KISTZ CHAR 1 Indicator: Actual processing time


in TO required
KZLEI CHAR 1 Kennzeichen: Leistungsdaten
PERNR 8 R Bearbeiter des TAs
(Personalnummer)
SOLWM CHAR 15 Sollaufwand WM

SOLEX 15 R Sollaufwand Fremdsystem


ISTWM CHAR 15 Ist-Zeit des WM-TA

ZEIEI CHAR 3 Zeiteinheit für Leistungsdaten

STDAT CHAR 8 Start-Datum des TA


ENDAT CHAR 8 Ende-Datum des TA
STUZT CHAR 6 Start-Uhrzeit des TA
ENUZT CHAR 6 Ende-Uhrzeit des TA
L2SKA CHAR 1 Transportauftragstyp bei 2-stufiger
Kommissionierung
LGTOR CHAR 3 (Eingangs-/Versand-)Tor der
Lagernummer
LGBZO CHAR 10 Bereitstellungszone der
Lagernummer
NOSPL 1 R Kein TA-Splitt
SWABW CHAR 4 Schwellwert für Abweichung Wird bei der TA-Erstellung
Sollaufwand / Istaufwand im TA ermittelt und in den Outbound-
IDoc aufgenommen
VBTYP CHAR 1 Verkaufsbelegart, die mit dem Gibt an, ob der Vorgang einen
Outbound-IDoc übergeben wird Retouren-TA, einen Anliefer-
TA oder einen Ausliefer-TA
betrifft
AUSFB CHAR 4 Ermöglicht die Rückmeldung
eines Kennzeichens für die
TA-Ausführung

April 2001 189


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Transportaufträge

E2LTORI
Felder Format Bezeichnung Muß Bemerkung
TAPOS CHAR 4 Transportauftragsposition X
MATNR CHAR 18 Materialnummer
WERKS CHAR 4 Werk X
CHARG CHAR 10 Chargennummer X falls Material chargenpflichtig
BESTQ CHAR 1 Bestandsqualifikation im Lager X falls Bestand mit Qualifikation
SOBKZ CHAR 1 Sonderbestandskennzeichen X falls Sonderbestand
LSONR CHAR 24 Sonderbestandsnummer X falls Sonderbestand
MEINS CHAR 3 Mengeneinheit X
LETYP CHAR 3 Lagereinheitentyp
KZQUI CHAR 1 Kennzeichen: Quittierungspflicht
KZNKO CHAR 1 Kennzeichen: Nullkontrolle
WEMPF CHAR 12 Warenempfänger
ABLAD CHAR 25 Abladestelle
WDATU CHAR 8 Datum des Wareneingangs
WENUM CHAR 10 Wareneingangsnummer
WEPOS CHAR 4 Wareneingangsposition
ZEUGN CHAR 10 Zeugnisnummer
VLTYP CHAR 3 Vonlagertyp X
VLBER CHAR 3 Vonlagerbereich X
VLPLA CHAR 10 Vonlagerplatz X
VPPOS CHAR 2 Position auf dem Vonlagerplatz
VSOLM CHAR 15 Von-Sollmenge in X
Lagermengeneinheit
NLTYP CHAR 3 Nachlagertyp X
NLBER CHAR 3 Nachlagerbereich X
NLPLA CHAR 10 Nachlagerplatz X
NPPOS CHAR 2 Position auf dem Nachlagerplatz
NSOLM CHAR 15 Nach-Sollmenge in X
Lagermengeneinheit
RLTYP CHAR 3 Rücklagertyp
RLBER CHAR 3 Rücklagerbereich
RLPLA CHAR 10 Rücklagerplatz
RPPOS CHAR 2 Position auf dem Rücklagerplatz
RSOLM CHAR 15 Rück-Sollmenge in
Lagermengeneinheit
MAKTX CHAR 40 Materialkurztext
VLENR CHAR 20 Vonlagereinheitennummer
NLENR CHAR 20 Nachlagereinheitennummer
VFDAT CHAR 8 Verfallsdatum oder X wenn MHD-pflichtiges Material
Mindesthaltbarkeitsdatum
HOMVE CHAR 1 Kennzeichen: Entnahme einer
ganzen homogenen Lagereinheit
QPLOS CHAR 12 Prüflosnummer
QPLOA CHAR 12 Prüflos, aus dem
Verwendungsentscheid getroffen
wurde

190 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Transportaufträge

KZSTI CHAR 1 Kennzeichen: Stichprobe


KOBER CHAR 3 Kommissionierbereich
LGORT 4 R Lagerort
SOLPO CHAR 15 Sollaufwand für
Transportauftragsposition
ZEIEI CHAR 3 Zeiteinheit für Leistungsdaten
L2SKR CHAR 1 Relevanz für 2-stufige
Kommissionierung
VOLUM CHAR 15 Volumen
VOLEH CHAR 3 Volumeneinheit

Außer den mit X markierten Feldern müssen eventuell noch andere Daten vom Fremdsystem
übergeben werden. Wie beim Versenden des IDocs vom WM an das Fremdsystem beeinflussen
auch hier mehrere WM-Customizing-Einstellungen den Umfang des IDocs.
Hierfür einige Beispiele:
1. Die übergebene Bewegungsart definiert eine Einlagerung mit fest definierter VON-
Schnittstelle, d.h. die Bewegungsart bestimmt den VON-Lagertyp und VON-Lagerplatz:
- Die VON-Daten (Lagertyp, Lagerbereich, Lagerplatz) dürfen nicht im Segment
E2LTORI übergeben werden. Die Nachdaten mit NACHLAGERTYP und
NACHLAGERPLATZ sind jedoch erforderlich.
2. Die übergebene Bewegungsart definiert eine Auslagerung auf einer dynamischen
Schnittstelle, die der Kostenstelle entspricht:
- Im Segment E2LTORI müssen der VON-Lagertyp und VON-Lagerplatz versendet
werden.
- Für die Ermittlung der dynamischen Schnittstelle muß im Segment E2LTORH der
Bedarfstyp mit dem Wert ‘K’ und die Bedarfsnummer mit der kontierten Kostenstelle
übergeben werden.
3. Die übergebene Bewegungsart definiert eine beliebige Umlagerung innerhalb einer
Lagernummer:
- Im Segment E2LTORI müssen sowohl die VON- als auch die NACH-Daten, d.h.
jeweils der Lagertyp und Lagerplatz, versendet werden.
4. Die übergebene Bewegungsart verlangt bei der Einlagerung das WE-Datum:
- Im Segment E2LTORI muß das Datum des Wareneingangs übergeben werden.
5. Die übergebene Bewegungsart oder die beteiligten Lagertypen erlauben eine
Rücklagerung:
- Im Segment E2LTORI können die Daten der Rücklagerung mit übergeben werden,
falls eine Rücklagerung auch stattgefunden hat.
6. Innerhalb des übergebenen Lagertyps ist die Lagereinheitenverwaltung aktiv:
- Wird auf einer Lagereinheit in diesem Lagertyp zugelagert, muß die LE-Nummer im
Segment E2LTORI im Feld ‘NLENR’ übergeben werden.

April 2001 191


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Transportaufträge

- Wird aus einer Lagereinheit in diesem Lagertyp eine Menge kommissioniert, muß die
LE-Nummer im Segment E2LTORI im Feld ‘VLENR’ übergeben werden.
- Wird eine Menge von einer Lagereinheit auf eine andere umgelagert, müssen beide
Lagereinheiten im Segment E2LTORI versendet werden.
- Wird eine volle Lagereinheit bewegt, muß diese Bewegung über das IDoc
WMSUID01 an WM gemeldet werden
Der Inhalt dieses IDocs muß auch kundenindividuell bestimmt werden. Zuvor sollten
jedoch der Aufbau und das Versenden des IDocs im SAP-System simuliert werden.
Hierfür können Sie den Testreport RLTORD10 benutzen. Weitere Informationen über die
Durchführung von Tests mit diesem Report finden Sie in der Dokumentation zum Report.

Da beim Empfangen von Transportaufträgen davon ausgegangen wird, daß der


zugehörige Fahrauftrag vom Fremdsystem bereits physisch ausgeführt wurde,
können nur Bewegungsarten verwendet werden, die Sofortquittierung erlauben. Der
im SAP-System aus dem IDoc erzeugte Transportauftrag wird sofort quittiert.
7. Bemerkungen:
- NOSPL bedeutet: Die im System voreingestellten Splittkriterien sollen ignoriert
werden.
- PERNR gibt dem TA die Personalnummer des Bearbeiters mit.
- SOLEX ist der extern ermittelte Aufwand, der zur Leistungserrechnung zusätzlich
zum intern ermittelten Aufwand addiert wird (sinnvoll in Sonderfällen, in denen die
interne Logik nicht alle Details abdeckt).
- Die nicht mit R gekennzeichneten Felder werden, wenn gefüllt, an einen Outbound-
IDoc übergeben.

192 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Quittieren von Transportaufträgen

Quittieren von Transportaufträgen


Mit dem IDoc WMTCID01 (WMTCID02 in Release 4.0) können Sie durchgeführte
Transportaufträge an das SAP-System melden. Diese werden dann im SAP-System quittiert.
Die Partnervereinbarung Eingang muß für den Nachrichtentyp WMTOCO gepflegt werden.
Nicht jeder Transportauftrag muß quittiert werden, d.h. nicht immer ist eine Rückmeldung der
versendeten Transportaufträge notwendig. Über eine Customizing-Einstellung im WM wird
entschieden, ob ein erstellter Transportauftrag quittiert werden muß oder nicht. Diese
Information wird mit dem IDoc WMTOID01 (WMTCID02 in Release 4.0) im Segment
E2LTORI mit dem Feld ‘KZQUI’ übergeben. Die Quittierungspflicht bezieht sich nicht auf
den gesamten Transportauftrag, sondern auf die einzelnen Positionen.
Das IDoc besteht aus drei Segmenten, E2LTCOX zum Quittieren ganzer Lagereinheiten,
E2LTCOH für die Transportauftragsköpfe und E2LTCOI für die TA-Positionsdaten.
Eine Lagereinheit kann im Fall der Mischbelegung mit mehreren Transportaufträgen bewegt
werden. Im Normalfall entspricht aber einer Lagereinheit ein Transportauftrag mit einer
Position. Am einfachsten ist es, die ganze Lagereinheit zu quittieren (siehe Version 1).
Arbeiten Sie ohne Lagereinheitenverwaltung, quittieren Sie einfach ganze
Transportaufträge (siehe Version 2). Diese Art der Quittierung wird normalerweise bei
Auslagerungen benutzt. Beim Einlagern empfiehlt sich eine positionsweise Quittierung
(siehe Version 4), falls mit einem Transportauftrag mehrere Paletten eingelagert werden.
Werden innerhalb einer Lagereinheit Differenzen festgestellt (z.B. Kommissionierung aus
Lagereinheit), quittieren Sie die gesamte Lagereinheit mit den jeweiligen Positionen, die
Differenzen ausweisen (siehe Version 5). Auch beim Rückmelden des gesamten
Transportauftrags können Differenzen explizit für die einzelnen Positionen eingegeben
werden (siehe Version 3).
Die folgende Matrix veranschaulicht die Möglichkeiten der Quittierung. Im Anschluß werden
dann die einzelnen Segmente des IDocs genauer beschrieben.
E2LTCOX = 1, E2LTCOH = 2; E2LTCOI = 3. Diese Abkürzungen entsprechen auch den
Hierarchieebenen der Segmente im IDoc.

IDoc-Aufbau für die Quittierung

Version Segment Anzahl Bedeutung


1 1 1 Quittieren der ganzen Lagereinheit
2 2 1 Quittieren des ganzen Transportauftrags
3 2 1 Quittieren des ganzen Transportauftrags bis auf 1 bis n
1... n Positionen mit Differenz
3
4 2 1 Quittieren einer oder mehrerer Transportauftragsposition(en)
1 (... n)
3
5 1 1 Quittieren einer ganzen Lagereinheit bis auf einige
1... n Transportaufträge, die Positionen mit Differenzen haben
2 1... m
3

April 2001 193


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Quittieren von Transportaufträgen

E2LTCOX relevant für Version 1 und 5

Felder Format Bezeichnung Muß Bemerkung


LGNUM CHAR 3 Lagernummer X
LENUM CHAR 20 Lagereinheitennummer X
QNAME CHAR 12 Benutzername für die Quittierung
SQUIT CHAR 1 Kz. gesamte Lagereinheit quittieren X Wert ‘X’
NLPLA CHAR 10 Nachlagerplatz (siehe folgenden Hinweis)
NPPOS CHAR 2 Nachposition (siehe folgenden Hinweis)

Nlpla und Nppos sind der Nachlagerplatz und die Position auf diesem Platz. Der
Nachlagerplatz und die Position beziehen sich auf den abweichenden
Nachlagerplatz der kompletten Lagereinheit.

E2LTCOH relevant für Version 2, 3, 4 und 5

Felder Format Bezeichnung Muß Bemerkung


LGNUM CHAR 3 Lagernummer X
TANUM CHAR 10 Transportauftragsnummer X
QNAME CHAR 12 Benutzername für die
Quittierung
SQUIT CHAR 1 Kz. gesamten X falls der gesamte Transportauftrag
Transportauftrag quittieren quittiert werden soll.(Version 2, 3 + 5)
KOMIM CHAR 1 Kommissioniermengen in
Lieferung übernehmen /
Warenausgang buchen (ab
Release 4.0)
EINLM CHAR 1 Einlagerungsmenge in (siehe folgenden Hinweis)
Anlieferung übernehmen
TBELI CHAR 1 TB abschließen Setzt den zugrundeliegenden TB bei
der TA-Quittierung auf “endgeliefert”

Bei der Quittierung eines TA zu einer Anlieferung bestimmt der Schalter Einlm, ob
die Einlagerungsmenge in den Anlieferungsbeleg übernommen und der
Wareneingang gebucht wird. Er verhält sich wie KOMIM bei der Auslieferung.

E2LTCOI relevant für Version 3, 4 und 5

194 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Quittieren von Transportaufträgen

Felder Format Bezeichnung Muß Bemerkung


TAPOS CHAR 4 Transportauftragspositio X
n
SQUIT CHAR 1 Kennzeichen: Quittieren X falls die Position ohne Differenz quittiert
ohne werden soll
NISTA CHAR 15 Nach-Istmenge X falls Differenz auf Nachlagerplatz
NDIFA CHAR 15 Nach-Differenzmenge X falls Differenz auf Nachlagerplatz
RISTA CHAR 15 Rück-Istmenge X falls Differenz auf Nachlagerplatz
RDIFA CHAR 15 Rück-Differenzmenge X falls Differenz auf Nachlagerplatz
KZNUL CHAR 1 Kennzeichen: Platz bei X falls Nullkontrolle
Nullkontrolle leer
PISTA CHAR 15 Restmenge nach X falls Nullkontrolle
Nullkontrolle
ALTME CHAR 3 Mengeneinheit X falls Mengen mitgegeben
KZDIF CHAR 1 Differenzenkennzeichen X falls Buchung auf bestimmte
Differenzenschnittstelle gewünscht
LENUM CHAR 20 Lagereinheitennummer X falls Quittierung im Blocklager
VQUIT CHAR 1 Quittierung im X falls Quittierung im Blocklager
Blocklager Entnahme
der ganzen LE
PICKM CHAR 15 Kommissioniermenge
bei Blocklagerquittierung
DIFFM CHAR 15 Differenzmenge bei
Blocklager
RESTM CHAR 15 Restmenge bei
Blocklagerquittierung
BQUIT CHAR 1 Quittierung im
Blocklager keine
weiteren Positionen
KZFOL CHAR 1 Kennzeichen:
Folgeaktion
NLPLA CHAR 10 Nachlagerplatz (siehe folgenden Hinweis)
NPPOS CHAR 2 Nachposition (siehe folgenden Hinweis)

Nlpla und Nppos sind der Nachlagerplatz und die Position auf diesem Platz, falls
der Nachlagerplatz vom Systemvorschlag abweicht. Im Segment E1LTCOI bezieht
sich der Platz auf eine TA-Position.

E2LTCOG

April 2001 195


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Quittieren von Transportaufträgen

(Sie benötigen dieses Segment, wenn Sie den Soll- und Istaufwand für
Transportaufträge erfassen möchen.)
Felder Format Bezeichnung Muß Bemerkung
LGNUM CHAR 3 Lagernummer
TANUM CHAR 10 Transportauftrag, für den die Daten
zurückgemeldet werden
SOLEX CHAR 15 Sollaufwand Fremdsystem
PERNR CHAR 8 Bearbeiter des TAs (Personalnummer)
STDAT CHAR 8 Start-Datum des TA
ENDAT CHAR 8 Ende-Datum des TA
STUZT CHAR 6 Start-Uhrzeit des TA
ENUZT CHAR 6 Ende-Uhrzeit des TA
ISTWM CHAR 15 Ist-Zeit des WM-TA
AUSFB CHAR 4
Beim Quittieren von Transportaufträgen kann der Istaufwand im TA an das System
zurückgemeldet werden. Der Sollaufwand wird normalerweise im SAP-System bestimmt und
kann durch den vom Fremdsystem gemeldeten Sollaufwand (SOLEX) ergänzt werden. In
welcher Form der Istaufwand zurückgemeldet werden kann, hängt von den im TA-IDoc
übermittelten Daten ab (KZLEI und KISTZ).
Ist-Daten können für KZLEI = 2, 3 oder 4 zurückgemeldet werden. Dies kann unabhängig
von der eigentlichen Quittierung durch das Senden des E2LTCOG-Segments erfolgen.
Abhängig vom Kennzeichen KISTZ aus dem TA-IDoc kann die Rückmeldung in folgender
Form erfolgen:
KISTZ = 1 => Felder: ISTWM, PERNR.
KISTZ = 2 oder 3 => Felder: STDAT, STUZT, ENDAT, ENUZT, PERNR.
Dabei bezieht sich die Einheit von SOLEX und ISTWM auf die Zeiteinheit, die im TA-IDoc im
Feld ZEIEI steht.
Mit KOMIM = 1 werden beim Quittieren des TA die Kommissioniermengen in der
Lieferposition angepaßt; mit KOMIM = 2 wird zusätzlich der Warenausgang angestoßen. Die
WA-Buchung erfolgt allerdings erst dann, wenn alle Lieferpositionen zurückgemeldet wurden.

Wichtig: will man die Warenausgänge zur Lieferung anstoßen, darf pro IDoc und
Kommunikationsvorgang nur ein einziger Transportauftrag mitgegeben werden. Der
KOMIM = 2 reduziert also die Massenfähigkeit des IDocs.

Warenbewegungen
Es gibt bestimmte Lagervorgänge, die beim Quittieren gesondert betrachtet werden müssen.

1. Rückmelden von Differenzen

196 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Quittieren von Transportaufträgen

Werden bei einer Lagerbewegung Differenzen festgestellt, müssen diese beim


Rückmelden vom Fremdsystem über das IDoc WMTCID01 im Segment E2LTCOI
übergeben werden. Folgende Felder müssen versendet werden:
SQUIT leer
NISTA Istmenge der Lagerbewegung, d.h. die tatsächlich bewegte bzw. entnommene Menge
NDIFA Differenzmenge der Lagerbewegung, d.h die Differenz zwischen der im
Transportauftrag übergebenen Menge und der Istmenge
RISTA Istmenge für die Rückposition (nur falls Rückposition vorhanden)
RDIFA Differenzmenge für die Rückposition
ALTME Mengeneinheit, auf die sich die Mengen beziehen (aus dem vom WM versendeten
Transportauftrag)
KZDIF falls der Lagertyp und der Lagerplatz, auf den die Differenz gebucht wird, übersteuert
werden soll
Um Differenzen zu melden, müssen Versionen 3, 4 und 5 verwendet werden.
Grundsätzlich muß die gesamte Sollmenge der entsprechenden TA-Position
zurückgemeldet werden. Dabei gilt für die E2LTORI-VSOLM:
VSOLM = NISTA + NDIFA + RISTA + RDIFA. Hier geht eine eventuell gefundene
Restmenge PISTA nicht ein. Sie wird extra angegeben.
2. Rückmeldung bei Nullkontrolle
Bei der Auslagerung aus einem Lagertyp mit Nullkontrolle muß der durch die zu
quittierende Lagerbewegung leer werdende Lagerplatz explizit zurückgemeldet werden.
Wird im vom WM versendeten Transportauftrag im Segment E2LTORI im Feld ‘KZNKO’
ein X übergeben, muß die Nullkontrolle im IDoc WMTCID01 im Segment E2LTCOI
zurückgemeldet werden. Ist der Lagerplatz nach der Entnahme leer, muß im Feld
‘KZNUL’ ein X übergeben werden. Bleibt ein Restbestand auf diesem Platz, müssen
folgende Felder im Segment E2LTCOI übergeben werden:
KZNUL leer
PISTA der gezählte Restbestand
ALTME Mengeneinheit, auf die sich die Mengen beziehen (aus dem vom WM versendeten
Transportauftrag)
Wird keine Nullkontrolle vom WM angefordert, kann trotzdem die Nullkontrolle vom
Fremdsystem zurückgemeldet werden, falls der Lagerplatz nach der Entnahme leer wird
(der Bestand im System weicht vom physischen Bestand ab). Auch im diesen Fall muß
im IDoc WMTCID01 im Segment E2LTCOI das Feld‘KZNKO’ auf X gesetzt werden.
Bei der Quittierung mit Nullkontrolle muß die Version 3 oder 4 verwendet werden.
3. Quittierung im LE-verwalteten Blocklager
Beim Quittieren des Transportauftrags im LE-verwalteten Blocklager müssen die
entnommenen Lagereinheiten zurückgemeldet werden.
Soll eine komplett entnommene Lagereinheit zurückgemeldet werden, müssen folgende
Felder im Segment E2LTCOI übergeben werden:

April 2001 197


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Quittieren von Transportaufträgen

LENUM Nummer der entnommenen Lagereinheit


VQUIT X
Soll eine entnommene Lagereinheit mit Differenz- und/oder Restmenge rückgemeldet
werden, müssen folgende Felder im Segment E2LTCOI übergeben werden:
LENUM Nummer der entnommenen Lagereinheit
PICKM Kommissioniermenge
DIFFM Differenzmenge
RESTM Restmenge
ALTME Mengeneinheit, auf die sich die Mengen beziehen (aus dem vom WM versendeten
Transportauftrag)
· Soll die Entnahme 'Für beendet erklärt werden', d.h. die Rückmeldung der einzelnen
Lagereinheiten für eine Transportauftragsposition ist abgeschlossen, muß im Segment
E2LTCOI das Feld ‘BQUIT’ mit X versendet werden.
· Das Rückmelden in diesem Fall muß positionsweise erfolgen, d.h. es muß die Version 4
verwendet werden. Pro Transportauftragsposition können mehrere Rückmeldungen
erfolgen; pro entnommene Lagereinheit eine Rückmeldung.
Das Versenden der Quittierung vom Fremdsystem kann im SAP-System simuliert werden.
Wir empfehlen, zuerst die für Sie relevanten Quittierungsvorgänge auf diese Weise zu
testen. Zum Testen der Quittierung der Transportaufträge steht Ihnen der Report
RLTOCO00 zur Verfügung. Für die Quittierung der Lagereinheiten ist der Report RLTOCO10
vorgesehen.

Das Feld ‘KZFOL’ im Segment E2LTCOI kann kundenindividuell verwendet werden.


Es ist vorgesehen, daß der Kunde mit diesem Kennzeichen über einen User-Exit in
der IDoc-Verarbeitung im WM eine eigene Verarbeitung ansteuern kann. So kann
beispielsweise bei Differenzen eine Folgeaktion angesteuert werden. Diese
Folgeaktion muß aber vom Kunden in eigener Regie realisiert werden.

198 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Stornieren von Transportaufträgen

Stornieren von Transportaufträgen


Stornoanforderung für Transportaufträge
Mit dem IDoc WMCAID01 können Sie eine Stornoanforderung an ein Fremdsystem senden oder
eine durchgeführte Stornobewegung an das SAP-System zurückmelden.
Für den bidirektionalen Austausch des IDocs müssen die Partnervereinbarungen Ausgang bzw.
Eingang für den Nachrichtentyp WMCATO gepflegt werden.
Grundsätzlich gilt: Es können nur noch nicht quittierte Transportaufträge storniert werden.
Da physische Transporte vom Fremdsystem durchgeführt werden, kann das SAP-System nicht
entscheiden, ob gemeldete Transportaufträge bereits ausgeführt wurden oder nicht. Aus diesem
Grund kann das SAP-System nur eine Stornoanforderung senden. Das Fremdsystem muß
dann entscheiden, wie es darauf reagiert. Ist die Bewegung noch nicht abgearbeitet, kann das
Fremdsystem die Ausführung verhindern und die Bestätigung der Stornierung an das SAP-
System versenden. Andernfalls muß an das SAP-System gemeldet werden, daß die Bewegung
schon ausgeführt wurde und die Stornierung nicht mehr möglich ist. In diesem Fall wird im WM
ein bestimmter Benutzer über diesen Vorgang informiert. Eine entsprechende Meldung wird in
den Eingangskorb dieses Benutzers gestellt. Wie mit den nicht
stornierbarenTransportauftragpositionen weiter verfahren wird, muß vorgangsbezogen
entschieden werden; außerdem müssen die notwendigen Anpassungen manuell durchgeführt
werden.
Zum Versenden von Stornoanforderungen an ein Fremdsystem müssen entsprechend der
Transportauftragsabwicklung auch zusätzlich lagerspezifische Daten gepflegt werden.
Entsprechende Informationen hierzu finden Sie im Einführungsleitfaden des Customizing.
Das IDoc selbst besteht aus zwei Segmenten: den Kopfdaten E2LTCAH und den Positionsdaten
E2LTCAI. Die Segmente werden im folgenden im Detail beschrieben.

E2LTCAH

Felder Format Bezeichnung Muß Bemerkungen

LGNUM CHAR 3 Lagernummer X


TANUM CHAR 10 Transportauftragsnummer X
CNAME CHAR 12 Benutzername für die TA-Stornierung
CANRQ CHAR 1 Anfrage Storno-Transportauftrag X ‘X’ bei Stornoanforderung
CANCL CHAR 1 Antwort Storno-Transportauftrag X ‘X’ bei Storno von
Fremdsystem
SOLEX CHAR 15 Sollaufwand Fremdsystem (siehe folgenden Hinweis)

SOLEX: Wenn Sie den Transportauftrag im intergrierten System stornieren, wird der
Sollaufwand im TA zurückgesetzt. Wenn Sie den TA über das IDoc stornieren,
können Sie den extern ermittelten Sollaufwand noch in den TA übernehmen.

E2LTCAI

April 2001 199


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Stornieren von Transportaufträgen

Felder Format Bezeichnung Muß Bemerkungen

TAPOS CHAR 4 Transportauftragsposition X


VLENR CHAR 20 Vonlagereinheitennummer X
NLENR CHAR 20 Nachlagereinheitennummer X
SFEHL CHAR 1 Kennzeichen: Fehler beim Stornieren
SFTXT CHAR 80 Fehlertext bei Storno
KZFOL CHAR 1 Kennzeichen: Folgeaktion

Stornoanforderung vom WM an das Fremdsystem


Die einzelnen Felder in den Segmenten müssen wie folgt gesetzt werden:
E2LTCAH
· Außer den Mußfeldern ‘LGNUM’ und ‘TANUM’ muß das Feld ‘CANRQ’ mit X versendet
werden.
E2LTCAI
· Außer dem Mußfeld ‘TAPOS’ müssen die Felder ‘VLENR’ und ‘NLENR’ gefüllt werden,
falls die Transportauftragsposition auf Lagereinheiten Bezug nimmt
(Lagereinheitenverwaltung ist für die beteiligten Lagertypen aktiviert)

Storno vom Fremdsystem an das WM


Die einzelnen Felder in den Segmenten müssen wie folgt gesetzt werden:
E2LTCAH
· Außer den Mußfeldern ‘LGNUM’ und ‘TANUM’ muß das Feld ‘CANCL’ mit X versendet
werden.
E2LTCAI
· Soll die Stornierung vom Fremdsystem positiv bestätigt werden, müssen außer dem Feld
‘TAPOS’ keine weitere Daten übergeben werden.
· Soll die Stornierung vom Fremdsystem negativ bestätigt werden (Storno nicht möglich),
muß außer dem Feld ‘TAPOS’ das Feld ‘SFEHL’ auf X gesetzt werden, und im Feld
‘SFTXT’ kann ein Text zur Erläuterung mit übergeben werden. Dieser Text erscheint im
Eingang für Fehlermeldungen.
Das Versenden der Stornoantwort vom Fremdsystem kann im SAP-System simuliert werden.
Wir empfehlen, zuerst die für Sie relevanten Stornovorgänge auf diese Weise zu testen. Zum
Testen der Stornierung stehen Ihnen die Reports RLCATO00 und RLCATO10 zur Verfügung.

Das Feld ‘KZFOL’ im Segment E2LTCAI kann kundenindividuell verwendet werden.


Es ist vorgesehen, daß der Kunde mit diesem Kennzeichen über einen Customer-
Exit in der IDoc-Verarbeitung im WM eine eigene Verarbeitung ansteuern kann
(siehe auch SAP-Systemeinstellungen und Modifikationskonzept [Seite 215]).

200 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Stornieren von Transportaufträgen

April 2001 201


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Freigabe von Gruppen

Freigabe von Gruppen


Das IDoc WMRRID01 dient zur Freigabe von bereits an ein Fremdsystem versendeten
Transportaufträgen zu einer Gruppe.
Der zugehörige Nachrichtentyp heißt WMRREF. Für ihn muß eine Partnervereinbarung Ausgang
gepflegt werden.
Die Gruppennummer wird im WM benutzt, um mehrere Transportaufträge zusammenzufassen
bzw. zu identifizieren. Sie wird bei der Transportauftragserstellung im Sammelgang benutzt. Eine
bestimmte Anzahl von Transportaufträgen wird als Gruppen erstellt. Die Gruppennummer wird im
Kopf des erstellten Transportauftrags an das Fremdsystem versendet (Segment E2LTORH im
IDoc WMTOID01).
Die Transportaufträge werden zu einer Gruppe zusammengefaßt, damit die Warenbewegungen
für mehrere Transportaufträge in einem Schritt erfolgen können, z.B. Bearbeitung von
Transportaufträgen für eine bestimmte Versandstelle oder Auslagerung auf denselben
Schnittstellenlagertyp. Das bedeutet, daß die Lagerbewegung nicht direkt stattfinden soll,
nachdem der Transportauftrag im Fremdsystem empfangen wurde. Ein explizit veranlaßter Start
muß für diese Lagerbewegungen gegeben werden.
Durch die Freigabe einer bestimmten Gruppe in einer WM-Lagernummer wird der Start für die
Lagerbewegungen an das Fremdsystem übergeben.
Das IDoc besteht aus dem Segment E2LRRFX, welches im folgenden beschrieben wird.

E2LRRFX
Felder Format Bezeichnung
LGNUM CHAR 3 Lagernummer
REFNR CHAR 10 Gruppe
DATUM CHAR 8 Datum
UZEIT CHAR 6 Uhrzeit
L2KSR CHAR 1 Relevanz für 2-stufige Kommissionierung
LSKSO CHAR 1 2-stufige Kommissionierung: Freigabestufe
Das Datum und die Uhrzeit für die Freigabe werden momentan im Standard nicht benutzt. Sie
können aber benutzt werden, falls die Freigabe der Gruppe kundenindividuell realisiert wird.

Die Freigabe von TAs zur zweistufigen Kommissionierung kann in unterschiedlichen


Schritten erfolgen (Feld LSKSO):
· 1 = nur direkte TAs (ohne 2-Stufigkeit) der Gruppe
· 2 = nur Aufteilungs-TAs der Gruppe
· 3 = Direkt- und Aufteilungs-TAs der Gruppe
· L2KSR hat den Wert “Space” oder “2” für 2-stufige Kommissionierung aktiv.

202 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Sperren von Lagerplätzen

Sperren von Lagerplätzen


Mit dem IDoc WMBIID01 können einzelne Lagerplätze oder auch Lagerplätze generisch, wie
etwa eine ganze Gasse, vom Fremdsystem an WM zum Sperren bzw. Entsperren versendet
werden.
Es muß die Partnervereinbarung Eingang für den Nachrichtentyp WMBBIN gepflegt werden.
Oft sind auf der Fremdsystemseite wegen technischen Problemen bestimmte Lagerplätze bzw.
ganze Gassen über eine bestimmte Zeit nicht anfahrbar. Damit diese Lagerplätze im WM-
System bei der Platzermittlung nicht berücksichtigt werden, müssen sie gesperrt werden. Das
Sperren dieser Lagerplätze muß vom Fremdsystem initiiert werden. Werden diese Lagerplätze
wieder benutzbar, müssen sie auch vom Fremdsystem wieder entsperrt werden.
Das IDoc besteht aus zwei Segmenten: den Kopfdaten E2LBINH und den Positionsdaten
E2LBINI. Die Segmente werden im folgenden beschrieben.

E2LBINH

Felder Format Bezeichnung Muß


LGNUM CHAR 3 Lagernummer X
LGTYP CHAR 3 Lagertyp X
BLOCK CHAR 1 Sperren Lagerplätze x entweder BLOCK oder DEBLO
DEBLO CHAR 1 Entsperren Lagerplätze x entweder BLOCK oder DEBLO

E2LBINI

Felder Format Bezeichnung Muß


LGPLA CHAR 10 Lagerplatz X Eingabe auch generisch z.B. 01
SKZUA CHAR 1 Sperrkennzeichen: für x mindestens eines der drei Kennz.
Auslagerung
SKZUE CHAR 1 Sperrkennzeichen: für x mindestens eines der drei Kennz.
Einlagerung
SKZSI CHAR 1 Sperrkennzeichen: d. laufende x mindestens eines der drei Kennz.
Inventur
SPGRU CHAR 1 Sperrgrund
· Im Segment E2LBINH wird festgelegt, ob es sich um Sperren oder Entsperren der
Lagerplätze handelt. Beim Sperren Muß im Feld BLOCK ein X versendet werden; beim
Entsperren muß dagegen das Feld DEBLO mit X gesetzt werden.
Die Handhabung der einzelnen Felder im Segment E2LBINI ist beim Sperren und Entsperren
gleich. Dabei ist folgendes zu beachten:
· Es muß mindestens eines der drei Sperrkennzeichen ‘SKZUA’, SKZUE’, ‘SKZSI’
versendet werden.

April 2001 203


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Sperren von Lagerplätzen

· Sollen die Lagerplätze generisch gesperrt werden, etwa eine ganze Gasse, so muß der
Stern * verwendet werden. Z.B. alle Lagerplätze, die mit 01 beginnen: Geben Sie 01* im
Feld LGPLA ein.
· Wird im Feld SPGRU ein Sperrgrund übergeben, muß der zugehörige Text im
Customizing der Lagerverwaltung auch gepflegt sein.
Das Sperren und Entsperren der Lagerplätze aus dem Fremdsystem heraus, kann im SAP-
System simuliert werden. Wir empfehlen, zuerst die für Sie relevanten Vorgänge auf diese
Weise zu testen. Für diesen Test steht Ihnen der Report RLBBIN00 zur Verfügung.

Sollen bestimmte Lagerplätze einzeln gesperrt werden, muß pro Lagerplatz ein
E2LBINI-Segment übergeben werden.

204 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Erzeugen / Stornieren von Transportbedarfen

Erzeugen / Stornieren von Transportbedarfen


Das IDoc WMTRID01 erlaubt es Ihnen, Transportbedarfe aus einem Fremdsystem an das SAP-
System zu senden und dort generieren zu lassen bzw. die bereits versendeten Transportbedarfe
zu stornieren.
Für den Nachrichtentyp WMTREQ muß die Partnervereinbarung Eingang gepflegt werden.
Im Unterschied zur direkten Transportauftragserstellung wird durch einen Transportbedarf noch
keine Suchstrategie im Lager durchgeführt.
Der Transportbedarf wird zur Planung einer Lagerbewegung verwendet. Beispiele sind aus der
Fertigung vorgeplante Transportbedarfe. Die tatsächliche Einlagerung, also das Erstellen und
Bearbeiten von Transportaufträgen mit Bezug auf die Transportbedarfe, könnte dann bei
Produktfertigstellung zeitnah erfolgen.
Der Transportbedarf stellt auch Anforderungen an Lagerbewegungen dar. Ein Beispiel dafür ist
eine Anforderung aus der Produktion, Ware bereitzustellen. Die Produktion bestimmt, welche
Materialien in welcher Menge wann und wo benötigt werden. Im Lager werden die aus den
Anforderungen erstellten Transportbedarfe in Transportaufträge für die Produktionsbereitstellung
umgesetzt.
Das IDoc WMTRID01 besteht aus zwei Segementen: den Kopfdaten E2LTRQH und den
Positionsdaten E2LTRQI. Beide Segmente werden im folgenden beschrieben. Die Spalten “Muß”
und “Bemerkungen” beziehen sich dabei auf Mußfelder, die für das Erzeugen der
Transportbedarfe vom Fremdsystem gefüllt werden müssen. Welche Felder für die Stornierung
benutzt werden, wird gesondert beschrieben.

E2LTRQH

Feld Format Bezeichnung Muß Bemerkungen

LGNUM CHAR 3 Lagernummer X


TBNUM CHAR 10 Transportbedarfsnummer
TRART CHAR 1 Transportart
TBPRI CHAR 1 Transportpriorität
TBKTX CHAR 40 Kopftext des Transportbedarfs
BNAME CHAR 12 Benutzername
BETYP CHAR 1 Bedarfstyp
BENUM CHAR 10 Bedarfsnummer
BWLVS CHAR 3 Bewegungsart Lagerverwaltung X
VLTYP CHAR 3 Vonlagertyp
VLPLA CHAR 10 Vonlagerplatz
NLTYP CHAR 3 Nachlagertyp
NLPLA CHAR 10 Nachlagerplatz
PDATU CHAR 8 Datum der geplanten Ausführung

April 2001 205


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Erzeugen / Stornieren von Transportbedarfen

PZEIT CHAR 6 Uhrzeit der geplanten Ausführung


LZNUM CHAR 20 Zusätzliche Bezugsnummer X beim Stornieren
TBRUE CHAR 1 Kennzeichen: Transportbedarf rückmelden
KTBAE CHAR 1 Kennzeichen: Transportbedarf stornieren X beim Stornieren

E2LTRQI

Feld Format Bezeichnung Muß Bemerkungen

TBPOS CHAR 4 Transportbedarfsposition


MATNR CHAR 18 Materialnummer X
WERKS CHAR 4 Werk X
BESTQ CHAR 1 Bestandsqualifikation im X falls Bestand mit Qualifikation
Lager
CHARG CHAR 10 Chargennummer X falls Material chargenpflichtig
SOBKZ CHAR 1 Sonderbestandskennzeichen X falls Sonderbestand
LSONR CHAR 24 Sonderbestandsnummer X falls Sonderbestand
MENGE CHAR 15 Transportbedarfsmenge X
MEINS CHAR 3 Mengeneinheit X
WEMPF CHAR 12 Warenempfänger
ABLAD CHAR 25 Abladestelle
WENUM CHAR 10 Wareneingangsnummer
WDATU CHAR 8 Datum des Wareneingangs
ZEUGN CHAR 10 Zeugnisnummer
ELIKZ CHAR 1 Kennzeichen: Endlieferung
VFDAT CHAR 8 Verfallsdatum oder X falls Material MHD-pflichtig
Mindesthaltbarkeitsdatum
LGORT 4 R Lagerort
L2SKR 1 R Relevanz für 2-stufige kann den Wert 2 haben oder initial
Kommissionierung sein

Außer den mit X markierten Feldern müssen eventuell noch andere Daten vom Fremdsystem
übergeben werden. Der Umfang der benötigten Daten in diesem IDoc muß von Fall zu Fall
einzeln bestimmt werden. Einerseits entscheidet die Art der Anforderung, wie Einlagerung aus
der Produktion oder Bereitstellung für die Produktion, über Inhalt und Umfang des IDocs;
andererseits beeinflussen auch mehrere WM-Customizing-Einstellungen, welche Felder des
IDocs versendet werden müssen.

206 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Erzeugen / Stornieren von Transportbedarfen

April 2001 207


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Erzeugen von Transportbedarfen

Erzeugen von Transportbedarfen


Beim Aufbauen der Segmente muß folgendes berücksichtigt werden:

E2LTRQH
· Das Feld ‘TBNUM’ für Transportbedarfsnummer darf nicht versendet werden, da die
Nummer im WM vergeben wird.
· Die Felder ‘BETYP’ und ‘BENUM’ müssen versendet werden, falls die Bewegungsart die
Bedarfsnummer erwartet. Über die Bedarfsnummer kann man den Bezug zu dem
Verursacher der Lagerbewegung darstellen, z.B. wird bei der Ankündigung eines
Wareneingangs aus der Produktion der Wert ‘F’ im Feld ‘BETYP’ und die
Fertigungsauftragsnummer im Feld ‘BENUM’ übergeben.
· Die Übergabe der VON- und NACH-Daten (Lagertyp und Lagerplatz) ist von der
Definition der Bewegungsart abhängig und kann benutzt werden, um das Ziel der
Lagerbewegung näher zu definieren.
· Über die Felder ‘PDATU’ und ‘PZEIT’ kann bestimmt werden, wann die Ausführung des
Transportbedarfs, d.h. das Umsetzen in Lagerbewegungen, erfolgen soll.
· Das Feld ‘LZNUM’ wird für eine zusätzliche Bezugsnummer verwendet. Der aus dem
IDoc erzeugte Transportbedarf im WM wird unter einer Transportbedarfsnummer
angelegt. Damit dieser Transportbedarf eindeutig aus Sicht des Fremdsystems
identifizierbar ist, muß die Bezugsnummer im Fremdsystem vergeben und an das WM
übergeben werden. Diese Bezugsnummer ist dann erforderlich, wenn ein bereits
erzeugter Transportbedarf über dieses IDoc storniert wird. Der Zugriff auf den zu
stornierenden Transportbedarf kann im WM nur über die eindeutige Bezugsnummer
erfolgen.
· Das Feld ‘TBRUE’ wird momentan im Standard nicht benutzt. Es ist für
Kundenanpassungen gedacht, falls eine Rückmeldung der abgearbeiteten
Transportbedarfe vom WM an Fremdsystem erforderlich ist.

E2LTRQI
· Die Felder ‘ABLAD’ und ‘WEMPF’ können verwendet werden, um das Ziel für die
Lagerbewegung positionsabhängig genau zu bestimmen; z.B.: Es wird ein
Transportbedarf erzeugt, um mehrere Materialien für einen Fertigungsauftrag innerhalb
der Produktion bereitzustellen. Im Kopf des Transportbedarfs wird zwar der
Produktionslagertyp bestimmt, die einzelnen Materialien werden aber an mehreren
Arbeitsplätzen benötigt. Die einzelnen Arbeitsplätze können im Feld ‘WEMPF’
übergeben werden.
· Die Felder ‘WENUM’ und ‘WDATU’ werden verwendet, wenn mit den versendeten
Transportbedarfen Wareneingänge avisiert bzw. geplant werden.

208 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Stornieren von Transportbedarfen

Stornieren von Transportbedarfen


Beim Aufbuen der Segmente muß folgendes berücksichtigt werden:

E2LTRQH
· Folgende Felder müssen versendet werden:
· ‘LGNUM’
· ‘LZNUM’

E2LTRQI
· Das Feld ‘TBPOS’ für die Transportbedarfsposition ist eine fortlaufende Nummer
innerhalb eines Transportbedarfs. Dieses Feld wird für das Erzeugen eines
Transportbedarfs vom Fremdsystem nicht übergeben, da die Vergabe der
Positionsnummer im WM beim Erstellen des Transportbedarfs erfolgt. Das Stornieren
erfolgt positionsweise, d.h. die Transportbedarfsposition muß dabei bekannt sein. Das
Fremdsystem kann eventuell die Positionsnummer übergeben, dafür muß aber diese
Nummer als laufende Nummer innerhalb des vorher gesendeten IDocs im Fremdsystem
bekannt sein. Ist die Nummer im Fremdsystem nicht bekannt, muß die gesamte
Quantidentifikation einer Position versendet werden, d.h. die Felder ‘MATNR’, ‘BESTQ’,
‘CHARG’, ‘SOBKZ’, ‘LSONR’.
· Soll die Transportbedarfsposition vollständig storniert werden, muß das Feld ‘ELIKZ’ mit
X gefüllt werden. Ist nur eine Teilmenge zu stornieren, muß die zu stornierende Menge
versendet werden. Soll die Menge erhöht werden, muß eine negative zu stornierende
Menge verschickt werden. Dafür müssen die Felder ‘MENGE’ und ‘MEINS’ übergeben
werden.
Da der Inhalt dieses IDocs kundenindividuell bestimmt werden muß, ist es sinnvoll, den Aufbau
und das Versenden des IDocs im SAP-System zu simulieren. Hierfür können Sie den Testreport
RLTREQ00 benutzen. Mehr Informationen über den Test mit diesem Report entnehmen Sie bitte
der Dokumentation des Reports.

April 2001 209


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Bewegen von Lagereinheiten

Bewegen von Lagereinheiten


Mit dem IDoc WMSUID01 können Bewegungen von Lagereinheiten, z.B. Umlagerungen, an das
SAP-System gemeldet und dort nachgezogen werden.
Die Partnervereinbarung Eingang ist für den Nachrichtentyp WMSUMO zu pflegen.
In bestimmten Fällen ist es notwendig, eine Umlagerung von Lagereinheiten im Fremdsystem
anzustoßen. Auch beim Einlagern einer Palette kann es durchaus sinnvoll sein, daß die
endgültige Lagerplatzvergabe im HRL vom Fremdsystem übernommen wird. Die durchgeführte
Bewegung der Lagereinheit muß an das WM gemeldet werden. Voraussetzung dafür ist, daß die
Lagereinheit im WM gebildet wurde und dadurch auch dort bekannt ist. Die gemeldete
Bewegung der Lagereinheit wird im WM nachgebucht.
Das IDoc besteht aus dem Segment E2LSUMX, welches im folgenden beschrieben wird. Dabei
kennzeichnet die Spalte “Muß” die mindestens zu füllenden Felder.

E2LSUMX
Felder Format Bezeichnung Muß
LGNUM CHAR 3 Lagernummer X
LENUM CHAR 20 Lagereinheitennummer X
BWLVS CHAR 3 Bewegungsart Lagerverwaltung X
LETYP CHAR 3 Lagereinheitentyp
LZNUM CHAR 20 Zusätzliche Bezugsnummer
BNAME CHAR 12 Benutzername
KZQUI CHAR 1 Kennzeichen: Quittierungspflicht
VLTYP CHAR 3 Vonlagertyp
VLBER CHAR 3 Vonlagerbereich
VLPLA CHAR 10 Vonlagerplatz
VPPOS CHAR 2 Position auf dem Vonlagerplatz
NLTYP CHAR 3 Nachlagertyp
NLBER CHAR 3 Nachlagerbereich
NLPLA CHAR 10 Nachlagerplatz
NPPOS CHAR 2 Position auf dem Nachlagerplatz
STATU CHAR 1 Status der Lagereinheit
REFNR CHAR 10 Gruppe
PERNR 8 R Bearbeiter des TAs (Personalnummer)
SOLEX 15 R Sollaufwand Fremdsystem

Über das Bewegen der Lagereinheit kann auch der externe Sollaufwand mitgegeben werden.
Beim Versenden des Segments E2LSUMX muß folgendes berücksichtigt werden:
· Das Feld ‘LETYP’ für Lagereinheitentyp muß nicht immer übergeben werden
· Das Feld ‘LZNUM’ wird wie beim Melden eines Transportauftrags benutzt.
· Das Kennzeichen ‘KZQUI’ für Quittierung soll normalerweise nicht gesetzt werden, da die
gemeldete Lagerbewegung bereits vollzogen wurde und dadurch nicht mehr
quittierungspflichtig ist.

210 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Bewegen von Lagereinheiten

· Die VON-Daten (Vonlagertyp, Vonlagerplatz) müssen nicht versendet werden, da die


Lagereinheit im WM bekannt ist und damit der Lagerplatz, auf dem sich die Lagereinheit
aktuell befindet.
· Das Feld ‘NPPOS’ wird nur in Verbindung mit einer bestimmten Einlagerungsstrategie,
der Palettentypstrategie, benutzt und beschreibt innerhalb eines Regalabschnitts die
genaue Position der Lagereinheit, auf der diese eingelagert wurde.
· Die Felder ‘STATU’ und ‘REFNR’ werden für das Melden der Bewegung vom
Fremdsystem nicht benutzt.
Das Melden der Bewegung einer Lagereinheit vom Fremdsystem kann im SAP-System simuliert
werden. Wir empfehlen, zuerst die für Sie relevanten Vorgänge auf diese Weise zu testen. Für
den Test steht Ihnen der Report RLSUMO00 zur Verfügung.
Synchroner Aufruf von ‘L_SU_MOVE_LSR’ (neu ab Release 3.0D)
Im Spezialfall der Einlagerung über I-Punkt kann es sinnvoll sein, anstelle eines IDoc den
genannten Funktionsbaustein synchron (direkt) aufzurufen, also explizit auf die SAP-Antwort zu
warten. Folgendes Szenario:
· Der TA zum I-Punkt wird vom SAP-System an das Fremdsystem gemeldet. Der
Palettenschein wird im SAP-System gedruckt.
· Das Fremdsystem identifiziert die Palette und führt eine Konturenkontrolle durch.
· Abhängig vom Ergebnis der Konturenkontrolle wird der Lagereinheitentyp oder andere
Daten verändert (oder eventuell der Nachlagerplatz vom Fremdsystem bestimmt).
· Das Fremdsystem ruft synchron ‘L_SU_MOVE_LSR’ auf und wartet auf den
Nachlagerplatz (oder, falls es diesen mitgegeben hat, auf die erfolgreiche Verbuchung im
SAP-System).
Da eindeutig bestimmbar ist, wo sich eine Palette genau befindet, können versehentliche
Doppeltbuchungen im SAP-System verhindert werden. Falls die Lagereinheit bereits vom I-Punkt
aus eingelagert wurde, liest der Funktionsbaustein den Nachlagerplatz und meldet ihn zurück.

April 2001 211


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Inventur in der Lagerverwaltung

Inventur in der Lagerverwaltung


In diesem Abschnitt wird das IDoc WMIVID01 beschrieben. Es besteht aus dem Segment
E1LINVX und dient sowohl zum Versenden von Inventurbelegen als auch zum Rückmelden der
Zählergebnisse.
Das Senden der Inventurbelege erfolgt aus dem Bild der Lagerverwaltung: Inventur ®
Aufnahmebeleg ® Drucken. Der Sendereport heißt RLLI0405. Geben Sie das Empfangssystem
ein, und markieren Sie Senden. Die Inventurbelege können parallel auch gedruckt werden. In
beiden Fällen wird ein Kennzeichen fortgeschrieben, das im Falle eines nochmaligen
Versendens oder Druckens auf den Nachdruck hinweist. Gesendet werden alle Daten des
Inventurbelegs, d.h. insbesondere Lagerplatz, Material und Sollmengen etc.
Es muß hierfür die Partnervereinbarung Ausgang für den Nachrichtentyp WMINVE gepflegt
werden.
Zum Empfangen der Zähldaten wird das gleiche IDoc verwendet. Pro gezähltem Lagerquant
muß ein E1LINVX-Segment gesendet werden. Die Reihenfolge des Empfangens ist dabei nicht
relevant. Sie können also ein IDoc mit vielen E1LINVX-Sätzen senden, ohne sich um die
Reihenfolge der Verbuchung im SAP-System zu kümmern.
Für das Rückmelden der Zählergebnisse muß die Partnervereinbarung Eingang für den
Nachrichtentyp WMINVE gepflegt werden.
Das Segment E1LINVX hat folgenden Aufbau. Die Mußfelder beziehen sich dabei auf das
Empfangen durch das SAP-System.

E1LINVX
Felder Format Bezeichnung Muß
LGNUM CHAR 3 Lagernummer X
IVNUM CHAR 10 Nummer des
Inventuraufnahmebelegs
IVPOS CHAR 4 Inventurposition
LGTYP CHAR 3 Lagertyp X
LGPLA CHAR 10 Lagerplatz X
PLPOS CHAR 2 Position auf dem Lagerplatz X falls Einlagerungsstrategie P im
Lagertyp
MATNR CHAR 18 Materialnummer X
WERKS CHAR 4 Werk X
CHARG CHAR 10 Chargennummer X falls mit Charge gearbeitet wird
SOBKZ CHAR 1 Sonderbestandskennzeichen X falls Sonderbestand
LSONR CHAR 24 Sonderbestandsnummer X falls Sonderbestand
BESTQ CHAR 1 Bestandsqualifikation im Lager X falls Q-Bestand
WDATU CHAR 8 Datum des Wareneingangs
LENUM CHAR 20 Lagereinheitennummer X falls LE-verwalteter Lagertyp
MENGA CHAR 15 Menge für Zählergebnisse X entweder hier oder Menge 0
KZNUL
ALTME CHAR 3 Mengeneinheit X
LQNUM CHAR 10 Quantnummer
NANUM CHAR 2 Nachzählungsnummer
NVERS CHAR 2 Nachzählungsversion

212 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Inventur in der Lagerverwaltung

ISTAT CHAR 1 Positionsstatus der Inventur


IDATU CHAR 8 Datum der Inventur
KZINV CHAR 2 Inventurart
IRNUM CHAR 10 Inventurreferenznummer
MAKTX CHAR 40 Materialkurztext
ISEIT CHAR 4 Inventurseite
LETYP CHAR 3 Lagereinheitentyp
KZNUL CHAR 1 Kennzeichen: Platz leer entweder hier oder Menge
MENGA
VFDAT CHAR 8 Verfallsdatum oder X falls Material MHD-pflichtig
Mindesthaltbarkeitsdatum
LGORT 4 R Lagerort
UNAME CHAR 25 Name des Zählers Ermöglicht die Übermittlung des
Namens der Person, die die
Inventur durchführt

Zum Testen kann der Report RLINVE00 verwendet werden. Dieser Report kann
benutzt werden, um die Inventur-Schnittstelle zwischen einem Fremdsystem und
dem WM-System zu testen. Das Erfassen der Daten mittels eines mobilen
Erfassungsgeräts wird dabei im System simuliert.
Die Daten entnimmt das System hierbei bestehenden Inventurbelegen. Damit läßt
sich der Eingang des IDocs WMIVID01 im System simulieren. Vorsicht im
Produktivsystem: Es wird wirklich ein Beleg verbucht!

April 2001 213


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Allgemeine Informationstexte

Allgemeine Informationstexte
Mit dem IDoc WMINID01 können Sie von einem Fremdsystem Informationstexte an SAP senden.
Diese Texte werden als Meldung in die jeweiligen Eingangskörbe der zur Planstelle
zugeordneten Benutzer gestellt (siehe SAP-Systemeinstellungen und Modifikationskonzept
[Seite 215]).
Die Partnervereinbarung Eingang muß dazu zum Nachrichtentyp WMINFO gepflegt werden.
Das Versenden der Informationstexte vom Fremdsystem kann im SAP-System simuliert
werden. Für diesen Test steht Ihnen der Report RLINFO00 zur Verfügung.
Das IDoc besteht aus nur einem Segment, dem E2LINFX. Das Segment wird im folgenden
beschrieben.

E2LINFX

Felder Format Bezeichnung Muß


LGNUM CHAR 3 Lagernummer X
ITEXT CHAR 80 Informationstext bei Kopplung X
DATUM CHAR 8 Datum
UZEIT CHAR 6 Uhrzeit

214 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
SAP-Systemeinstellungen und Modifikationskonzept

SAP-Systemeinstellungen und Modifikationskonzept


Einsatzmöglichkeiten
Dieser Abschnitt gibt Ihnen einen Überblick über die notwendigen Einstellungen im SAP-System
sowie Informationen zu zusätzlichen Anpassungen, die im Rahmen von Customer-Exits möglich
sind.

Informationsquellen
Folgende Informationsquellen stehen Ihnen zusätzlich zur Verfügung:
1. Einführungsleitfaden (online)
Werkzeuge ® Business Engineer ® Customizing ® Einführungsprojekte ® SAP
Referenz-IMG anzeigen ® Logistics Execution ® Lagerverwaltung ® Schnittstellen
® Fremdsysteme ® ALE-Anbindung definieren
Sie werden durch die notwendigen Tabelleneinstellungen geführt, um anwendungsseitig
festzulegen, welche Vorgänge für ein Fremdsystem relevant sind.
2. Stamm-Menü (online)
Logistik ® Logistics Execution ® Lagerverwaltung ® Umfeld ® Fremdsysteme ®
ALE-Funktionen
Die ALE-Funktionen erlauben ein dediziertes Monitoring der empfangenen und
versendeten IDocs.
3. Folgende zusätzliche Dokumentation in Papierform ist zur Vertiefung erhältlich:
- RFC-Handbuch
Genaue technische Beschreibung der Programmierschnittstelle.
- ALE-Beratungshandbuch
Allgemeine Information zur ALE-Technologie und ihren Funktionen
- WorkFlow-Handbuch
Allgemeine Information zum WorkFlow-Konzept (siehe Fehlerbearbeitung)
4. Auswertereport
Diese Auswertung erlaubt es, zu IDocs, die mit Status 53 eingebucht wurden, die
entstandenen Anwendungsobjektnummern anzuzeigen. Zum Beispiel läßt sich ersehen,
welche IDoc-Nummer welchen Transportauftrag erstellt hat. Voraussetzung dafür ist,
daß dies von der Anwendung so vorgesehen ist.
Um diesen Report aufzurufen, wählen Sie in der Menüleiste Umfeld ® Fremdsysteme ®
Auswertungen ® Verknüpfte Objekte.

Customizing
Unter diesem Stichwort versteht SAP die notwendigen Tabelleneinstellungen, um
anwendungsseitig Entscheidungen zu treffen, wann z.B. ein Transportauftrag an ein
Fremdsystem gesendet wird etc. Ausführliche Online-Informationen hierzu finden Sie im System
im Einführungsleitfaden.

April 2001 215


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
SAP-Systemeinstellungen und Modifikationskonzept

Fehlerbearbeitung
Grundlage der Übertragung ist TCP/IP. Tritt hierbei ein Fehler auf, wird die Verbindung zwischen
Sender und Empfänger gestört. Über Return-Codes der verwendeten RFC-Funktionen erhält der
Sender die Kontrolle darüber, ob ein Aufruf funktioniert hat oder nicht. Bei TCP/IP-Fehlern muß
die Verbindung abgebaut und das IDoc erneut versendet werden.
Fehler in der ALE-Serviceschicht beim Senden bzw. Empfangen der IDocs werden als
technische Fehler bezeichnet. Beim Auftreten von technischen oder logischen Fehlern (siehe
unten) erstellt das SAP-System ein WorkItem pro fehlerhaftem IDoc. Ein WorkItem ist Teil einer
WorkFlow-Verarbeitung. Im wesentlichen ist das WorkItem eine Fehlernachricht, die an alle
Benutzer im System gesendet wird, die einer bestimmten Planstelle zugeordnet sind. Die
Fehlernachricht enthält den Fehlertext. Greift einer der Benutzer die Nachricht in seinem
Eingangskorb auf, analysiert den Fehler und bucht den Beleg nach, so verschwindet die
Fehlernachricht aus allen Eingangskörben.
Beim Empfangen wird das IDoc in der Datenbank gesichert, bevor die Verarbeitung angestoßen
wird. Damit wird die Kommunikation von der Verarbeitung entkoppelt. Tritt bei der Verarbeitung
ein Fehler auf, beispielsweise Verbuchung mit nicht zugelassener oder falscher Bewegungsart,
also ein logischer Anwendungsfehler, so erstellt das SAP-System ein WorkItem mit
entsprechendem Fehlertext.

216 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Aktivieren der Fehlerbearbeitung

Aktivieren der Fehlerbearbeitung


Tritt beim Verarbeiten eines IDocs ein logischer Fehler auf, wird eine Nachricht an einen oder
mehrere Benutzer versendet. Der folgende Text beschreibt das Einrichten dieser
Fehlerbearbeitung.
Technisch gesehen stößt das System eine nachrichtentypspezifische Standardaufgabe an. Die
Standardaufgabe muß einer Planstelle zugeordnet sein, die wiederum Benutzer bzw. Inhaber
hat.
Sie können eine oder mehrere Planstellen anlegen. Diese sind in einer zentralen
Organisationseinheit geklammert.
Nun gibt es mehrere Möglichkeiten:
1. Sie tragen die Organisationseinheit pauschal in der Partnerdefinition ein und geben keine
Spezifizierung mehr in der eigentlichen Partnervereinbarung pro Nachrichtentyp an.
Dann gehen alle Nachrichten an die der Organisationseinheit zugeordneten Benutzer, zu
deren Planstelle die auftretende Standardaufgabe gehört.
2. Sie tragen nicht die Organisationseinheit in der Partnerdefinition ein, sondern eine
bestimmte Planstelle.
3. Sie übersteuern den Eintrag in der Partnerdefinition zusätzlich mit Einträgen in der
Partnervereinbarung für einen Nachrichtentyp.
Im Normalfall kommen Sie mit Version 1 aus. Haben Sie aber zwei Fremdsysteme, die
beispielsweise zwei verschiedene Lagernummern bedienen, und sind die Sachbearbeiter der
auftretenden Fehler zwei verschiedene Lagerarbeiter, so können Sie mit Version 2 denselben
Fehler über die zwei verschiedenen Partnernummern auseinandersteuern.
Die Hierarchie wird in der folgenden Abbildung veranschaulicht:

Zuordnung von Fehlermeldungen

April 2001 217


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Aktivieren der Fehlerbearbeitung

Partnerdefinition
Partnerdefinitionfür
fürbestimmte
bestimmte
Partnernummer
Partnernummerundundlogistisches
logistischesSystem
System Organisationseinheit
Organisationseinheit
Empfänger
Empfängervon
vonBenachrichtigungen
Benachrichtigungen…

Art
Art OO Organisationseinheit
Organisationseinheit
Sprache
Sprache DD Deutsch
Deutsch
ID
ID 50005004
50005004 WM-Team
WM-Team Planstelle Planstelle
Planstelle Planstelle

Benutzer
Benutzer ...

Partnervereinbarung
Partnervereinbarungfür
für
bestimmten
bestimmtenNachrichtentyp
Nachrichtentyp Fehler
Fehler Storno-TA
Storno-TA
Fehler
Fehler Zähldaten
Zähldaten Inventur
Inventur
Empfänger
Empfängervon
vonBenachrichtigungen
Benachrichtigungen… Fehler
… Fehler Quittieren
Quittieren TA
TA
...
...
Art
Art __
__
Sprache
Sprache ___
___
ID
ID __________
__________

Das direkte Eintragen von Benutzernamen in der Partnerdefinition oder


-vereinbarung genügt nicht, da die Zuordnung zur Standardaufgabe nicht gefunden
werden kann.

Sämtliche Einstellungen sind über den Einführungsleitfaden oder direkt über die Transaktion
/nPPOM zu erreichen.
1. Zuerst muß eine Organisationseinheit definiert werden. Diese entspricht einer Wurzel,
an der viele Planstellen hängen können.
2. Legen Sie eine Planstelle an.
3. Ordnen Sie Benutzer zu.
4. Ordnen Sie die Standardaufgaben zu.

Standardaufgaben für die IDoc-Verarbeitung (technische Fehler)

Wählen Sie Anwendungsübergreifende Komponenten ® Verteilung (ALE) ® Fehlerbehandlung


einstellen ® Org.-Einheiten anlegen und Standardaufgaben zuordnen im Unternehmens-IMG.
ALE/EDI: Fehlerbearbeitung (Ausgang)
ALE/EDI: Fehlerbearbeitung (Eingang)

218 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Aktivieren der Fehlerbearbeitung

ALE/EDI: Syntaxfehler (Ausgang)


ALE/EDI: Syntaxfehler (Eingang)

Standardaufgaben für die WM-, IM-Anwendung (logische Fehler)

Wählen Sie Schnittstellen ® Fremdsysteme ® ALE-Anbindung definieren und dann OrgEinheit


und Standardaufgaben pflegen im Einführungsleitfaden (IMG) für die Lagerverwaltung.
· Fehler Storno TA
· Fehler Zähldaten Inventur
· Fehler Quittieren TA
· Fehler Warenbewegungen
· Fehler Transportaufträge
· Fehler Bewegen Lagereinheitt
· Fehler Sperren Lagerplätze
· Fehler Transportbedarf
· Information

Standardaufgaben für die SD-Anwendung (logische Fehler)

· Fehler Rückmeldung Versandelementdaten


· Fehler Rückmeldung Kommissionierung

April 2001 219


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Eingangskorb darstellen

Eingangskorb darstellen
Die Darstellung im Eingangskorb kann individuell angepaßt werden. Eine gute Einstellung, um
die Nachrichten nach IDoc-Typ geordnet anzeigen zu lassen, ist im folgenden beschrieben.

Vorgehensweise
1. Rufen Sie die Transaktion /nSIN1 auf.
2. Wählen Sie unter Einstellungen Konfiguration, und legen Sie eine neue Konfiguration
an.
3. Wählen Sie Startkonfiguration.
Damit stellen Sie sicher,daß Sie diese Konfiguration immer automatisch verwenden.
Sichern Sie.
4. Wählen Sie Einstellungen ® Gruppieren.
5. Wählen Sie aus der rechten Spalte durch Doppelklick diejenigen Felder aus, nach
welchen in der Übersichtsanzeige sortiert wird.
Sinnvoll sind: 1.„Aufgabe“ und 2. „Erstellungsdatum“.
6. Wählen Sie Einstellungen ® Spaltenauswahl.
7. Wählen Sie aus der rechten Spalte durch Doppelklick diejenigen Felder aus, die Sie in
der Detaillanzeige sehen wollen.
Sinnvoll sind: 1. „Gelesen“, 2. „Verarbeiten“, 3. „Beschreibung“, 4. „Autor“, 5.
„Eingangsdatum“, 6. „Eingangszeit“, und 7. „Status“.

220 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Fehleranalyse

Fehleranalyse

Technische Fehler in der ALE-Serviceschicht [Seite 222]

Logische Fehler in der Anwendung [Seite 225]

April 2001 221


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Technische Fehler in der ALE-Serviceschicht

Technische Fehler in der ALE-Serviceschicht


Folgende Fehler können in der ALE- Serviceschicht auftreten:
· Syntax-Fehler des IDocs
· Fehlende Partnervereinbarung
· Beim Versenden wurde das IDoc nicht an aRFC übergeben.
· Beim Empfangen wurde das IDoc nicht an die Anwendung übergeben.

Ausgang
Syntax-Fehler des IDocs: IDoc-Status ‘07’
Beim Versenden bzw. Empfangen von IDocs wird die Syntax der einzelnen IDocs geprüft. Bei
der IDoc-Definition wird die Syntax festgelegt, u.a.
· die einzelnen Segmente eines IDoc-Typs
· die Beziehung zwischen den einzelnen Segmenten
· wieviele Segmente in einem IDoc versendet werden können
Bei der Partnervereinbarung für einen IDoc-Typ und einen bestimmten Partner kann die
Syntaxprüfung des IDocs aktiviert werden. Wir empfehlen Ihnen, diese Prüfung zu aktivieren,
besonders für Ihre selbst erstellten IDocs. Dieser Fehler kommt normalerweise nur im
Testbetrieb vor. Die fehlerhaften IDocs lassen sich nicht reparieren, deswegen müssen sie
erneut versendet werden, nachdem eine Korrektur des IDoc-Aufbaus im SAP-System
vorgenommen wurde.

Fehlende bzw. falsche Partnervereinbarung: IDoc-Status ‘29’


Beim Versenden eines IDocs von SAP an das Fremdsystem muß der Ausgang der
Partnervereinbarung für den IDoc-Typ (Nachrichtentyp) und alle relevanten Partner definiert sein.
Die genaue Beschreibung der Partnervereinbarungen entnehmen Sie bitte der Online-
Dokumentation des Einführungsleitfadens (IMG). Kann für die zu versendenden IDocs der
Partner (Fremdsystem) nicht ermittelt werden, muß wie folgt verfahren werden:
· die Partnervereinbarung muß nachgepflegt werden
· alle zum Versenden anstehenden IDocs müssen zum erneuten Versenden angesteuert
werden. Da bei diesem Fehler ein WorkItem für die Standardaufgabe
‘ALE/EDI:Fehlerbearbeitung (Ausgang)’ ausgelöst und in die Eingangskörbe der
entsprechenden Benutzer gestellt wird, muß das Nachversenden des fehlerhaften IDoc
aus dem Eingangskorb angesteuert werden. Beim Nachversenden wird der fehlerhafte
IDoc mit dem Status ‘31’ gekennzeichnet und in ein neues kopiert, das mit den Daten
aus der Partnervereinbarung ergänzt und an den aRFC übergeben wird.
Fehler bei den Partnervereinbarungen kommen normalerweise nur im Testbetrieb vor.

Beim Versenden wurde das IDoc nicht an aRFC übergeben : IDoc-Status ‘30’
Obwohl die Partnervereinbarung gepflegt ist, wurde das IDoc nicht an den aRFC übergeben, d.h.
das IDoc wurde aufgebaut aber nicht versendet. Man findet auch keinen offenen Eintrag in der
RFC-Transaktionsauswertung (/nSM58) für das entsprechende Subystem. Das IDoc ist zwar
versandfertig, das Versenden des IDocs muß aber explizit angesteuert werden.

222 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Technische Fehler in der ALE-Serviceschicht

Dies erfolgt mittels des Reports RSEOUT00, der als periodischer Job eingeplant oder über das
WM-Menü Umfeld ® Fremdsysteme ® ALE-Funktionen ® Periodische Arbeiten ® Verarbeiten:
IDocs im ALE-Ausgang direkt gestartet werden kann.
Dabei sollte in der Partnervereinbarung der Ausgangsmodus für das entsprechende IDoc geprüft
werden. Bei Ausgangsmodus ‘2’ wird das erzeugte IDoc direkt versendet, bei ‘4’ werden die
IDocs gesammelt und in definierten Paketgrößen verschickt. Bei dem Modus ‘4’ ist es also
gewollt, daß die IDocs nicht direkt versendet werden.
Der Status ‘30’ im IDoc kann normalerweise nur in Verbindung mit dem Ausgangsmodus ‘4’
vorkommen.

Eingang
Syntax-Fehler des IDocs: IDoc-Status ‘60’
Wie im Ausgang kann bei der Partnervereinbarung für einen IDoc-Typ und einen bestimmten
Partner die Syntaxprüfung des IDocs aktiviert werden. Wir empfehlen Ihnen, diese Prüfung zu
aktivieren. Dieser Fehler kommt normalerweise nur im Testbetrieb vor. Die fehlerhaften IDocs
lassen sich nicht reparieren, deswegen müssen sie erneut versendet werden, nachdem eine
Korrektur des IDoc-Aufbaus im sendenden System vorgenommen wurde.

Fehlende bzw. falsche Partnervereinbarung: IDoc-Status ‘63’


Beim Empfangen eines IDocs in SAP muß die Partnervereinbarung Eingang für den IDoc-Typ
(Nachrichtentyp) und den sendenden Partner definiert sein. Die genaue Beschreibung der
Partnervereinbarungen entnehmen Sie bitte der Online-Dokumentation des
Einführungsleitfadens (IMG). Kann für die empfangenen IDocs die Partnervereinbarung und
dadurch die Eingangsmethode nicht gefunden werden, kann die Anwendung für die IDoc-
Verarbeitung nicht aktiviert werden und das IDoc bleibt im System mit Status offen stehen. Bei
diesem Fehler muß wie folgt verfahren werden:
· die Partnervereinbarung muß nachgepflegt werden
· alle offenen IDocs müssen zum Verarbeiten erneut angesteuert werden. Da bei diesem
Fehler ein WorkItem für die Standardaufgabe ‘ALE/EDI:Fehlerbearbeitung (Eingang)’
ausgelöst und in die Eingangskörbe der entsprechenden Benutzer gestellt wird, muß die
erneute Ansteuerung der Anwendung für die Verarbeitung des fehlerhaften IDocs aus
dem Eingangskorb durchgeführt werden.
Der Fehler der Partnervereinbarung kommt normalerweise nur im Test-Betrieb vor.

Beim Empfangen wurde das IDoc nicht an die Anwendung übergeben: IDoc-Status ‘64’
Obwohl die Partnervereinbarung gepflegt wurde, ist das empfangene IDoc nicht verarbeitet und
nicht als fehlerhaft gekennzeichnet, d.h. die Anwendung wurde für die Verarbeitung dieses IDocs
nicht angesteuert. Der IDoc ist zwar übergabebereit an die Anwendung, das Ansteuern der
Anwendung für die Verarbeitung des IDocs muß aber explizit vorgenommen werden.
Dies erfolgt mittels des Reports RBDAPP01, der als periodischer Job eingeplant oder über WM-
Menü Umfeld ® Fremdsysteme ® ALE-Funktionen ® Periodische Arbeiten ® Verarbeiten:
IDocs im ALE-Ausgang direkt gestartet werden kann.
Wie beim Versenden überprüfen Sie in der Partnervereinbarung die Art der Verarbeitung. Bei der
Verarbeitung ‘1’ werden die IDocs sofort nach dem Empfangen an die Anwendung zum
Verarbeiten übergeben. Bei der Verarbeitung ‘3’ und teilweise bei ‘2’ ist es gewollt, daß die
Verarbeitung nicht direkt, sondern explizit angesteuert wird.

April 2001 223


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Technische Fehler in der ALE-Serviceschicht

Der Status ‘64’ im IDoc kann normalerweise nur in Verbindung mit der Verarbeitung ‘3’ und ‘2’
vorkommen.

224 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Logische Fehler in der Anwendung

Logische Fehler in der Anwendung


Die im folgenden beschriebenen Fehler in der Anwendung beziehen sich auf den Eingang eines
IDocs in SAP. Beim Ausgang wird das zu übergebende IDoc in der Anwendung aufgebaut,
deswegen werden fehlende bzw. falsche Customizing-Einstellungen für diese Anbindung direkt
in der SAP-Abwicklung, z.B. während der Transportauftragserstellung oder Gruppenfreigabe
bemängelt.
Beim Eingang eines IDoc im SAP-System können in der Anwendung folgende Fehler auftreten:
· Fehlende bzw. fehlerhafte Customizing-Einstellungen im SAP-System
· Fehlende bzw. fehlerhafte Daten im IDoc
· Fehler durch gesperrte Objekte
· Der fehlerhafte IDoc wird mit dem Status ‘51’ gekennzeichnet.

Fehlende bzw. fehlerhafte Customizing-Einstellungen im SAP-System


Das empfangene IDoc kann im SAP-System nicht verarbeitet werden, da bestimmte Daten des
IDocs nicht im System gepflegt sind, z.B. es wird bei einer vom Fremdsystem gemeldeten
Lagerbewegung eine Bewegungsart übergeben, die im SAP-System nicht definiert ist. Bei diesen
Fehlern müssen die Customizing-Einstellungen entsprechend vorgenommen werden; danach
kann das Nachbuchen des fehlerhaften IDocs angesteuert werden. Das Nachbuchen kann
entweder aus dem Eingangskorb eines zuständigen Benutzers oder über den Report
RBDMANIN erfolgen, der als periodischer Job eingeplant oder über das WM-Menü Umfeld ®
Fremdsysteme ® ALE-Funktionen ® Periodische Arbeiten ® Verarbeitung: IDocs im ALE-
Ausgang direkt gestartet werden kann.
Das IDoc kann auch nicht verarbeitet werden, falls die IDoc-Daten nicht mit den Customizing-
Einstellungen übereinstimmen, z.B. die vom Fremdsystem gemeldete Lagerbewegung soll direkt
quittiert werden. Die Bewegungsart für diese Lagerbewegung erlaubt aber keine Sofort-
Quittierung. In diesem Fall muß zuerst die Customizing-Einstellung angepaßt werden, bevor das
Nachbuchen des fehlerhaften IDocs aus dem Eingangskorb eines zuständigen Benutzers oder
über den Report RBDMANIN angesteuert werden kann.

Fehlende bzw. fehlerhafte Daten im IDoc


Falls die Daten des empfangenen IDocs nicht vollständig sind, muß entschieden werden, ob der
fehlerhafte IDoc nochmal versendet werden muß, oder ob eine Korrektur im SAP-System
möglich bzw. sinnvoll ist. Die Korrektur kann am IDoc vorgenommen werden bzw. für bestimmte
IDocs kann das Nachbuchen im Dialog erfolgen und dadurch eine Korrektur der Daten direkt in
der SAP-Transaktion. Das Korrigieren am IDoc ist grundsätzlich über den IDoc-Editor möglich,
soll aber nur in Ausnahmefällen benutzt werden. Die Korrektur der Daten beim Nachbuchen im
Dialog ist nur beim Melden der Inventur (IDoc-WMIVID01) möglich.
Ähnlich wie bei den Fehlern in den Customizing-Einstellungen kann das fehlerhafte IDoc aus
dem Eingangskorb eines zuständigen Benutzers oder über den Report RBDMANIN nachgebucht
werden.

Fehler durch gesperrte Objekte


Oft kommt es innerhalb der SAP-Abwicklung zu Problemen mit dem Sperren der einzelnen
Objekte. Bei einem konkurrierenden Zugriff auf ein SAP-Objekt kommt es zum Abbruch der
Verarbeitung mit dem Hinweis auf das gesperrte Objekt. Dieser Fehler wird bei der IDoc-

April 2001 225


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Logische Fehler in der Anwendung

Verarbeitung wie alle anderen Fehler betrachtet. Hiefür ist seitens der Benutzer keine Aktivität
notwendig, um den Fehler zu beheben. Eine wiederholte Verarbeitung zum späteren Zeitpunkt
löst das Problem automatisch. Deswegen kann für das Nachbuchen dieser IDocs die
Hintergrundverarbeitung (periodischer Job) des Reports RBDMANIN sinnvoll eingesetzt werden.
Über den Parameter ‘Fehlerstatus’ dieses Reports läßt sich das Nachbuchen für bestimmte
Fehler mittels der Identifikation einer Fehlernachricht abgrenzen; in diesem Fall nur für die
jeweiligen Fehlernachrichten eines Sperrfehlers.

Wichtige Hinweise im Eingangskorb


Für alle beschriebene Fehler wird jeweils ein WorkItem erstellt und in die Eingangskörbe der
zuständigen Benutzer gestellt. Die WorkItems werden auch für bestimmte wichtige Hinweise
benutzt, die entweder direkt vom Fremdsystem versendet oder bei der IDoc-Verarbeitung intern
in der Anwendung aufgebaut werden. Diese Workitems dienen nicht dazu, daß aus dem
Eingangskorb die IDoc-Verarbeitung erneut angestoßen werden kann. Sie wird benutzt, um den
Benutzer über eine Konflikt Situation zu informieren oder um eine wichtige Nachricht aus dem
Fremdsystem an SAP-System weiterzuleiten. Diese Nachricht wird über den IDoc WMINID01 an
SAP übergeben. Eine interne Nachricht wird z.B. ausgelöset, falls beim Quittieren eines
Transportauftrags bzw. einer Lagereinheit diese bereits quittiert sind. D.h. das Quittieren kann
nicht mehr durchgeführt werden, es muß aber darüber jemand informiert werden, da
normalerweise diese Quittierung nur vom Fremdsystem erfolgen kann.
Das WorkItem für die Hinweise muß nicht wie bei den Fehlern aus dem Eingangskorb verarbeitet
sondern abgeschlossen werden.

226 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Modifikationskonzept

Modifikationskonzept
In diesem Abschnitt erhalten Sie einen Überblick über die User-Exits für die Schnittstelle sowie
die Veränderungsmöglichkeiten der Verarbeitung.
Eingang (Empfangen von IDocs vom Fremdsystem) [Seite 228]
Ausgang (Senden von IDocs an ein Fremdsystem) [Seite 231]
Liste der User-Exits (SAP-Erweiterungen) [Seite 233]

April 2001 227


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Eingang (Empfangen von IDocs vom Fremdsystem)

Eingang (Empfangen von IDocs vom Fremdsystem)


Verwendung
Folgende Modifikationsszenarios sind möglich:
1. Sie benutzen das Standard-IDoc, wollen aber die Verarbeitung des IDocs in eigener
Regie realisieren.
2. Sie benutzen das Standard-IDoc, wollen aber die Standard-IDoc-Verarbeitung
beeinflussen, d.h. die Fehlerbearbeitung soll modifiziert werden, oder der IDoc-Inhalt soll
kundenindividuell interpretiert werden.
3. Sie benutzen ein modifiziertes IDoc mit eigenen Segmenten und wollen für die Daten aus
diesen Segmenten eine bestimmte Verarbeitung durchführen.
4. Sie benutzen ein modifiziertes IDoc mit eigenen Segmenten und wollen die Verarbeitung
des IDocs in eigener Regie realisieren.
5. Sie benutzen ein eigenes IDoc mit einem neuen Nachrichtentyp und müssen die
Verarbeitung des IDocs in eigener Regie realisieren.
Im folgenden werden die einzelnen Modifikationsmöglichkeiten erläutert.
Nach dem Empfangen und Sichern eines IDocs wird ein Rahmenfunktionsbaustein der SAP-
Anwendung angestoßen, der die Verarbeitung eines IDocs übernimmt. Hier haben Sie die erste
Möglichkeit, einzugreifen, indem Sie einen eigenen Verarbeitungsfunktionsbaustein
erzeugen. Damit dieser auch aufgerufen wird, müssen Sie ihn in einer ALE-Customizing Tabelle
eintragen (Transaktion /nSALE : Eingang ® Steuerung ® Eingangsmethoden. Der Schlüssel
der Tabelle ist neben dem Nachrichtentyp auch Nachrichtenvariante und
Nachrichtenfunktion. Das bedeutet, Sie können auch eine zusätzliche Partnervereinbarung für
eine bestimmte Nachrichtenvariante und -funktion treffen, die Sie dem IDoc im Fremdsystem
mitgeben, um die Verarbeitung im SAP-System auseinanderzusteuern. Angebotene
Rahmenfunktionsbausteine sind standardmäßig folgenden Nachrichtentypen zugeordnet:

Rahmenfunktionsbausteine Eingang
WMBBIN L_IDOC_INPUT_WMBBIN Lagerplätze sperren
WMCATO L_IDOC_INPUT_WMCATO Storno TA
WMINFO L_IDOC_INPUT_WMINFO Information
WMINVE L_IDOC_INPUT_WMINVE Inventuraufnahmebelege
WMMBXY L_IDOC_INPUT_WMMBXY Warenbewegungen
WMSUMO L_IDOC_INPUT_WMSUMO Lagereinheit bewegen
WMTOCO L_IDOC_INPUT_WMTOCO Quittieren TA
WMTORD L_IDOC_INPUT_WMTORD_MULTIPLE Transportaufträge (TA)
WMTREQ L_IDOC_INPUT_WMTREQ Freigabe Gruppe
SDPICK SD_IDOC_INPUT_PICKING Rückmelden Liefermengen
SDPACK SD_IDOC_INPUT_PACKING Rückmelden Versandelemente
Der Rahmenfunktionsbaustein filtert die Nutzdaten pro IDoc heraus und ruft seinerseits in einer
Schleife den eigentlichen Verarbeitungsfunktionsbaustein der Anwendung auf. Jeweils vor dem
Aufruf dieses Funktionsbausteins als auch danach ist ein Customer-Exit implementiert. Den Exit
„danach“ können Sie nutzen, um eigene Fehlerstatus fortzuschreiben bzw. die gesetzten
Fehlerstatus zu ändern. Den Funktionsbaustein „davor“ können Sie nutzen, um z.B. eigene
Fortschreibungen durchzuführen oder um eigene Segmente, die Sie in der IDoc-Definition

228 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Eingang (Empfangen von IDocs vom Fremdsystem)

angehängt haben, auszuwerten. Eigene IDoc-Segmente definieren Sie in der IDoc-Pflege


(/nWE30). Bitte sehen Sie sich die entsprechende Dokumentation der ALE-Gruppe an.
Die Namen der Customer-Exits entnehmen Sie bitte dem Quellcode der
Rahmenfunktionsbausteine.
Beim Erstellen eines eigenen Funktionsbausteins und auch bei Nutzung der Customer-Exits ist
darauf zu achten, daß kein Commit Work abgesetzt wird, da der Funktionsbaustein nach
Abarbeitung zurück in die ALE-Serviceschicht verzweigt, wo auftretende Anwendungsfehler
fortgeschrieben, die IDoc-Status gesetzt und eventuell sogar Rollbacks ausgeführt werden. Nach
einem Commit Work würde ein Rollback im Fehlerfall nicht mehr durchgeführt werden können.
Damit käme es u.U. zu teilweise verbuchten IDocs und damit zu Inkonsistenzen in der
Fehlerbearbeitung.
Zu beachten ist grundsätzlich, daß weitere I/Os, die in den Customer-Exits erfolgen, die
Performance beeinträchtigen können.
Legen Sie eigene Rahmenfunktionsbausteine an, bietet das SAP-System allgemein
verwendbare Funktionsbausteine zu den verschiedenen Aufgaben an. Zum Verständnis sehen
Sie sich bitte auch die obigen Rahmenfunktionsbausteine an.

Hilfsfunktionsbausteine Eingang
L_IDOC_CONTINUE_SAVE Anwendungsobjekte für Folgeaktivitäten
zwischensichern
L_IDOC_CREATED_OBJECTS_SAVE Die aus einem IDoc erstellten Belege zwischensichern
L_IDOC_ERROR_SAVE Fehlerhafte IDocs zwischensichern
L_IDOC_INPUT_REFRESH Initialisierung für die IDoc-Verarbeitung (Tabellen-
Refresh)
L_IDOC_OK_SAVE Verarbeitete IDocs zwischensichern
L_IDOC_RETURN_CREATE Statussatz des IDocs ermitteln und aufbauen
L_IDOC_ROLLBACK_SAVE IDoc-Tabellen nach notwendigem Rollback
aktualisieren
L_IDOC_STATUS_CREATE Statussatz des IDocs ermitteln und aufbauen
L_IDOC_TIDOC_FETCH Holen der internen Tabelle zwecks
Statusfortschreibung
Genauso, wie Sie eigene Segmente pflegen, definieren Sie auch ein eigenes IDoc
(Zwischenstruktur). Dieses IDoc muß einem neuem Nachrichtentyp zugeordnet werden. Für
diesen Nachrichtentyp müssen Sie eine Partnervereinbarung treffen. Die Tabellen für den
Eingang in der Transaktion /nSALE sind zu pflegen. Für die Fehlerbearbeitung kann die
Standardaufgabe TS00008099 verwendet werden.
Bei den einzelnen Modifikationsszenarios können Sie folgende Modifikationsmöglichkeiten
nutzen:
1. Für die Verarbeitung des IDocs realisieren Sie einen eigenen
Verarbeitungsfunktionsbaustein, der aus dem Standardfunktionsbaustein des
jeweiligen Nachrichtentyps kopiert und angepaßt werden kann.
2. Sie aktivieren die Customer-Exits im Standardfunktionsbaustein. Wollen Sie die
Fehlerbearbeitung beeinflussen, müssen Sie den Customer-Exit für eigene Fehlerstatus
einschalten und realisieren. Soll die IDoc-Verarbeitung beeinflußt werden, ist der
Customer-Exit für eigene Fortschreibungen zu aktivieren und zu realisieren.

April 2001 229


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Eingang (Empfangen von IDocs vom Fremdsystem)

3. Sie definieren im Standard-IDoc eigene IDoc-Segmente und benutzen den Customer-


Exit für eigene Fortschreibungen, um die Daten aus den eigenen Segmenten zu
verarbeiten.
4. Sie definieren im Standard-IDoc eigene IDoc-Segmente und realisieren einen eigenen
Verarbeitungsfunktionsbaustein wie in Szenario 1.
5. Sie definieren ein eigenes IDoc und realisieren einen eigenen
Verarbeitungsfunktionsbaustein. Beim Erstellen des Funktionsbausteins können Sie
die Standard-Hilfsfunktionsbausteine benutzen.

230 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
Ausgang (Senden von IDocs an ein Fremdsystem)

Ausgang (Senden von IDocs an ein Fremdsystem)


Verwendung
Folgende Modifikationsszenarios sind möglich:
1. Sie benutzen das Standard-IDoc, wollen aber die Standardverarbeitung, d.h. den Aufbau
dieses IDocs, beeinflussen.
2. Sie benutzen das Standard-IDoc, wollen aber selbst bestimmen, wann und an wen eine
Tranportauftragsposition versendet werden soll, d.h. der Standard Ablauf der
Schnittstelle wird von Ihnen nicht benutzt.
3. Sie benutzen ein modifiziertes IDoc mit eigenen Segmenten und wollen eine eigene
Verarbeitung ansteuern, um die Daten dieses Segment aufzubauen.
4. Sie benutzen ein modifiziertes IDoc mit eigenen Segmenten und wollen die Verarbeitung
des IDocs, d.h. dessen Aufbau, in eigener Regie realisieren.
5. Sie benutzen ein modifiziertes IDoc mit eigenen Segmenten und wollen, wie in Szenario
2, den Standard Ablauf der Schnittstelle nicht benutzen.
6. Sie benutzen ein eigenes IDoc mit einem neuen Nachrichtentyp und müssen die
Verarbeitung des IDocs in eigener Regie realisieren.
7. Sie benutzen ein eigenes IDoc mit einem neuen Nachrichtentyp und wollen, wie in
Szenario 2, den Standard Ablauf der Schnittstelle nicht benutzen.
Im folgenden werden die einzelnen Modifikationsmöglichkeiten erläutert.
Innerhalb der Anwendung erfolgt die Vorbereitung für das Versenden von IDocs. Das IDoc wird
aufgebaut, die Partner ermittelt und die ALE-Schicht angesteuert. Der Aufbau des IDocs erfolgt
in den Anwendungsfunktionsbausteinen.
Innerhalb des WM haben Sie hier die erste Möglichkeit zu modifizieren, indem Sie einen eigenen
Funktionsbaustein erzeugen. Damit dieser auch von der Anwendung aufgerufen wird, müssen
Sie ihn in einer WM-Customizing Tabelle eintragen (siehe Customizing-Einstellung der
Schnittstelle im WM).
Zum Aufbauen und Senden von IDocs verwendet das WM folgende Funktionsbausteine:

Funktionsbausteine Ausgang
L_IDOC_CREATE_WMTOID01 Transportaufträge
L_IDOC_CREATE_WMRRID01 Freigabe Gruppe
L_IDOC_CREATE_WMCAID01 Stornoanforderung TA
L_IDOC_CREATE_WMIVID01 Inventuraufnahmebelege
Sehen Sie sich die Funktionsbausteine an. Auch hier haben Sie User-Exits zur Verfügung, um
eigene IDoc-Segmente hinzuzufügen bzw. den Standard-IDoc-Aufbau zu beeinflussen.
Soll die Standard Schnittstelle der Kopplung innerhalb des WM-Systems nicht benutzt werden,
da Sie selbst entscheiden wollen, wann eine Kopplung zum Fremdsystem erfolgen soll und an
welche Fremdsysteme die Daten versendet werden sollen, müssen sie diese Anbindung in
eigener Regie realisieren. Dabei darf die Schnittstelle im WM nicht aktiviert werden. Für die
eigene Realisierung der Anbindung können Sie den allgemeinen WM User-Exit MWMTO001
‘Erweiterungen bei Ende der TA-Erzeugung’ benutzen.

April 2001 231


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Ausgang (Senden von IDocs an ein Fremdsystem)

Eigene IDoc-Segmente definieren Sie in der IDoc-Pflege, wie beim Eingang bereits erwähnt
wurde. Auch ein kundeneigenes IDoc kann für den Ausgang definiert werden. All that is needed
here in addition to the IDoc definition is the partner profile output.
Wenn Sie aus Ihrer eigenen Anwendung heraus einen eigenen Sendefunktionsbaustein
erstellen wollen, können Sie zur Vereinfachung folgende Funktionsbausteine verwenden, die in
den SAP-Sendebausteinen bereits verwendet werden.

Hilfsfunktionsbausteine Ausgang
L_IDOC_HEADER_CREATE Aufbau der notwendigen EDIDC Daten pro IDoc
L_IDOC_SEGMENT_CREATE Aufbau eines IDoc-Segments
L_IDOC_SEND Versenden des aufgebauten IDocs
L_IDOC_FETCH Zum Zugriff der Daten in Ihrem Programm, nach dem Aufruf
Ihres IDOC_CREATE_....
Bei den einzelnen Modifikationsszenarios können Sie folgende Modifikationsmöglichkeiten
nutzen:
1. Für die Verarbeitung des IDocs realisieren Sie einen eigenen
Verarbeitungsfunktionsbaustein, der aus dem Standardfunktionsbaustein des
jeweiligen Nachrichtentyps kopiert und angepaßt werden kann.
2. Sie aktivieren den User-Exit im Standard-Funktionsbaustein, um den Standard-IDoc-
Aufbau zu beeinflussen.
3. Sie realisieren eine eigene Anbindung der Schnittstelle zwischen WM und dem
Fremdsystem.
4. Sie definieren im Standard-IDoc eigene IDoc-Segmente und benutzen den User-Exit,
um die eigenen Segmente mit Daten zu füllen.
5. Sie definieren im Standard-IDoc eigene IDoc-Segmente und realisieren einen eigenen
Funktionsbaustein, der aus dem Standard Funktionsbaustein des jeweiligen
Nachrichtentyps kopiert und angepaßt werden kann.
6. Sie definieren im Standard-IDoc eigene IDoc-Segmente und realisieren eine eigene
Anbindung der Schnittstelle zwischen WM und dem Fremdsystem.
7. Sie definieren ein eigenes IDoc und realisieren einen eigenen Funktionsbaustein.
Beim Erstellen des Funktionsbausteins können die Standard-Hilfsfunktionsbausteine
benutzt werden.
8. Sie definieren ein eigenes IDoc und realisieren eine eigene Anbindung der
Schnittstelle zwischen WM und Fremdsystem.

232 April 2001


SAP AG IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI)
SAP-Customer-Exits

SAP-Customer-Exits
Customer-Exits
Entw.kl. Erweiterung Name
MB MB_CF001 Verbuchung des Materialbeleg (Ausgang)
VL VMDE0001 Fehlerbearbeitung IDoc-Eingang für SDPICK und SDPACK
VL VMDE0002 Nachricht PICKSD (Kommissionierung, Ausgang)
VL VMDE0003 Nachricht SDPICK (Kommissionierung, Eingang)
VL VMDE0004 Nachricht SDPACK (Verpacken, Eingang)
LVS MWMIDI01 Fehlerbearbeitung bei IDoc-Eingang für IDocs: WMTOCO,
WMCATO, WMBBIN, WMTREQ, WMSUMO gemeinsam *
LVS MWMIDI02 Nachricht WMTOCO (Quittieren TA) Eingang
LVS MWMIDI03 Nachricht WMCATO (Stornieren TA) Eingang
LVS MWMIDI04 Nachricht WMBBIN (Sperren Lagerplatz) Eingang
LVS MWMIDI05 Nachricht WMTREQ (Erstellen TB) Eingang
LVS MWMIDI06 Nachricht WMSUMO (Bewegen Lagereinheit) Eingang
LVS MWMIDO07 Fehlerbearbeitung für IDoc-Eingang: MDE für IDocs:
WMMBXY, WMINVE, WMTORD gemeinsam *
LVS MWMIDO08 Nachricht WMMBXY (Warenbewegung) Eingang
LVS MWMIDO09 Nachricht WMINVE (Zähldaten Inventur) Eingang
LVS MWMIDO10 Nachricht WMTORD (Erzeugen TA) Eingang
LVS MWMIDO01 IDoc WMTOID01 (Transportauftrag) Ausgang
LVS MWMIDO02 IDoc WMCAID01 (Stornoanforderung TA) Ausgang
LVS MWMIDO03 IDocs WMRRID01 (Freigabe Gruppe)Ausgang
LVS MWMIDO04 IDocs WMIVID01 (Inventuraufnahme Beleg) Ausgang

April 2001 233


IDoc-Schnittstelle: EDI-Szenarien der Anwendung (BC-SRV-EDI) SAP AG
Senden von Belegen an ein Fremdsystem

Senden von Belegen an ein Fremdsystem


Das Versenden von Warenbewegungsbelegen an ein Fremdsystem, z.B. das Weitermelden von
Wareneingängen, wird in Release 3.0 nicht standardmäßig unterstützt. Es gibt jedoch im
Rahmen eines User-Exits eine Möglichkeit, solche Belege zu versenden. Der Name des
Bausteins ist EXIT_SAPLMBMB_001 in der Funktionsgruppe XBMG. Aufgerufen wird er über
CALL CUSTOMER FUNCTION ‘001’. Mit der Transaktion /nSMOD erhalten Sie eine Übersicht
über angebotene Customer-Funktionen, aktiviert werden sie mit der Transaktion /nCMOD. Der
Baustein wird aus der Verbuchung von Warenbewegungen aufgerufen. Er gehört zur
Entwicklungsklasse ‘MB’.

234 April 2001