Datenumsetzung bei IDocs: 3 Fallbeispiele, um viel Zeit und Entwicklungskapazität zu sparen.

Es muss ungefähr zu Beginn der 2000er Jahre gewesen sein – es war einer meiner ersten Projekte, bei dem wir in einem Energiekonzern im Ruhrgebiet SAP R/3 einführten. In der Summe waren, soweit ich mich erinnere, über 200 Berater unterwegs, um die Prozesse aufzunehmen, die Entwicklungen voranzutreiben und das System zu customizen. Meine Aufgabe bestand darin die Prozesse der Mengendisposition (Schnittstelle zwischen Verkauf und Bestandsführung) aufzunehmen und hierfür die zukünftigen Prozesse zu modellieren. Wie in jedem Projekt üblich, waren auch damals die Customizingmöglichkeiten des Systems vermeintlich nicht ausreichend, so dass ein recht großes Entwicklungsteam bereit stand, das tagtäglich mit neuen Entwicklungsanträgen (EA) „beglückt“ wurde.

Eines Tages berichtete mir eine Kollege auf eine spöttische Art: „Hast du von dem neuen EA gehört?“ Ich hatte von nichts ungewöhnlichem gehört und verneinte seine Frage. Daraufhin erzählte er mir: „Bei den Entwicklern ist eine EA eingegangen, bei dem die User die Hinweis- und Warnmeldung im SAP-GUI als Pop-Up dargestellt haben wollen“, und lachte dabei mit einer gewissen Schadenfreude. Er wusste es und auch mir war es bekannt, dass diese Meldungen damals schon mit einer Einstellung im SAP-GUI als Pop-Up-Meldung darstellbar sind, d.h. die Mühe für den EA war an dieser Stelle völlig obsolet.

Über die Jahre habe ich vielfach Entwicklungen gesehen, deren Sinn ich nicht verstand. Wenn ich nachfragte, warum hier nicht die Standardmöglichkeiten genutzt wurden, war die gängige Antwort: Das ist historisch gewachsen – wie dem auch sei. Meine Erfahrung ist, dass man im Sinne des Kunden 1-mal, 2-mal und am besten noch weitere Male hinterfragen sollte, ob eine Entwicklung tatsächlich nötig ist.

Ein super Tool, womit man sich einige Entwicklungen im IDoc-Umfeld sparen kann, ist „Datenumsetzung zwischen Sender und Empfänger“. Mit dieser Funktion können IDoc-Inhalte ohne Entwicklung manipuliert werden. Im folgende stelle ich 3 Beispiele vor, wie dieses Tool eingesetzt werden kann.

0. Grundlagen – Datenumsetzung zwischen Sender und Empfänger

Die Anlage von Umsetzregeln für die Anpassung von IDoc-Daten verläuft im Prinzip immer nach den folgenden 3 Schritten:

 

 

1. BD62 – Regel anlegen

In diesem Schritt wird mittels der Transaktion BD62 eine Regel angelegt, die Bedeutung der Regel angegeben und das Segment der Regel zugeordnet, deren Daten anzupassen sind – im Screenshot ist es das Segment E1BPDLVHDUNHDR.

© 2017 SAP SE. Alle Rechte vorbehalten

 

2. BD79 – Regel pflegen

In diesem Schritt (Transaktion BD79) spielt die Musik: Hier wird die Regel konkretisiert, d.h. hier wird eingestellt, was die Regel genau bewirken soll.

© 2017 SAP SE. Alle Rechte vorbehalten

 

3. BD55 – Regel einem Nachrichtentyp zuordnen

Im letzten Schritt muss die Regel noch einem Nachrichtentyp und einer Sender-Empfänger-Kombination zugeordnet werden:

© 2017 SAP SE. Alle Rechte vorbehalten

 

Im Folgenden will ich 3 beispielhafte Anwendungsfälle für Umsetzregeln vorstellen. Alle Bespiele basieren auf dem Szenario, dass das ERP an ein externes LVS angebunden ist. Dabei sollen in allen 3 Beispielen Daten im IDoc SHP_OBDLV_CONFIRM_DECENTRAL02 angepasst werden. Mit diesem IDoc erfolgt vom LVS-System die Kommissionierrückmeldung der Lieferung im ERP System, d.h. der Sender ist das LVS und der Empfänger ist das ERP-System.

 

# Im ersten Beispiel soll in das Feld TIMEZONE im Segmente E1BPDLVDEADLN die Konstante CET gesetzt werden

## Hintergrund: Das LVS sendet das Lieferdatum und die Uhrzeit in UTC; durch die Konstanten soll die Uhrzeit auf CET konvertiert werden

# Im zweiten Fall soll in das Feld SHIP_MAT im Segment E1BPDLVHDUNHDR der Wert 2525 gesetzt werden, wenn dieses PA enthält

## Hintergrund: Das LVS kennt die Materialnummern für die Packmittel nicht und sendet 2-stellige Kürzel. Diese sollen auf die ERP-Packmittelnummern konvertiert werden

# Im letzten Fall soll in das Feld TIMESTAMP_UTC im Segmente E1BPDLVDEADLN das aktuelle Tagesdatum gesetzt werden, wenn das Feld TIMETYPE = WSHDRLFDAT ist.

## Hintergrund: Das vom LVS ermittelte Lieferdatum ist vielfach nicht richtig, dadurch soll das Lieferdatum immer auf das Tagesdatum gesetzt werden.

Wie oben schon erwähnt, spielt die Musik beim Thema Umsetzregeln bei der Pflege der Regeln – BD79. Daher konzentriere ich mich bei der Vorstellung der Regeln auf diesen Punkt.

1. Konstante setzen – TIMEZONE = CET

# Transaktion BD62 aufrufen und neue Regel anlegen:

## Umsetzregel: ZZ_CONF_TERM
## Bedeutung: CET als Konstante
## IDoc-Segmentname: E1BPDLVDEADLN

# Transaktion BD79 aufrufen, Regel „ZZ_CONF_TERM“ vorgeben und links oben auf „Stift“ klicken

# In nächsten Screen auf das Feld „TIMEZONE“ doppelklicken

# In linken Bereich den Regeltyp „Konstante setzen“ auswählen und recht im Feld Konstante „CET“ eintragen und speichern

# Transaktion BD55 aufrufen und Nachrichtentyp „SHP_OBDLV_CONFIRM_DECENTRAL“ vorgeben

# Links oben auf den Button „Neue Einträge“ klicken und folgenden neuen Eintrag erfassen:

## Sender: LVS-System
## Empfänger: ERP-System
## Segmenttyp: E1BPDLVDEADLN
## Umsetzregel: ZZ_CONF_TERM

# Speichern

Ab jetzt ist die Regel aktiv: Damit wird das Feld TIMEZONE im Segment E1BPDLVDEADLN für den Nachrichtentyp SHP_OBDLV_CONFIRM_DECENTRAL immer mit der Konstante CET gefüllt.

2. Wert abhängig ersetzen – Wenn SHIP_MAT=PA, dann SHIP_MAT=2525 setzen

# Transaktion BD62 aufrufen und neue Regel anlegen:

## Umsetzregel: ZZ_HU_MAT
## Bedeutung: Packmittel umschlüsseln
## IDoc-Segemtname: E1BPDLVHDUNHDR

# Transaktion BD79 aufrufen, Regel „ZZ_HU_MAT“ vorgeben und links oben auf „Stift“ klicken

# Im nächsten Screen auf das Feld „SHIP_MAT“ doppelklicken

# Im linken Bereich den Regeltyp „Senderfeld umschlüsseln“ auswählen und recht im Feld Senderfeld „SHIP_MAT“ eintragen und auf den Button „Bedingungen“ klicken

# In diesen Screen in die Spalte „Wert Empfängerfeld“ „2525“ und in die Spalte „Packmittel“ „PA“ eintragen

# Ein Schritt zurück und Regel sichern

# Abschließend die Regel per Transaktion BD55 einem Nachrichtentyp und Sender-Empfänger-Kombination zuordnen

Ab jetzt ist die Regel aktiv – damit wird in das Feld „SHIP_MAT“ „2525“ eingetragen, wenn vom LVS in diesem Feld „PA“ übermittelt wird.

3. Tagesdatum setzen – TIMESTAMP_UTC = Tagesdatum

# Transaktion BD62 aufrufen und neue Regel anlegen:

## Umsetzregel: ZZ_LIEF_DAT
## Bedeutung: Lieferdatum gleich Tagesdatum
## IDoc-Segemtname: E1BPDLVDEADLN

# Transaktion BD79 aufrufen, Regel „ZZ_LIEF_DAT“ vorgeben und links oben auf „Stift“ klicken

# Im nächsten Screen auf das Feld „TIMESTAMP_UTC“ doppelklicken

# Im linken Bereich den Regeltyp „Senderfeld übernehmen“ auswählen

# Im rechten Feld Senderfeld „TIMESTAMP_UTC“ eintragen und im Feld „Spez. Konvertierungsroutine“ „DATAB“ eintragen

# Im mittleren Bereich des Screens (Bedingungen) im Feld „Senderfeld“ „TIMETYPE“ eingeben und auf den Button „Bedingungen“ klicken

# In den Details der Bedingung in der Spalte „Log. Zeitp.“ den Wert „WSHDRLFDAT“ eintragen

# Ein Schritt zurück und Regel sichern

# Abschließend die Regel per Transaktion BD55 einem Nachrichtentyp und Sender-Empfänger-Kombination zuordnen

Nun werden in das Feld TIMESTAMP_UTC das aktuelle Tagesdatum eingetragen, wenn im Feld „TIMETYPE“ der Wert „WSHDRLFDAT“ enthalten ist.

 

*** Es wäre super, wenn du ein kleines Feedback hinterlassen würdest, Isa.

6 Gedanken zu „Datenumsetzung bei IDocs: 3 Fallbeispiele, um viel Zeit und Entwicklungskapazität zu sparen.“

  1. Hi Isa,
    danke für die Erklärung. Kann das hier beschriebene als Alternative zu User Exits verwendet werden? Ich habe jetzt auch Beispiele gefunden, in denen erst Umsetzungsregeln definiert werden, diese dann aber in einem User Exit ausgestaltet werden.

    Wo ist hier der Unterschied?

    Danke und viele Grüße
    Michael

Bitte hinterlasse ein kurzes Feedback, Isa.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.