Vehicle Management System: Aktionserstellung - SAP...Version: 5.0 Datum: 26.03.2003 Autor: SAP AG...

Version: 5.0

Datum: 26.03.2003

Autor: SAP AG

Vehicle Management System: Aktionserstellung

Technische Anleitung

Aufruf, Steuerung und Erstellung von Aktionen im Vehicle Management System (VMS)

Release DIMP 4.71 (Discrete Industries & Mill Products)

Automotive 4.0 für VMS 4.0

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf

Titel: Vehicle Management System: Aktionserstellung

Version: 5.0

Datum: 26.03.2003

Seite 2 von 78

Copyright 2003 SAP AG. Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung dieses Dokuments oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch die SAP AG nicht gestattet.

Die in diesem Dokument enthaltenen Informationen können ohne vorherige Ankündigung geändert oder ergänzt werden.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 3 von 78

Inhaltsverzeichnis

1 TECHNISCHER HINTERGRUND DER AKTIONSVERARBEITUNG......................................5 1.1 DEFINITION AKTION....................................................................................................................5

1.1.1 Einfache Aktion ................................................................................................................6 1.1.2 Komplexe Aktion..............................................................................................................6 1.1.3 Verkettungsaktion............................................................................................................8

1.2 VMS-KAPSELUNGSMODELL.......................................................................................................9 1.3 ABLAUF DER AKTIONSVERARBEITUNG .....................................................................................11

1.3.1 PREPARE-Verarbeitung...............................................................................................12 1.3.1.1 Form USER_COMMAND_4000 ..............................................................................14 1.3.1.2 Funktionsbaustein VELO09_ACTION_DATA_PREPARE ...................................14 1.3.1.3 Funktionsbaustein VELO09_ACTION_DATA_PREPARE_INT...........................15 1.3.1.4 Aktionsspezifischer Baustein VELO<NN>_<ACTION>_PREPARE ...................15 1.3.1.5 Funktionsbaustein VELO09_PREPARE_VEHICLE_DATA .................................15

1.3.2 EXECUTE-Verarbeitung ...............................................................................................15 1.3.2.1 Form USER_COMMAND_4000 ..............................................................................17 1.3.2.2 Funktionsbaustein VELO09_SET_ACTION...........................................................18 1.3.2.3 Funktionsbaustein VELO09_SET_SINGLE_ACTION ..........................................19 1.3.2.4 Funktionsbaustein VELO09_SET_ACTION_INTERN ..........................................20 1.3.2.5 Aktionsspezifischer Baustein VELO<NN>_<ACTION>_EXECUTE....................20 1.3.2.6 Funktionsbaustein VELO09_WRITE_VEHICLE_DATA .......................................20

1.3.3 Ablauf von Verkettungsaktionen ..................................................................................20 1.4 FAHRZEUGTABELLE / DATENDESIGN .......................................................................................22 1.5 KOMMUNIKATIONSSTRUKTUR / DATENDESIGN.........................................................................23 1.6 GLOBALE DATENOBJEKTE IN DER AKTIONSVERARBEITUNG.....................................................25

1.6.1 Globale Variablen in der Funktionsgruppe VELO09..................................................25 1.6.2 Globale Variablen in Aktionsfunktionsgruppen ..........................................................26 1.6.3 Globale Variablen in der Funktionsgruppe VELO22..................................................28

2 ERSTELLUNG EINFACHER AKTIONEN .................................................................................29 2.1 AKTION DEFINIEREN .................................................................................................................29 2.2 TECHNISCHE ANGABEN ZUR AKTION HINTERLEGEN ................................................................29 2.3 FAHRZEUGSTATUS FESTLEGEN................................................................................................30 2.4 AKTION ZU AKTIONSMATRIZEN ZUORDNEN ..............................................................................31 2.5 FINDUNG DER AKTIONSSTEUERUNG FESTLEGEN .....................................................................31 2.6 AKTION TESTEN .......................................................................................................................31 2.7 AKTIONEN VERKETTEN .............................................................................................................32

3 ERSTELLUNG KOMPLEXER AKTIONEN ...............................................................................33 3.1 EIGENE AKTIONSFUNKTIONSGRUPPE ANLEGEN.......................................................................33 3.2 AKTIONSSPEZIFISCHEN SUBSCREEN ANLEGEN........................................................................35

3.2.1 Screenelemente/Layout ................................................................................................35 3.2.2 Ablauflogik ......................................................................................................................37

3.2.2.1 Module im Process Before Output ..........................................................................38 3.2.2.2 Module im Process After Input ................................................................................38

3.2.3 Aktionsscreen der Aktion zuordnen.............................................................................39 3.3 VERARBEITUNG KUNDENEIGENER ZUSATZDATEN EINRICHTEN ................................................40

3.3.1 Kundeneigene Zusatzdaten als Fahrzeugattribute verarbeiten................................40 3.3.1.1 Struktur VLCACTDATA erweitern ...........................................................................40

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 4 von 78

3.3.1.2 Fahrzeugattribute der Aktion zuordnen ..................................................................41 3.3.2 Kundeneigene Zusatzdaten als Qualifier verarbeiten ...............................................42

3.3.2.1 Qualifier definieren....................................................................................................42 3.3.2.2 Qualifier der Aktion zuordnen ..................................................................................42

3.3.3 Qualifier versus Fahrzeugattribute ..............................................................................43 3.4 EIGENEN PREPARE-BAUSTEIN ANLEGEN UND AUFRUFEN ....................................................44

3.4.1 Namenskonvention........................................................................................................44 3.4.2 Dokumentation...............................................................................................................44 3.4.3 Schnittstelle ....................................................................................................................45 3.4.4 Quelltext..........................................................................................................................47

3.4.4.1 Datendeklarationen...................................................................................................47 3.4.4.2 Prüfungen ..................................................................................................................49

3.4.4.2.1 Lesen/Prüfen des Vorgängerbelegs .................................................................49 3.4.4.2.2 Bedingte Prüfungen ............................................................................................51

3.4.4.3 Füllen der Kommunikationsstruktur ........................................................................52 3.4.4.3.1 Kopfdaten.............................................................................................................52 3.4.4.3.2 Positionsdaten .....................................................................................................53

3.4.4.4 Festlegen der Vorlagekonfiguration ........................................................................54 3.4.5 Aufruf ..............................................................................................................................55

3.5 EIGENEN EXECUTE-BAUSTEIN ANLEGEN UND AUFRUFEN.....................................................56 3.5.1 Namenskonvention........................................................................................................56 3.5.2 Dokumentation...............................................................................................................56 3.5.3 Schnittstelle ....................................................................................................................57 3.5.4 Quelltext..........................................................................................................................59

3.5.4.1 Datendeklarationen...................................................................................................59 3.5.4.2 Prüfungen ..................................................................................................................60

3.5.4.2.1 Lesen/Prüfen des Vorgängerbelegs .................................................................60 3.5.4.2.2 Aufruf des PREPARE-Bausteins.......................................................................63

3.5.4.3 Anlegen/Ändern/Löschen von SAP-Standardbelegen..........................................64 3.5.4.4 Fortschreiben der VMS-Belegtabelle......................................................................66 3.5.4.5 Verbuchung ...............................................................................................................67 3.5.4.6 Schreiben der Fahrzeugdaten .................................................................................68 3.5.4.7 Füllen der Kommunikationsstruktur ........................................................................69

3.5.4.7.1 Kopfdaten.............................................................................................................69 3.5.4.7.2 Positionsdaten .....................................................................................................70

3.5.5 Aufruf ..............................................................................................................................71 3.6 ABSPRUNG AUS DER FAHRZEUGHISTORIE IN BELEG EINRICHTEN ...........................................72

4 ANHANG .......................................................................................................................................73 4.1 TABELLEN IM VMS...................................................................................................................73

4.1.1 Bewegungsdaten ...........................................................................................................73 4.1.2 Stammdaten ...................................................................................................................74 4.1.3 Customizing-Tabellen ...................................................................................................74 4.1.4 Steuertabellen................................................................................................................76

4.2 RICHTLINIEN BEI DER ENTWICKLUNG DES VMS ......................................................................76

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 5 von 78

1 Technischer Hintergrund der Aktionsverarbeitung

1.1 Definition Aktion

Eine Aktion ist ein betriebswirtschaftlicher Vorgang, der sich auf Geschäftsprozesse beim Handling von Fahrzeugen bezieht, zum Beispiel Fahrzeug anlegen, Fahrzeug ändern, Bestellung anlegen, Kundenauftrag anlegen.

Ein Fahrzeug hat zwei Status, den Primär- und den Sekundärstatus. Der Fahrzeugstatus ändert sich automatisch in Abhängigkeit von der durchgeführten Aktion. Eine Aktion kann den Primär- und/oder den Sekundärstatus setzen.

In einer Aktionsmatrix, die im Customizing definiert wird, sind die betriebswirtschaftlichen Prozesse als Aktions- und Statusfolgen festgelegt. Ein Eintrag in der Aktionsmatrix definiert, welche Aktion bei welchem aktuellen Fahrzeugstatus erlaubt ist und welcher neue Statuswert gesetzt wird, wenn die Aktion erfolgreich durchgeführt wurde. Einem Fahrzeug wird im Vehicle Management System eine Primär- und eine Sekundärmatrix zugeordnet, um die Statusfolgen von Primär- und Sekundärstatus zu steuern.

Aktionen werden im Customizing als Primär- und/oder Sekundäraktionen gekennzeichnet. Die Begriffe Primär- und Sekundäraktion sind dabei als gleichwertig zu betrachten; sie drücken keine Hierarchie aus. Was für den jeweiligen Anwender Primär- beziehungsweise Sekundäraktionen sind, hängt von seinen individuellen Geschäftsprozessen ab. Mögliche Aufteilungen sind: Einkaufsaktionen versus Verkaufsaktionen oder logistische Aktionen (Aktionen, die das Fahrzeug selbst betreffen) versus Finanzaktionen (Aktionen, die den Zahlungsverkehr betreffen).

Wenn Sie im Vehicle Management System eine Aktion durchführen, werden unabhängig von der gewählten Aktion bestimmte generelle Prüfungen und Funktionen durchlaufen. Beispiele sind: Es wird geprüft ob die angeforderte Aktion beim aktuellen Fahrzeugstatus erlaubt ist; es werden Fahrzeugzusatzdaten (Attribute, Qualifier) geschrieben; bei erfolgreicher Durchführung der Aktion wird ein neuer Fahrzeugstatus gesetzt; es wird ein Eintrag in die Fahrzeughistorie geschrieben. Wenn Sie eigene Aktionen entwickeln und in das Vehicle Management System einbinden möchten, ist das Wissen um diese Abläufe von Nutzen.

Weiterhin benötigen viele Aktionen Dateneingaben (zum Beispiel Aktion CREA), damit sie durchgeführt werden können. In diesem Fall wird die Aktion gestartet, es werden Daten eingegeben, und diese Daten werden dann verarbeitet. Diese Interaktion erfordert es, dass wichtige Prüfungen und Funktionen mehrfach durchlaufen werden. Auch das müssen Sie bei der Entwicklung von kundeneigenen Aktionen berücksichtigen.

Ziel dieser Dokumentation ist es, die technischen Abläufe beim Aufruf und der Ausführung von Aktionen zu erläutern. Darüber hinaus wird auf das Coding der relevanten Funktionsbausteine und Programme eingegangen.

Grundsätzlich wird zwischen einfachen und komplexen Aktionen unterschieden.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 6 von 78

1.1.1 Einfache Aktion

Einfache Aktionen sind Aktionen, die nur durch Einstellungen im VMS-Customizing erzeugt werden. Im VMS-Customizing wird die neue Aktion angelegt und in die Statusfolge einer Aktionsmatrix integriert (siehe 2).

Solche Aktionen haben nur ein Status-Update und einen Eintrag in der Fahrzeughistorie zur Folge.

Die einfachen Aktionen haben keine aktionsspezifischen Repository-Objekte und erfordern deswegen keine Entwicklung. Als Aktionsscreen wird automatisch ein Standardscreen verwendet, der abgesehen von der Drucktaste Aktion ausführen keine Elemente enthält.

1.1.2 Komplexe Aktion

Eine komplexe Aktion besteht in der Regel aus einem spezifischen Aktionsscreen, dessen PBO- und PAI-Modulen sowie aus einem PREPARE- und einem EXECUTE-Funktionsbaustein. Die Kommunikationsschnittstellen sind fest definiert und können gegebenenfalls kundenspezifisch erweitert werden.

Komplexe Aktionen sind somit Aktionen, die eigenes Coding beziehungsweise eigene Subscreens besitzen. Sie geben Ihnen die Möglichkeit, Aktionen mit eigener Logik zu programmieren (siehe 3), die die unterschiedlichsten Aufgaben erfüllen können.

Eine komplexe Aktion hat in der Regel folgende drei Bestandteile, die jeweils aktionsspezifisch sind:

Action Subscreen

Function ModuleAction preparation

Function ModuleAction execution

• Aktionsscreen: Ein eigener Subscreen (optional), der auf der Registerkarte Aktion rechts neben der Fahrzeugliste eingeblendet wird. Es ist fast immer ausreichend, ausschließlich die im VMS-Standard mitgelieferten PA-I und PBO-Module dafür zu verwenden.

• EXECUTE-Baustein: In der Regel gibt es einen Funktionsbaustein (VELO<NN>_<ACTION>_EXECUTE), der für die eigentliche Aktionsausführung verantwortlich ist. Dieser Baustein legt zum Beispiel einen R/3-Standardbeleg durch Aufrufen eines BAPIs an.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 7 von 78

Wenn Sie lediglich Daten von der Kommunikationsstruktur (siehe 1.5) beziehungsweise dem Aktionsscreen in die Fahrzeug- und/oder Historientabelle schreiben möchten, so benötigen Sie keinen eigenen EXECUTE-Baustein, sondern müssen lediglich in der IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen einige Einstellungen machen (siehe 3.3.1).

• PREPARE-Baustein: Optional kann es einen Baustein geben (VELO<NN>_<ACTION>_PREPARE), der direkt nach Auswahl der Aktion aufgerufen wird. Er kann unter anderem dazu dienen, aktionsspezifische Prüfungen zu machen und den Aktionsscreen mit Vorschlagswerten zu füllen.

Die Übergabe von Daten zwischen dem Aktionsscreen und der Aktionsverarbeitung wird durch eine definierte Kommunikationsstruktur ermöglicht. Auf den Aktionsscreens dürfen Sie nur Felder dieser Struktur verwenden. Sie können die Struktur mit der Append-Technik kundenspezifisch erweitern. Der Aufbau und die Erweiterungsmöglichkeit dieser Struktur wird weiter unten (siehe 1.5) genauer beschrieben.

Die Grafik zeigt den Ablauf einer komplexen Aktion in der Transaktion VELO:

• Falls zu der Aktion ein PREPARE-Baustein existiert, wird dieser zunächst aufgerufen. Hier werden aktionsspezifische Prüfungen durchgeführt und Daten für den Aktionsscreen vorbereitet. Die Daten werden in die Kommunikationsstruktur VLCACTDATA_CS gestellt.

• Anschließend wird - falls vorhanden - ein aktionsspezifischer Screen dargestellt. Dieser Screen enthält die für die Aktion benötigten Felder der Kommunikationsstruktur VLCACTDATA_CS. Der Benutzer nimmt Eingaben in diesen Feldern vor und wählt anschließend die Drucktaste Aktion ausführen.

• Nun wird die eigentliche Aktionsverarbeitung durchgeführt; das heißt der EXECUTE-Baustein wird aufgerufen. Für alle Fahrzeuge, die in der internen Tabelle VLCDIAVEHI_CT übergeben werden, wird die Aktion mit den Daten der Kommunikationsstruktur durchgeführt. Hier könnte zum Beispiel nach einigen Prüfungen ein BAPI aufgerufen werden, das einen SAP-Standardbeleg anlegt.

Action Subscreen

Function ModuleAction preparation

Function ModuleAction execution

Nx

Nx

VLCACTDATA_S

VLCDIAVEHI_T

VLCACTDATA_S

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 8 von 78

Man kann im VMS-Customizing Verkettungsaktionen definieren (siehe 2.7), also Aktionen, bei denen mehrere Elementaraktionen automatisch nacheinander ausgeführt werden. Bei diesen Verkettungsaktionen werden zunächst alle relevanten PREPARE-Bausteine nacheinander verarbeitet, anschließend wird ein gemeinsamer Aktionsscreen dargestellt, und nachdem der Benutzer die Daten eingegeben und Aktion ausführen gewählt hat, werden alle relevanten EXECUTE-Bausteine verarbeitet.

Es ist möglich, VMS-Aktionen nicht über die Transaktion VELO aufzurufen, sondern über BAPIs; die IDOC-Schnittstelle oder auch das Web-Interface nutzen beispielsweise diese Technik. Wenn Aktionen über ein VMS-BAPI ausgeführt werden, werden nur die EXECUTE-Bausteine durchlaufen. Daher müssen die in den PREPARE-Bausteinen implementierten Prüfungen in den EXECUTE-Bausteinen ebenfalls durchgeführt werden. Anders ausgedrückt:

Eine Aktion muss durch ihren EXECUTE-Baustein logisch und betriebswirtschaftlich vollständig beschrieben sein !

Aus Gründen der Bedienerfreundlichkeit sollten Sie auf wichtige Prüfungen in den PREPARE-Bausteinen jedoch nicht verzichten. So wird der Benutzer in der Transaktion VELO bereits so früh wie nur möglich, nämlich beim Aufruf einer Aktion, also zum PREPARE-Zeitpunkt, zum Beispiel darauf hingewiesen, dass eine Aktion nicht ausgeführt werden kann.

1.1.3 Verkettungsaktion

Aktion, die aus zwei oder mehreren miteinander verketteten Elementaraktionen besteht. Eine Verkettungsaktion wird in der IMG-Aktivität Aktionen festlegen definiert (siehe 2.7). Die Elementaraktionen können einfache oder komplexe Aktionen sein.

Beim Start der Verkettungsaktion werden automatisch alle enthaltenen Elementaraktionen in der angegebenen Reihenfolge ausgeführt. Jede Elementaraktion wird dabei vom System als vollständige Aktion verarbeitet, inklusive Setzen eines neuen Status und Verbuchung.

Beim Ausführen einer Verkettungsaktion werden die Elementaraktionen nacheinander durchgeführt und separat verbucht; das heißt jede Elementaraktion wird als eigenständige LUW (logical unit of work) behandelt.

Das Verketten von Aktionen erfordert kein eigenes Coding. Wenn jedoch die einzelnen Elementaraktionen jeweils unterschiedliche Eingabefelder benötigen, müssen Sie einen neuen Aktionsscreen anlegen, der alle diese Felder beinhaltet, und diesen in der IMG-Aktivität Technische Angaben zu Aktionen hinterlegen der Verkettungsaktion zuordnen.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 9 von 78

1.2 VMS-Kapselungsmodell

Die Funktionalität des VMS (Paket ISAUTO_VLC) ist thematisch in mehrere Funktionsgruppen aufgeteilt. Es gibt eine saubere Trennung von Präsentations-, Anwendungs- und Datenbankfunktionalitäten. Wegen der Platzierung des VMS als selbstständiges und flexibles Modul wurden alle Objekte vollständig gekapselt.

VMS-Internet-Oberfläche

(VELO01)

Anwendungslogik

(VELO03)

Schnittstelle zum IPC

(VELO07)

SD-Aktionen

(VELO11)

Fahrzeugsuche

(VELO13)

MM-Aktionen

(VELO10)

Business-Partner

(VELO12)

Schnittstelle zum TREX

(VELO08)

VMS-R/3-Oberfläche

(VELO02)

DB-Tabellenverwaltung

(VELO04)

Stammdatenpflege

(VELO06)

Customizing

(VELO05)


(VELO14)

CS-Aktionen

(VEO16)

VMS-Aktionen

(VELO15)

LE-Aktionen

(VELO17)

BAPI-Funktionsbausteine

(VEO19)

Schnittstelle extern

(VELO18)

VMS-Flag

(VELO22)

liveCache (obsolet)

(VELO24)

Category Management

(VELO23)


(VELO25)

Verkaufsbelege/Fahrzeug

(VELO27)

Funktionsgruppe für BW

(VELO26)

Status- und Aktionsverwaltung (VELO09)

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 10 von 78

Zu den Aktionsfunktionsgruppen gehören unter anderem die fünf rot markierten Gruppen, denen die Aktionen thematisch zugeordnet sind: VELO10, VELO11, VELO15, VELO16, VELO17.

Die VELO15 hat unter den Aktionsfunktionsgruppen eine besondere Bedeutung, da diese sozusagen die Ur-Aktionsfunktionsgruppe ist. In der VELO15 sind zum Beispiel die PAI- und PBO-Module definiert, die für die Aktionsscreens benötigt werden. Alle anderen Aktionsfunktionsgruppen inkludieren lediglich diese Module (siehe 3.1).

Von zentraler Bedeutung ist die Funktionsgruppe VELO09; hier ist das allgemeine Aktionshandling implementiert.

Die VMS-R/3-Oberfläche des VMS und die für die Interaktion mit dem Benutzer nötige Ablauflogik ist in der Funktionsgruppe VELO02 hinterlegt. In dieser Funktionsgruppe ist das Unterprogramm USER_COMMAND _4000 von zentraler Bedeutung (siehe unten); dort werden die Funktionscodes verarbeitet, zum Beispiel der Funktionscode zum Ausführen einer Aktion, durch den die Funktionsbausteine für die PREPARE- beziehungsweise EXECUTE-Verarbeitung aufgerufen werden.

Die Funktionsgruppe VELO02 enthält das generelle VMS-Konstanten-Include LVELO02CON.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 11 von 78

1.3 Ablauf der Aktionsverarbeitung

Nachfolgend werden die generellen technischen Abläufe bei Aufruf und Ausführung von Aktionen erläutert. Anschließend wird auf den Ablauf des ABAP-Codings der einzelnen Objekte eingegangen, und die wichtigsten logischen Schritte werden vorgestellt.

Abbildung 5 1. Aufruf einer Aktion

2. Rückkehr zur VELO und Anzeige des Aktionsscreens

3. Eingaben des Benutzers auf dem Aktionsscreen

4. Ausführen der Aktion

5. Rückkehr zur VELO und Anzeige des Aktionsscreens

VELO – Transaktions-oberfläche

Aktions-Subscreen

1PAI-Screen 4000/VELO02

User_Command_4000

2

3

4

User_Command_4000

PBO-Module PBO-Module

- Prüfung, ob Aktion für ausgewählte Fahrzeuge erlaubt

- Initialisieren globaler Daten für die Aktionsverarbeitung

- Aufruf der PREPARE-Verarbeitung

- Gegebenenfalls Ausgabe einer Fehlermeldung

- Aktivieren der Registerkarte Aktion

- Aufbau der Fahrzeugliste auf der Registerkarte Aktion

- Bestimmen des Aktionsscreens

- Aufruf des Aktionsscreens

- ...

- Aktualisieren der Fahrzeugliste auf der Registerkarte Aktion

- Bestimmen des Aktionsscreens

- Aufruf des Aktionsscreens

- ...

- Anlegen eines Aktionsprotokolls

- Bereitstellen wichtiger Datenobjekte

- Aufruf der EXECUTE-Verarbeitung

- Schreiben des Aktionsprotokolls

- Aktualisieren wichtiger Datenobjekte der VELO

5

PBO-Screen 5000/VELO02

• Beim Aufruf einer Aktion in der Transaktion VELO (Aktion auswählen und grünen Haken drücken, Funktionscode ACTN), wird im PAI des Screens 4000 (VELO-Trägerdynpro; Funktionsgruppe VELO02) das Unterprogramm USER_COMMAND_4000 durchlaufen. Dort wird die PREPARE-Verarbeitung aufgerufen und die Registerkarte Aktion aktiviert.

• Anschließend wird im PBO des Screens 5000 (Registerkarte Aktion) die Liste der zu verarbeitenden Fahrzeuge aufgebaut sowie der Aktionsscreen bestimmt und aufgerufen; dabei werden die PBO-Module des aktionsspezifischen Subscreens durchlaufen.

• Nach eventueller Dateneingabe und Ausführen der Aktion (Drucktaste Aktion ausführen, Funktionscode AKTN) wird erneut das PAI des Screens 4000 und damit das Unterprogramm USER_COMMAND_4000 durchlaufen; dort wird nun die EXECUTE-Verarbeitung aufgerufen und das Aktionsprotokoll geschrieben.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 12 von 78

• Abschließend wird im PBO-Zeitpunkt des Screens 5000 (Registerkarte Aktion) die Fahrzeugliste angepasst (Erfolgs-LEDs, Datenänderungen) und der Aktionsscreen erneut aufgerufen. Auf dem Aktionsscreen werden Daten (zum Beispiel Nummer des angelegten Belegs) angezeigt. Außerdem kann der Benutzer das Aktionsprotokoll aufrufen.

1.3.1 PREPARE-Verarbeitung

Die generelle und aktionsspezifische PREPARE-Verarbeitung hat die Aufgabe, bereits beim Aufruf einer Aktion wichtige Prüfungen durchzuführen und Daten für den Aktionsscreen und die weitere Verarbeitung aufzubereiten.

Bei der Aktionsausführung über ein VMS-BAPI wird die PREPARE-Verarbeitung nicht aufgerufen; sie ist also nur bei der Aktionsausführung aus der Transaktion VELO heraus relevant.

Eine Aktion muss nicht zwingend einen PREPARE-Baustein besitzen.

Die folgende Abbildung zeigt, welche Bausteine im Rahmen der PREPARE-Verarbeitung aufgerufen werden. Diese generelle Abfolge ist für alle Aktionen gleich; wenn eine Aktion keinen eigenen PREPARE-Baustein hat, entfällt lediglich der Aufruf des entsprechenden Bausteins.

USER_COMMAND_4000

Internal Tableaction_lt

Loop at action_ltVELO09_ACTION_DATA_PREPARE

VELO09_ACTION_DATA_PREPARE_INT

VELONN_<ACTION>_PREPARE(Aktionsspezifischer PREPARE-Baustein)

VELO09_PREPARE_VEHICLE_DATABadI: VLC_PREPARE_ACTIONMethode: PREPARE_FURTHER_ACTIONS

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 13 von 78

Das Unterprogramm USER_COMMAND_4000 ruft beim Funktionscode ACTN (Aufruf einer Aktion) die PREPARE-Verarbeitung, also den Baustein VELO09_ACTION_DATA_PREPARE auf. Dieser Baustein wiederum ruft für jede auszuführende Aktion (bei Verkettungsaktionen können dies mehrere sein) einzeln den Baustein VELO09_ACTION_DATA_PREPARE_INT auf; dieser startet folgende Funktionen:

• falls vorhanden, den aktionsspezifischen PREPARE-Baustein

• die Methode PREPARE_FURTHER_ACTION des BAdIs VLC_PREPARE_ACTION; in diesem BAdI werden die kundenspezifischen PREPARE-Bausteine aufgerufen (siehe 3.4.5)

• den Baustein VELO09_PREPARE_VEHICLE_DATA. Wenn im Customizing (IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen; Details siehe 3.3) definiert wurde, dass eine Aktion Zusatzdaten (Attribute oder Qualifier) verarbeiten soll, werden hier die im Customizing definierten Zusatzdaten aufbereitet.

Folgende Abbildung zeigt den Datenfluss in der PREPARE-Verarbeitung:

VLCDIAVEHI_T VLCACTDATA_S XINTERLINKED_V

VE

LO

09_A

CT

ION

_DA

TA

_PR

EP

AR

E_I

NT

VE

LO

<NN

>_<A

CT

ION

>_P

RE

PA

RE

Action SubscreenVLCACTDATA_S

Vehicle data (selected vehicles)

VehicleDatabase

Die PREPARE-Verarbeitung erhält die Information, welche Aktion für welche Fahrzeuge (VLCDIAVEHI_T) ausgeführt werden soll. Es werden Daten aufbereitet, von der Datenbank gelesen und geprüft. Wenn ein Fehler auftritt, wird die Verarbeitung sofort mit der passenden Fehlermeldung abgebrochen. Die aufbereiteten Daten werden in die Kommunikationsstruktur VLCACTDATA_S gestellt und auf dem Aktionsscreen dargestellt.

Auf einem Aktionsscreen dürfen nur Felder der Kommunikationsstruktur VLCACTDATA_S dargestellt werden.

Nach eventueller Dateneingabe und Ausführen der Aktion (Drucktaste Aktion ausführen, Funktionscode AKTN) wird die Kommunikationsstruktur und die Fahrzeugtabelle an die EXECUTE-Verarbeitung (siehe 1.3.2) übergeben.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 14 von 78

1.3.1.1 Form USER_COMMAND_4000

Das Modul USER_COMMAND_4000 ist innerhalb der Transaktion VELO (Funktionsgruppe VELO02) das steuernde PAI-Modul. Hier werden vom Benutzer gewählte Funktionscodes ausgewertet, und die weitere Verarbeitung wird eingeleitet.

Aufgaben des PAI-Moduls in Bezug auf den PREPARE-Zeitpunkt (Funktionscode ACTN):

• Prüfung auf Existenz der Aktion / Auslesen der Texte zur Aktion in der Anmeldesprache

• Prüfung, ob die Aktion für die selektierten Fahrzeuge erlaubt ist

• Setzen und Initialisieren einiger globaler Daten (siehe 1.6.1) in der VELO09 (gewählte Aktion setzen, Kommunikationsstruktur VLCACTDATA_CS initialisieren, Fahrzeugliste übertragen)

• Aufruf der PREPARE-Verarbeitung: VELO09_ACTION_DATA_PREPARE

• Meldung, ob die Aktion erfolgreich ausgeführt werden kann

• Setzen der LEDs in der Fahrzeugliste

• Setzen des Parameters BEFORE_AFTER_GV in der VELO09; gibt an, ob sich die Verarbeitung vor oder nach der Aktion befindet. Dieser Parameter wird in einem generellen PBO-Modul der Aktionsscreens ausgewertet, um Feldattribute (zum Beispiel Eingabebereitschaft; siehe 3.2.2.1) zu steuern.

• Setzen der Variable CONFIGURE_BUTTON_GV gemäß den Einstellungen im Aktionscustomizing (siehe 2.2); gibt an ob eine Konfigurieren-Drucktaste auf dem Aktionsscreen gebraucht wird. Diese Variable wird in einem generellen PBO-Modul der Aktionsscreens ausgewertet (siehe 3.2.2.1).

• Wenn im Aktionscustomizing (siehe 2.2) das Kennzeichen Konfiguration sofort starten gesetzt ist, wird hier die Konfiguration gelesen und dargestellt, bevor der Aktionsscreen prozessiert wird.

Die Konfiguration kann in der CU50- oder der IPC-Oberfläche dargestellt werden. Normalerweise wird die IPC-Oberfläche verwendet; wenn man den Benutzerparameter VELO_CU50_ACTIVE = ‚X’ setzt, wird die CU50-Oberfläche verwendet.

1.3.1.2 Funktionsbaustein VELO09_ACTION_DATA_PREPARE

Dieser Funktionsbaustein führt einige generelle Prüfungen durch und ruft implizit die aktionsspezifische PREPARE-Verarbeitung auf. Einzelne Aufgabenschritte sind:

• Lesen einiger globaler Daten (siehe 1.6.1) aus der VELO09 (Kommunikationsstruktur VLCACTDATA_CS und Liste der zu verarbeitenden Fahrzeuge)


• Füllen der internen Tabelle ACTION_LT mit den auszuführenden Aktionen; bei einer Verkettungsaktion können dies mehrere sein

• Prüfung, ob der Benutzer berechtigt ist, die Aktion(en) durchzuführen

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 15 von 78

• In einer Schleifenverarbeitung über die interne Tabelle ACTION_LT wird für jede auszuführende Aktion der Funktionsbaustein VELO09_ACTION_DATA_PREPARE_INT separat aufgerufen.

1.3.1.3 Funktionsbaustein VELO09_ACTION_DATA_PREPARE_INT

• Aufruf des PREPARE-Bausteins der jeweiligen Aktion. Dabei wird mit Hilfe einer CASE-Anweisung die auszuführende Aktion abgefragt und der hart im Coding zugeordnete PREPARE-Baustein aufgerufen.

• Einige PREPARE-Bausteine liefern die Schlüssel von Vorlagekonfigurationen in der Tabelle VLCGUIDCUOBJ_LT zurück (siehe 3.4.4.4). Die Konfigurationen werden hier gelesen, damit sie später an der Oberfläche dargestellt werden können.

Die PREPARE-Verarbeitung von kundeneigenen Aktionen wird in der Methode PREPARE_FURTHER_ACTIONS des BAdIs VLC_PREPARE_ACTION aufgerufen (siehe 3.4.5).

• Aufruf des Bausteins VELO09_PREPARE_VEHICLE_DATA

1.3.1.4 Aktionsspezifischer Baustein VELO<NN>_<ACTION>_PREPARE Detaillierte Beschreibung: siehe 3.4

1.3.1.5 Funktionsbaustein VELO09_PREPARE_VEHICLE_DATA

Wenn in der IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen Einstellungen vorgenommen wurden, übernimmt dieser Baustein das Lesen/Aufbereiten der Qualifierdaten und/oder der Fahrzeugattribute (siehe 3.3).

Dieser Baustein ist sozusagen ein mit Hilfe des Customizings aktionsspezifisch einstellbarer PREPARE-Baustein.

1.3.2 EXECUTE-Verarbeitung

Die EXECUTE-Verarbeitung stellt die eigentliche Aktionsausführung dar. Erst hier wird der betriebswirtschaftliche Vorgang tatsächlich durchgeführt, indem Fahrzeugdaten, Belegdaten oder andere Daten in die Datenbank geschrieben werden.

Die EXECUTE-Verarbeitung wird gestartet, wenn der Benutzer auf dem Aktionsscreen – falls nötig – Daten eingegeben und Aktion ausführen gewählt hat. Sie kann aber auch gestartet werden, wenn ein VMS-BAPI aufgerufen wird, beispielsweise über die IDoc-Schnittstelle oder das Web-Interface.

Wenn Aktionen über ein VMS-BAPI ausgeführt werden, werden nur die EXECUTE-Bausteine durchlaufen. Daher müssen die in den PREPARE-Bausteinen implementierten Prüfungen in den EXECUTE-Bausteinen ebenfalls durchgeführt werden. Anders ausgedrückt:

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 16 von 78


Die folgende Abbildung zeigt, welche Bausteine im Rahmen der EXECUTE-Verarbeitung aufgerufen werden. Diese generelle Abfolge ist für alle Aktionen gleich. Die Aufgaben der einzelnen Bausteine werden unten erläutert.

USER_COMMAND_4000

Internal Tableaction_lt

Loop at action_ltVELO09_SET_ACTION

VELO09_SET_SINGLE_ACTION

VELONN_<ACTION>_EXECUTE(Aktionsspezifischer EXECUTE-Baustein)

VELO09_WRITE_VEHICLE_DATABadI: VLC_EXECUTE_ACTION

Methode: EXECUTE_FURTHER_ACTIONS

VELO09_SET_ACTION_INTERN

Eine besondere Bedeutung hat der Funktionsbaustein VELO09_SET_ACTION – auch Aktionshandler genannt. Dies ist der zentrale Baustein zum Ausführen von VMS-Aktionen; er wird sowohl von der Transaktion VELO als auch von den VMS-BAPIs aufgerufen.

Das Unterprogramm USER_COMMAND_4000 ruft beim Aktionscode AKTN (Aktion ausführen) die EXECUTE-Verarbeitung, das heißt den Baustein VELO09_SET_ACTION auf. Dieser Baustein wiederum ruft für jede auszuführende Aktion (bei Verkettungsaktionen können dies mehrere sein) einzeln den Baustein VELO09_SET_SINGLE_ACTION auf. Anschließend wird der Baustein VELO09_SET_ACTION_INTERN aufgerufen; dieser startet folgende Funktionen:

• falls vorhanden, den aktionsspezifischen EXECUTE-Baustein

• die Methode EXECUTE_FURTHER_ACTION des BAdIs VLC_EXECUTE_ACTION; in diesem BAdI werden die kundenspezifischen EXECUTE-Bausteine aufgerufen (siehe 3.5.5)

• den Baustein VELO09_WRITE_VEHICLE_DATA. Wenn im Customizing (IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen; Details siehe 3.3) definiert wurde, dass eine Aktion Zusatzdaten (Attribute oder Qualifier) verarbeiten soll, werden hier die im Customizing definierten Zusatzdaten aus der Kommunikationsstruktur VLCACTDATA_CS in die Fahrzeugdaten geschrieben.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 17 von 78

Die folgende Abbildung zeigt den Datenfluss in der EXECUTE-Verarbeitung:

VE

LO

09_S

ET

_AC

TIO

N_I

NT

ER

N

VE

LO

<NN

>_<A

CT

ION

>_E

XE

CU

TE

Action Subscreen

VLCDIAVEHI_TVLCACTDATA_S

Action Log

VehicleVehicleDatabaseDatabase

VLCACTDATA_S

VLCH_MSSG_T

VLCDIAVEHI_T VLCACTDATA_S

Die EXECUTE-Verarbeitung erhält die aufbereiteten Daten vom PREPARE-Baustein beziehungsweise die vom Benutzer auf dem Aktionsscreen eingegebenen Daten (VLCACTDATA_S) und die Liste der zu verarbeitenden Fahrzeuge (VLCDIAVEHI_T). Während der Ausführung der Aktion werden Meldungen (Fehler, Warnungen , Erfolgsmeldungen) in einer Message-Tabelle gesammelt und in das Aktionsprotokoll (SAP-Reuse-Komponente: Application Log) geschrieben. Änderungen auf der Datenbank werden verbucht, Belege angelegt und Ergebnisse auf dem Aktionsscreen angezeigt.

1.3.2.1 Form USER_COMMAND_4000

Das Modul USER_COMMAND_4000 hat bei der Aktionsausführung (Funktionscode AKTN) unter anderem die Aufgabe, die EXECUTE-Verarbeitung aufzurufen. Im Einzelnen übernimmt es folgende Aufgaben:

• Anlegen eines Aktionsprotokolls (Baustein VELO03_BAL_LOG_CREATE, Reuse-Komponente)

• Füllen der Fahrzeugtabelle VLCDIAVEHI_LT: die Fahrzeuge, die aktuell in der Fahrzeugliste der Registerkarte Aktion stehen, sind in der internen Tabelle VLCDISPLALV_ACTION_GT aufgelistet; das Original der Fahrzeugdaten steht in der globalen Tabelle VLCDISPLALV_ ACTION_GT

• Übertragen der Kommunikationsstruktur VLCACTDATA_CS aus den globalen Daten der Funktionsgruppe VELO09 (siehe 1.6.1); damit sind alle Daten bekannt, die von den PREPARE-Bausteinen und/oder den Aktionsscreens geliefert werden

• Aufruf des Aktionshandlers (Baustein: VELO09_SET_ACTION); es wird unter anderem die Fahrzeugtabelle VLCDIAVEHI_LT und die Kommunikationsstruktur VLCACTDATA_CS übergeben

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 18 von 78

• Übergabe der vom Aktionshandler zurückgegebenen Meldungen (Fehler, Warnungen, Erfolgsmeldungen) an das Aktionsprotokoll.; gegebenenfalls Speichern des Protokolls auf der Datenbank (wird durch Benutzerparameter VELO_ACTPROTOCOL gesteuert)

• Aktualisieren einiger globaler (Fahrzeug-)Tabellen und Strukturen

• Ausgeben einer generellen Fehler- beziehungsweise Erfolgsmeldung

• Übertragen der Kommunikationsstruktur VLCACTDATA_CS an die VELO09, damit die Aktionsscreens die aktualisierten Daten anzeigen können

1.3.2.2 Funktionsbaustein VELO09_SET_ACTION

Dieser Funktionsbaustein – auch Aktionshandler genannt – ist der zentrale Baustein zum Ausführen von VMS-Aktionen. Er wird sowohl von der Transaktion VELO als auch von den VMS-BAPIs aufgerufen. Es werden folgende Schritte durchgeführt:

• Setzen des globalen VMS-Kennzeichens in der Funktionsgruppe VELO22 (siehe 1.6.3). Dieses Kennzeichen kann zum Beispiel in einem Customer-Exit einer R/3-Standardfunktion abgefragt werden, um zu entscheiden, ob die Funktion vom VMS aufgerufen wurde.


• Prüfen, ob der Benutzer berechtigt ist, die Aktion(en) durchzuführen

• Füllen der internen Tabelle ACTION_LT mit den auszuführenden Aktionen; bei Verkettungsaktionen können dies mehrere sein

• Fahrzeuge initial erzeugen, wenn eine Aktion zum Anlegen von Fahrzeugen aufgerufen wird

• Pro Fahrzeug wird so vorgegangen:

• Es wird geprüft, ob der Benutzer berechtigt ist, eine Aktion für das Werk durchzuführen.

• Das Fahrzeug wird für andere Benutzer gesperrt.

• Es wird ein Read-Before-Write-Check durchgeführt. Dazu werden die an der Oberfläche angezeigten Daten mit den aktuellen Daten in der Datenbank verglichen. Wenn es Abweichungen gibt, weil ein anderer Benutzer in der Zwischenzeit eine Aktion für das Fahrzeug ausgeführt hat, wird ein Fehler ausgelöst.

• Falls die Aktion eine Verkettungsaktion ist, wird hier geprüft, ob sie aufgrund des aktuellen Fahrzeugstatus erlaubt ist.

Je nachdem, ob Fehler auftreten, werden die einzelnen Fahrzeuge auf die beiden internen Tabellen VLCDIAVEHI_NO_LT und VLCDIAVEHI_OK_LT verteilt. Es werden nur die Fahrzeuge weiterverarbeitet, die in der OK-Tabelle stehen.

• Alles Folgende wird für jede Aktion, die in der internen Tabelle ACTION_LT steht, separat durchgeführt:

• Pro Fahrzeug aus der OK-Tabelle wird so vorgegangen:

• Es wird geprüft, ob die Aktion beim aktuellen Fahrzeugstatus erlaubt ist.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 19 von 78

• Prüfungen, die im BAdI VLC_EXECUTE_ACTION implementiert sind, werden ausgeführt.

Je nachdem, ob Fehler auftreten, werden Fahrzeuge aus der OK-Tabelle in die NO-Tabelle geschrieben. Die Fahrzeuge der NO-Tabelle werden als fehlerhaft gekennzeichnet und werden nicht weiterverarbeitet.

Es werden im Folgenden nur die Fahrzeuge der OK-Tabelle weiterverarbeitet.

• Spezialfall: Wenn die Aktion im Customizing als Vereinzelungsaktion gekennzeichnet ist (/SE16; Tabelle CVLC03; Feld ISOLTN = X), dann werden die folgenden Schritte nicht ausgeführt, sondern nur noch die Methode VEHICLE_ISOLATION des BAdIs VLC_EXECUTE_ACTION. Es gibt in Kundenprojekten bereits Lösungen für die Implementierung.

Fahrzeugvereinzelung bedeutet, dass der EXECUTE-Baustein der Aktion für jedes Fahrzeug einzeln aufgerufen wird. Führt man zum Beispiel die Bestellaktion für 10 Fahrzeuge im Vereinzelungsmodus durch, so wird automatisch pro Fahrzeug eine Bestellung angelegt. Möglicherweise werden 8 Bestellungen erfolgreich und 2 nicht angelegt.

• Aufruf des Bausteins VELO09_SET_SINGLE_ACTION; es werden unter anderem alle Fahrzeuge der OK-Tabelle VLCDIAVEHI_OK_LT und die Daten der Kommunikationsstruktur VLCACTDATA_CS übergeben.

• Wenn die Aktion erfolgreich durchgeführt wurde, wird nun der COMMIT abgesetzt. Eine Variable COMMIT_LV (beziehungsweise Importparameter COMMIT_IV) entscheidet, ob synchron oder asynchron verbucht wird.

Entsprechend den Default-Einstellungen werden Aktionen asynchron verbucht. Eine Ausnahme bilden die Verkettungsaktionen. Hier wird aus Sicherheits-gründen nach jeder einzelnen Elementaraktion synchron (COMMIT WORK AND WAIT) verbucht. Wenn Sie von dieser Regel abweichen möchten, können Sie das BAdI VLC_EXECUTE_ACTION implementieren (Methode COMMIT_MODE).

• Erzeugung von Erfolgsmeldungen

• Aktualisieren der Exportparameter

• Im Fehlerfall wird der ROLLBACK ausgelöst, Fehlermeldungen werden erzeugt, die Exportparameter angepasst und die Fahrzeuge entsperrt.

• Ende der Schleife über die Aktionstabelle ACTION_LT

• Entsperren aller Fahrzeuge

1.3.2.3 Funktionsbaustein VELO09_SET_SINGLE_ACTION

Dieser Baustein bekommt unter anderem eine Fahrzeugtabelle (OK-Tabelle), die Kommunikationsstruktur und ein Aktionskürzel übergeben und führt nun die wesentlichen Schritte der Aktion aus:

• Aufruf von BAdIs zum kundenspezifischen Ändern der Daten vor der Aktionsausführung (BAdI VLC_EXECUTE_ACTION, Methode DATA_CHANGES_BEFORE_ACTION)

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 20 von 78

• Aufruf des Bausteins VELO09_SET_ACTION_INTERN; dieser ruft seinerseits die aktionsspezifischen EXECUTE-Bausteine auf

• Aufruf von BAdIs zum kundenspezifischen Ändern der Daten nach der Aktionsausführung (BAdI VLC_EXECUTE_ACTION, Methode DATA_CHANGES_AFTER_ACTION)

• Aktualisieren des Fahrzeugstandorts, der Verfügbarkeit und des geplanten Lieferdatums in den Fahrzeugdaten (IMG-Aktivität Aktionssteuerung und Aktionsmatrizen festlegen).

• Aktualisieren des Fahrzeugstatus in den Fahrzeugdaten

• Aktualisieren der Fahrzeughistorie

1.3.2.4 Funktionsbaustein VELO09_SET_ACTION_INTERN

• Aufruf des EXECUTE-Bausteins der jeweiligen Aktion. Dabei wird mit Hilfe einer CASE-Anweisung die auszuführende Aktion abgefragt und der hart im Coding zugeordnete EXECUTE-Baustein aufgerufen.

• Kundenspezifische Aktionen und Bausteine werden in der Methode EXECUTE_FURTHER_ ACTIONS des BAdIs VLC_EXECUTE_ACTION aufgerufen (siehe 3.5.5).

Die EXECUTE-Bausteine von kundenspezifischen Aktionen werden in der Methode EXECUTE_FURTHER_ACTIONS des BAdIs VLC_EXECUTE_ACTION aufgerufen.

• Aufruf des Bausteins VELO09_WRITE_VEHICLE_DATA

1.3.2.5 Aktionsspezifischer Baustein VELO<NN>_<ACTION>_EXECUTE Detaillierte Beschreibung: siehe 3.5

1.3.2.6 Funktionsbaustein VELO09_WRITE_VEHICLE_DATA

Wenn in der IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen Einstellungen vorgenommen wurden, übernimmt dieser Baustein die Verarbeitung der Qualifierdaten und/oder der Fahrzeugattribute (siehe 3.3).

Dieser Baustein ist sozusagen ein mit Hilfe des Customizings aktionsspezifisch einstellbarer EXECUTE-Baustein.

1.3.3 Ablauf von Verkettungsaktionen

Beim Start der Verkettungsaktion werden automatisch alle enthaltenen Elementaraktionen in der angegebenen Reihenfolge ausgeführt. Jede Elementaraktion wird dabei vom System als vollständige Aktion verarbeitet, inklusive Setzen eines neuen Status und Verbuchung.

Das Verketten von Aktionen erfordert kein eigenes Coding. Wenn jedoch die einzelnen Elementaraktionen jeweils unterschiedliche Eingabefelder benötigen, müssen Sie einen neuen Aktionsscreen anlegen, der alle diese Felder beinhaltet, und diesen in der IMG-Aktivität Technische Angaben zu Aktionen hinterlegen (siehe 2.2) der Verkettungsaktion zuordnen.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 21 von 78

Bei Ausführung einer Verkettungsaktion wird der Subscreen prozessiert, der im Customizing der Verkettungsaktion zugeordnet ist; die Screens der Elementaraktionen werden nicht berücksichtigt.

Bei Verkettungsaktionen werden, wie oben bereits gesehen, die PREPARE- und EXECUTE-Bausteine nacheinander abgearbeitet.

Bei Ausführung einer Verkettungsaktion werden in der PREPARE-Verarbeitung die PREPARE-Bausteine aller Elementaraktionen nacheinander ausgeführt; in der EXECUTE-Verarbeitung werden alle relevanten EXECUTE-Bausteine nacheinander ausgeführt.

Beispiel: Werden zwei Aktionen A1 und A2, bestehend aus jeweils einem PREPARE-Baustein (P1 und P2), einem EXECUTE-Baustein (E1 und E2) und einem Subscreen (S1 und S2) zu einer Verkettungsaktion A3 mit eigenem Subscreen S3 verkettet, dann werden die Bestandteile der Verkettungsaktion A3 in folgender Reihenfolge durchlaufen: P1 à P2 à S3 à E1 à E2. Die Subscreens S1 und S2 werden für A3 nicht benötigt.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 22 von 78

1.4 Fahrzeugtabelle / Datendesign

Hier werden nur die wichtigsten VMS-Tabellen vorgestellt; es muss aber darauf hingewiesen werden, dass Verknüpfungen zu weiteren SAP-Standardtabellen (Beispiel: Konfiguration, Charge, Bewertungsart, Equipment, ...) bestehen.

• Fahrzeugtabelle VLCVEHICLE

Dies ist die zentrale Fahrzeugtabelle; sie enthält steuernde und beschreibende Attribute. Die Include-Struktur VLCADDVDATA fasst die beschreibenden Fahrzeugattribute zusammen; diese Struktur kann um kundenspezifische Felder erweitert werden (siehe 3.3.1).

• Qualifierdaten zum Fahrzeug VLCADDDATA

Für beschreibende Fahrzeugdaten können im Customizing Qualifier definiert werden (siehe 3.3.2), beispielsweise Nummernschild, Achslast, Motorleistung. Diese Qualifier werden mit definiertem Fahrzeugbezug in dieser Tabelle gespeichert.

• Fahrzeughistorie VLCHISTORY

In der Fahrzeughistorie wird jede durchgeführte Aktion mit Zeitstempel, Statusübergang und weiteren Daten gespeichert. Diese Struktur kann ebenfalls um kundenspezifische Felder erweitert werden (siehe 3.3.1.1).

• VMS-Belegtabellen (zum Beispiel VLCCUORDER; siehe 3.5.4.4)

Aus dem VMS werden eine Vielzahl von SAP-Standardbelegen angelegt; für jeden Belegtyp gibt es eine VMS-Belegtabelle, in der die Verknüpfung von Fahrzeug und Belegnummer/Position gespeichert wird.

• Zusätzliche Fahrzeugkonfigurationen (VLCADDCFG)

Ein Fahrzeug hat genau eine Fahrzeugkonfiguration; diese wird durch ein Feld in der Fahrzeugtabelle (VLCVEHICLE-CUOBJ) repräsentiert. Neben der Fahrzeugkonfiguration kann ein Fahrzeug zusätzliche Fahrzeugkonfigurationen haben; diese werden in der Tabelle VLCADDCFG gespeichert.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 23 von 78

1.5 Kommunikationsstruktur / Datendesign

Wie bereits dargestellt, ist die Kommunikationsstruktur VLCACTDATA_CS verantwortlich für den Datentransport von der PREPARE-Verarbeitung zum Aktionsscreen und von dort weiter zur EXECUTE-Verarbeitung.

Auf den Aktionsscreens dürfen nur Felder der VLCACTDATA_CS verwendet werden.

Die VLCACTDATA ist folgendermaßen strukturiert:

VLCACTDATA

VLCACTDATA_HEAD_S

VLCACTDATA_ITEM_TVLCADDDATA_ITEM_T

VLCACTDATA_MM_ITEM_SVLCACTDATA_SD_ITEM_SVLCACTDATA_LE_ITEM_SVLCACTDATA_SM_ITEM_SVLCACTDATA_VMS_ITEM_S

Structure ofheader data

Table ofitem data

Table ofadditionaldata (qualifiers)

• Kopfdaten (Struktur VLCACTDATA_HEAD_S)

Daten, die für alle an der Aktion beteiligten Fahrzeuge gelten. Beispiel: Wird ein Kundenauftrag für drei Fahrzeuge angelegt, so ist der Auftraggeber ein Kopfdatum.

Die Struktur VLCACTDATA_HEAD_S gliedert sich auf in weitere Unterstrukturen (siehe Abbildung; analog zur ITEM-Struktur), in denen die Fahrzeugattribute thematisch sortiert sind.

Kundenspezifische Felder sollten stets in eine der Unterstrukturen aufgenommen werden. Eventuell ist es auch sinnvoll, eine neue Struktur in die VLCACTDATA_HEAD_S zu inkludieren.

• Positionsdaten (Tabellentyp VLCACTDATA_ITEM_T; Feld ADDDATA_ITEM)

Daten, die bei der Aktionsausführung nur für genau ein Fahrzeug gelten. Beispiel: Wird die Aktion SMOD Fahrzeug ändern für mehrere Fahrzeuge gleichzeitig durchgeführt, so wird zum Beispiel auf dem Aktionsscreen die Fahrzeugidentifikationsnummer nur für das aktuell ausgewählte Fahrzeug angezeigt.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 24 von 78

Wenn die Struktur VLCACTDATA_ITEM_S erweitert werden muss, gelten dieselben Regeln wie bei der VLCACTDATA_HEAD_S.

• Qualifierdaten (Tabellentyp VLCADDDATA_ITEM_T; Feld ACTDATA_ITEM)

Daten, die im Customizing frei definiert werden können (siehe 3.3.2) und die bei der Aktionsausführung ebenso wie die Positionsdaten nur für genau ein Fahrzeug gelten. Qualifier werden, im Gegensatz zu den Positionsdaten, auf einem Aktionsscreen als ALV-Liste dargestellt; außerdem werden sie auf der Datenbank in die separate Tabelle VLCADDDATA geschrieben, belasten also nicht die zentrale Fahrzeugtabelle.

Da Qualifier im Customizing frei definiert werden können, sind keine Strukturerweiterungen nötig.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 25 von 78

1.6 Globale Datenobjekte in der Aktionsverarbeitung

Für die Aktionsverarbeitung in der Transaktion VELO werden einige globale Datenobjekte verwendet. Diese dienen hauptsächlich dazu, den Datentransport zwischen verschiedenen Funktionsgruppen und vor allem zwischen einer Vielzahl von Screens (Transaktion VELO, Aktionsscreens etc.) zu gewährleisten.

Bei der Implementierung des VMS wurde die Anzahl der globalen Variablen so gering wie möglich gehalten. Nur die Funktionsgruppe VELO02 (Transaktion VELO) hat eine Vielzahl globaler Variablen; diese werden dort wegen der vielen Screens benötigt. Die Aktionsfunktionsgruppen, beispielsweise VELO15, haben nur einige wenige klar definierte globale Datenobjekte, die hauptsächlich für die Aktionsscreens benötigt werden. Weiterhin hat die Funktionsgruppe VELO09 (Status- und Aktionsverwaltung) einige wenige globale Datenobjekte, die insbesondere für den Datentransfer zwischen den Funktionsgruppen benötigt werden.

In den VMS-BAPIs beziehungsweise im Funktionsbaustein VELO09_SET_ACTION werden keinerlei globale Datenobjekte verwendet. Anders ausgedrückt: Alle Daten werden über die Bausteinschnittstelle übergeben. Gleiches gilt für sämtliche aktionsspezifischen EXECUTE- und PREPARE-Bausteine.

Im Folgenden werden die globalen Datenobjekte der Funktionsgruppen VELO09, VELO22 und der Aktionsfunktionsgruppen erläutert.

1.6.1 Globale Variablen in der Funktionsgruppe VELO09

Dies ist die Funktionsgruppe, in der die generelle Status- und Aktionsverwaltung implementiert ist. Die globalen Daten in dieser Funktionsgruppe werden für den Datentransfer zwischen der Funktionsgruppe VELO02 (Transaktion VELO) und den verschiedenen Aktionsfunktionsgruppen benötigt. Eine Ausnahme stellt VLCACTDATA_GS dar.

• VLCACTDATA_GS

Struktur mit aktionsspezifischen Daten. Diese wird durch die Felder auf dem Aktionsscreen oder durch die Bausteine VELO<NN>_<ACTION>_PREPARE gefüllt. Die in der Struktur vorhandenen Informationen werden von den Bausteinen VELONN_<ACTION>_ EXECUTE benötigt, um beispielsweise einen R/3-Standardbeleg anlegen zu können. Außerdem werden Rückgabedaten der Aktion, beispielsweise die Nummer des erzeugten Belegs, mit dieser Struktur zum Aktionssubscreen zurückübertragen.

• SELECTED_VEHICLE_GV

Interne Nummer (GUID) des auf der Oberfläche ausgewählten Fahrzeugs. Diese Variable wird benötigt, um bei Aktionen, die Positionsdaten besitzen, die zum ausgewählten Fahrzeug gehörenden Positionsdaten auf dem Aktionssubscreen anzeigen zu können.

• LIST_OF_VEHICLES_GT

Liste der Fahrzeuge (entspricht der VLCDIAVEHI), die für die Aktion ausgewählt wurden. Die Liste enthält unter anderem die Daten der Fahrzeuge aus der Tabelle VLCVEHICLE.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 26 von 78

• CONFIGURE_BUTTON_GV

Diese Variable enthält die Information, ob auf dem Aktionssubscreen die Konfigurieren-Drucktaste vorhanden sein soll.

• SELECTED_ACTION_GV

Vierstelliges Kürzel für die ausgewählte Aktion.

• BEFORE_AFTER_GV

Variable zur Steuerung der Ein-/Ausgabefelder und der Drucktasten auf dem Aktionssubscreen. Die Variable enthält die Information für den Aktionssubscreen, ob die Aktion noch ausgeführt werden soll oder schon ausgeführt wurde.

Weitere Informationen sind im Include LVELO09TOP ersichtlich.

1.6.2 Globale Variablen in Aktionsfunktionsgruppen

Es gibt einige klar definierte globale Datenobjekte, die in allen Aktionsfunktionsgruppen deklariert werden. Das TOP-Include beginnt bei allen Aktionsfunktionsgruppen mit folgenden Zeilen:

FUNCTION-POOL VELOXX MESSAGE-ID VELO. *======================================================================= * Vehicle Management System Type Pool TYPE-POOLS: VLCH, * IBase Type Pool IBXX. * The Include LVELO02CON contains all constants that are used in the * Vehicle Management System. INCLUDE LVELO02CON. * The Include LVELO15ACT contains declarations that are needed in all * function groups in that actions are implemented. INCLUDE LVELO15ACT. *=======================================================================

Das LVELO02CON ist ein zentrales Konstanten-Include, in dem (fast) alle im VMS verwendeten Konstanten definiert sind. Dieses Include liegt in der VELO02 und wird in weiteren Funktionsgruppen inkludiert.

Es gibt eine Auswahl von globalen Datenobjekten, die grundsätzlich in allen Aktionsfunktionsgruppen verwendet werden können. Diese sind im Include LVELO15ACT zusammengefasst. Dieses Include liegt in der VELO15 und wird in sämtlichen Aktionsfunktionsgruppen inkludiert.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 27 von 78

Im Folgenden werden die globalen Variablen des Includes LVELO15ACT erläutert:

• ACTIONTEXT_GV

Kurztext (sprachabhängig) der Aktionsbezeichnung. Dieser wird aus dem Customizing gezogen und als Text im Rahmen auf dem Aktionsscreen dargestellt.

• VLCACTDATA_HEAD_S

Daten, die für alle an der Aktion beteiligten Fahrzeuge gelten. Es handelt sich in der Regel um Kopfdaten der Belege, die durch die Aktionen angelegt werden sollen. Die Struktur ist Bestandteil der VLCACTDATA und enthält Felder für alle Aktionen.

• VLCACTDATA_ITEM_S

Wird nur für Aktionen, die mit Positionsdaten an der Oberfläche arbeiten, benötigt und enthält eine Zeile der Tabelle VLCACTDATA_ITEM_GT mit den Positionsdaten des aktuell ausgewählten Fahrzeugs.

• VLCACTDATA_SUBITEM_S

Wird nur für Aktionen, die mit Unterpositionsdaten an der Oberfläche arbeiten, benötigt. Das heißt, es wird mit Positionsdaten gearbeitet, aber diese Daten sind teilweise keine flache Struktur, sondern müssen als Tabellen beziehungsweise ALV dargestellt werden Die Struktur stellt eine Zeile der Tabelle VLCACTDATA_SUBITEM_GT dar und enthält einen Unterpositionsdatensatz des aktuell ausgewählten Fahrzeugs.

• VLCACTDATA_ITEM_GT

Wird nur für Aktionen, die mit Positionsdaten an der Oberfläche arbeiten, benötigt und enthält die Positionsdaten aller an der Aktion beteiligten Fahrzeuge. Die Tabelle ist Bestandteil der VLCACTDATA.

• VLCADDDATA_ITEM_GT

Wird nur für Aktionen benötigt, die mit Zusatzdaten (Qualifier) arbeiten, und enthält die Zusatzdaten aller an der Aktion beteiligten Fahrzeuge.

• VLCADDDATA_VHCL_GT

Wird nur für Aktionen benötigt, die mit Zusatzdaten (Qualifier) arbeiten, und enthält die Zusatzdaten des momentan ausgewählten Fahrzeugs.

• VLCACTDATA_SUBITEM_GT

Wird nur für Aktionen benötigt, die mit Unterpositionsdaten arbeiten, und enthält alle Unterpositionsdaten aller an der Aktion beteiligten Fahrzeuge.

• VLCACTDATA_VEHICLE_SUBITEM_GT

Wird nur für Aktionen benötigt, die mit Unterpositionsdaten arbeiten, und enthält Unterpositionsdaten des momentan ausgewählten Fahrzeugs. Da es verschiedenartige Unterpositionsdaten für ein Fahrzeug geben kann, werden bis zu fünf globale Tabellen für diese Daten zur Verfügung gestellt.

• CONTAINER_ADDDATA_GO; ALV_CONTROL_ADDDATA_GO

Wird nur für Aktionen benötigt, die mit Zusatzdaten (Qualifier) arbeiten. Die Qualifier werden auf dem Aktionsscreen als ALV dargestellt. Die Variablen sind die Objektreferenzvariablen für den Container und das ALV-Control.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 28 von 78

• VLC_SUBITEM_CONTAINER_1_GO, VLC_SUBITEM_GRID_1_GO

Wird nur für Aktionen benötigt, die mit Unterpositionsdaten arbeiten. Die Unterpositionsdaten werden auf dem Aktionsscreen als ALV dargestellt. Die Variablen sind die Objektreferenzvariablen für den Container und das ALV-Control. Da es verschiedenartige Unterpositionsdaten für ein Fahrzeug geben kann, werden diese beiden Variablen bis zu fünfmal zur Verfügung gestellt.

• VLC_HTML_CONTAINER_GO; VLC_HTML_CONTROL_GO

Wird nur für Aktionen benötigt, die ein HTML-Control auf einem Aktionsscreen verwenden. Die Variablen sind die Objektreferenzvariablen für den Container und das HTML-Control.

Weitere Informationen sind im Include LVELO15ACT ersichtlich. In diesem Include sind sämtliche globalen Variablen der Aktionsfunktionsgruppen deklariert. Das Include wird von allen Aktionsfunktionsgruppen verwendet.

1.6.3 Globale Variablen in der Funktionsgruppe VELO22

FUNCTION-POOL VELO22. * This flag may only be set / read by the function modules VELO22_SET_ * VMS_FLAG and VELO22_GET_VMS_FLAG. The GET-function module can be * called by R/3-standard documents to check whether the standard * document is called by the Vehicle Management System or not. Depending * on this information Modifications that are included in standard * documents can be activated. DATA: VMS_FLAG_GV TYPE XFLAG. DATA: LIST_OF_VEHICLES_GT TYPE VLCDIAVEHI_T.

• VMS_FLAG_GV

Das VMS-Kennzeichen wird automatisch vom Aktionshandler (VELO09_SET_ ACTION) gesetzt. Dieses Kennzeichen kann mit dem Baustein VELO22_GET_VMS_ FLAG gelesen werden.

Verwendung: Wenn Sie für Ihr spezielles VMS-Szenario einen Customer-Exit einer SAP-Standardfunktionalität mit Logik füllen, können Sie das VMS-Kennzeichen dort auswerten, um in einem IF-Statement zu entscheiden, ob das Coding des Customer-Exits durchlaufen werden soll.

• LIST_OF_VEHICLES_GT

Diese Fahrzeugliste kann mit den Bausteinen VELO22_GET_LIST_OF_VEHICLES und VELO22_SET_LIST_OF_VEHICLES gesetzt und gelesen werden.

Verwendung: Sie können zum Beispiel in einem Customer-Exit einer SAP-Standardfunktionalität, die durch einen EXECUTE-Baustein vom VMS aufgerufen wird, die Liste der zu verarbeitenden Fahrzeuge abfragen. Sie müssen allerdings zuvor im EXECUTE-Baustein mit dem SET-Baustein die Liste setzen.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 29 von 78

2 Erstellung einfacher Aktionen

Einfache Aktionen werden ausschließlich mit Hilfe des Customizings erstellt und setzen keine Kenntnisse der ABAP-Programmierung voraus.

2.1 Aktion definieren

Führen Sie in der IMG-Aktivität Aktionen festlegen (Transaktion OVELO1) folgende Schritte aus:

1. Legen Sie für jede Aktion einen Schlüssel (vierstellig) und eine Bezeichnung fest.

2. Legen Sie fest, ob die Aktion eine interne Aktion sein soll.

Interne Aktionen werden nicht in der Transaktion VELO angeboten, können aber weiterhin über die VMS-BAPIs (IDoc-Schnittstelle, Web-Interface etc.) durchgeführt werden.

3. Legen Sie fest, ob die Aktion eine Primäraktion oder eine Sekundäraktion sein soll.

Eine Primäraktion ist eine Aktion der primären Aktionssteuerung, eine Sekundäraktion eine Aktion der sekundären Aktionssteuerung. Vor Ausführung der Aktion prüft das System stets die Aktionsmatrix der primären bzw. sekundären Aktionssteuerung, um zu entscheiden, ob aufgrund der Fahrzeugstatus diese Aktion erlaubt ist.

4. Legen Sie fest, ob die Aktion SCEM-relevant sein soll.

Die SCEM-Relevanz bestimmt, ob die ausgeführte Aktion einen Event Handler im SCEM (Supply Chain Event Management) anlegen soll beziehungsweise die Info-Parameter eines bestehenden Event Handlers ändern soll.

2.2 Technische Angaben zur Aktion hinterlegen

Führen Sie in der IMG-Aktivität Technische Angaben zur Aktion hinterlegen (Transaktion OVELO6) folgende Schritte aus:

1. Legen Sie fest, ob der Anwender beim Durchführen einer Aktion die Möglichkeit haben soll zu konfigurieren. Es gibt folgende Möglichkeiten:

• Der Anwender muss konfigurieren: Die Konfiguration wird sofort ohne Aufforderung gestartet, das heißt beim Aufruf der Aktion erscheint direkt der IPC (Internet Pricing and Configuration).

• Der Anwender darf nicht konfigurieren: Die Drucktaste zum Aufruf der Konfiguration wird ausgeblendet.

• Der Anwender kann konfigurieren: Die Drucktaste zum Aufruf der Konfiguration wird eingeblendet.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 30 von 78

2. Legen Sie fest, ob die Aktion eine Anlegen-Aktion sein soll, also, eventuell in Kombination mit anderen betriebswirtschaftlichen Funktionen, Fahrzeuge anlegen soll.

In der Transaktion VELO werden auf dem Bild der Fahrzeugsuche nur die markierten Aktionen, also nur Aktionen zum Anlegen von neuen Fahrzeugen angeboten, da andere Aktionen an dieser Stelle nicht sinnvoll sind.

Im Funktionsbaustein VELO09_SET_ACTION wird aufgrund dieses Kennzeichens entschieden (siehe 1.3.2.2), ob Fahrzeuge initial angelegt werden.

3. Geben Sie das Programm an, in dem sich der Aktionsscreen befindet, und die Dynpronummer des Aktionsscreens.

4. Geben Sie eine Aliasaktion an.

Über die Aliasaktion kann für kundeneigene Aktionen festgelegt werden, welche VMS Standardaktion ausgeführt werden soll, wenn die kundeneigene Aktion ausgewählt wird.

Eine Nutzung einfacher Aktionen zum Konfigurieren wird nicht empfohlen. Bei einfachen Aktionen dürfen Sie das Kennzeichen Anlegen-Aktion nicht setzen. Die Felder Aktionsprogramm und Aktionsdynpro müssen ebenfalls leer bleiben, da einfache Aktionen keine eigenen Subscreens verwenden.

2.3 Fahrzeugstatus festlegen

Hier werden die Fahrzeugstatus festgelegt, die ein Fahrzeug in seinem Leben annehmen kann.

Der Fahrzeugstatus ändert sich automatisch in Abhängigkeit von der durchgeführten Aktion. Man unterscheidet zwischen Primär- und Sekundärstatus, je nachdem, ob sich der Status auf Primär- oder Sekundäraktionen bezieht.

Legen Sie in der IMG-Aktivität Fahrzeugstatus festlegen (Transaktion OVELO12) für jeden Status einen Schlüssel und eine Bezeichnung fest.

Sie können auch mit Asterisken als Wildcards arbeiten und damit einen ganzen Bereich von Fahrzeugstatus beschreiben. Das ist dann sinnvoll, wenn Sie in der Aktionsmatrix ausdrücken wollen, dass eine Aktion nicht nur an einer bestimmten Stelle im Prozess, sondern an einer beliebigen Stelle innerhalb eines ganzen Bereichs der Prozesskette ausgeführt werden kann. Sie können also beispielsweise eingeben: MM1* für MM10 bis MM19, MM* für MM10-MM99, M*, *.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 31 von 78

2.4 Aktion zu Aktionsmatrizen zuordnen

Sie müssen die Aktion mindestens einer Primär- und/oder Sekundärmatrix zuordnen, je nachdem, wie sie im Customizing definiert ist.

Führen Sie in der IMG-Aktivität Aktionssteuerungen und Aktionsmatrizen festlegen (Transaktion OVELO11) folgende Schritte aus:

Die Aktionssteuerung ist ein Schlüssel, der eine Aktionsmatrix repräsentiert.

1. Legen Sie für jede Aktionssteuerung einen Schlüssel und eine Bezeichnung fest.

2. Wählen Sie die Aktionssteuerung, zu der die Aktion gehören soll.

3. Legen Sie für diese Aktionssteuerung die Aktionsmatrix fest, das heißt legen Sie fest, von welchem Status aus die Aktion ausgeführt werden darf und welcher Status nach erfolgreicher Aktionsdurchführung gesetzt werden soll.

Es ist möglich, das eine Aktion den Fahrzeugstatus nicht ändert, in diesem Fall sind alter Status und neuer Status gleich.

2.5 Findung der Aktionssteuerung festlegen

Abschließend müssen Sie noch die Aktionssteuerungsfindung einstellen, damit das System den Fahrzeugen eine primäre und/oder sekundäre Aktionssteuerung zuordnen kann. Beim Anlegen eines Fahrzeugs muss mindestens eine Steuerung gefunden werden, damit die Aktion erfolgreich sein kann.

Geben Sie in der Transaktion VELOS das Fahrzeugmodell an, und ordnen Sie ihm eine primäre und sekundäre Aktionssteuerung zu.

2.6 Aktion testen

Testen Sie Ihre neu angelegten Aktionen, indem Sie ein neues Fahrzeug anlegen.

Bei einfachen Aktionen werden nur Statusänderungen vorgenommen, Konfigurationsänderungen etc. sind nicht möglich. Der Aktionsscreen darf daher nur die Drucktaste Aktion ausführen enthalten.

Im Detailscreen können Sie die jeweiligen Statusänderungen und die Historieneinträge verfolgen.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 32 von 78

2.7 Aktionen verketten

Sie legen Verkettungsaktionen genauso an wie Elementaraktionen (siehe 2.1). In der Sicht Verkettungsaktionen ordnen Sie der Verkettungsaktion anschließend mehrere Elementaraktionen zu und legen mit einem numerischen Wert die Reihenfolge fest, in der diese Aktionen durchgeführt werden sollen.

• Sie dürfen die Verkettungsaktion nur dann anlegen, wenn Sie sowohl die Berechtigung für die Verkettungsaktion als auch für sämtliche Elementaraktionen haben.

• Jede Elementaraktion wird vom System als vollständige Aktion verarbeitet - inklusive Setzen eines neuen Status und Verbuchung. Daher müssen Sie jede Elementaraktion in der Primär- und/oder Sekundärmatrix als eigenen Eintrag aufnehmen. Während der Verarbeitung der Verkettungsaktion wird also durch jede Elementaraktion ein Zwischenstatus gesetzt.

• Sie müssen auch die Verkettungsaktion in die Primär- und/oder Sekundärmatrix aufnehmen. Dieser Eintrag ist wegen der Prüfung auf den alten Fahrzeugstatus relevant, nicht aber, um einen neuen Status zu setzen.

• Rekursive Verkettung ist nicht möglich. Verkettungsaktionen dürfen also nicht als Elementaraktionen von Verkettungsaktionen verwendet werden.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 33 von 78

3 Erstellung komplexer Aktionen

Zunächst müssen Sie, wie oben beschrieben, eine einfache Aktion anlegen. Darauf aufbauend können Sie nun die komplexe Aktion programmieren.

3.1 Eigene Aktionsfunktionsgruppe anlegen

Legen Sie eine eigene Funktionsgruppe an. Damit die Funktionsgruppe Aktionen aufnehmen kann, müssen Sie im Top-Include einige globale Datenobjekte deklarieren und im Rahmenprogramm einige PAI- und PBO-Module inkludieren. Kopieren Sie dazu die folgenden Zeilen in das Top-Include der neuen Funktionsgruppe (siehe 1.6.2):

FUNCTION-POOL VELOXX MESSAGE-ID VELO. *======================================================================= * Vehicle Management System Type Pool TYPE-POOLS: VLCH, * IBase Type Pool IBXX. * The Include LVELO02CON contains all constants that are used in the * Vehicle Management System. INCLUDE LVELO02CON. * The Include LVELO15ACT contains declarations that are needed in all * function groups in that actions are implemented. INCLUDE LVELO15ACT. *=======================================================================

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 34 von 78

Die benötigten PAI-, PBO-Module und Unterprogramme sind in der Funktionsgruppe VELO15 definiert. Inkludieren Sie diese Objekte im Rahmenprogramm der neuen Funktionsgruppe wie folgt:

* PBO : action screens (general) * ================================================================= INCLUDE LVELO15O01. " M_PREPARE_DATA (PBO) INCLUDE LVELO15F01. " F_PREPARE_DATA (PBO) INCLUDE LVELO15O02. " M_DETERMINE_LAYOUT (PBO) INCLUDE LVELO15F02. " F_DETERMINE_LAYOUT (PBO) INCLUDE LVELO15O03. " M_DETERMINE_VEHICLE_DISPLAY (PBO) INCLUDE LVELO15F03. " F_DETERMINE_VEHICLE_DISPLAY (PBO) * PAI : action screens (general) * ================================================================= INCLUDE LVELO15I01. " M_CHECK_ENTRY_FIELDS_FILLED (PAI) INCLUDE LVELO15F04. " F_CHECK_ENTRY_FIELDS_FILLED (PAI) INCLUDE LVELO15I02. " M_MODIFY_ITAB_FROM_DISP (PAI) INCLUDE LVELO15F05. " F_MODIFY_ITAB_FROM_DISP (PAI) INCLUDE LVELO15I03. " M_TRANSFER_DATA (PAI) INCLUDE LVELO15F06. " F_TRANSFER_DATA (PAI) * PBO : action screens (with additional vehicle data table) * ================================================================= INCLUDE LVELO15O04. " M_ADDITIONAL_VEHICLE_DATA_PBO INCLUDE LVELO15F07. " F_ADDITIONAL_VEHICLE_DATA_PBO * PAI : action screens (with additional vehicle data table) * ================================================================= INCLUDE LVELO15I04. " M_ADDITIONAL_VEHICLE_DATA_PAI INCLUDE LVELO15F08. " F_ADDITIONAL_VEHICLE_DATA_PAI

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 35 von 78

3.2 Aktionsspezifischen Subscreen anlegen

Komplexe Aktionen haben in der Regel einen eigenen Subscreen. Die Aktionsscreens haben einen einheitlichen Aufbau (siehe Abbildung) und bezüglich ihrer Module und Ablauflogik eine festgelegte Struktur.

Viele Aktionen benötigen für die Verarbeitung Eingangsparameter, die der Benutzer auf einem aktionsspezifischen Screen eingeben kann.

Im Folgenden wird beschrieben, wie Sie sehr einfach zusätzliche Felder auf Aktionsscreens aufbringen und diese im Rahmen der Aktionsausführung verarbeiten können. Mit dieser Methode können Sie sowohl bestehende Aktionsscreens erweitern als auch sehr einfach eigene Aktionsscreens anlegen.

Auch wenn Sie nur kleinere Änderungen an bestehenden Aktionsscreens machen, sollten Sie diese nicht modifizieren, sondern in eine eigene Funktionsgruppe kopieren und dort die Kopie verändern.

3.2.1 Screenelemente/Layout

Damit die Namen und Attribute der Screenelemente bei allen VMS-Aktionen übereinstimmen, empfiehlt SAP, immer einen bestehenden Screen zu kopieren und dann die Kopie anzupassen.

RahmennameACTIONTEXT_GV

Felder müssen Bestandteilsein von:VLCACTDATA_ITEM_Sund/oderVLCACTDATA_HEAD_S

Screenpainter Felder:IN1 (musst), IN2 (kann), OU1 (output)

Buttons (Screenpainter):BUTTON_KONF à start IPCBUTTON_ADDR à maintain endcustomerBUTTON_AKTN à action execute

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 36 von 78

• Rahmen

Der Rahmen des aktionsspezifischen Sreens muss ACTIONTEXT_GV heißen. Nur dann ist gewährleistet, dass der im VMS-Customizing festgelegte Text für die Aktionsbezeichnung auf dem Aktionsscreen automatisch erscheint.

• Verwendete Felder

Alle auf den Aktionsscreens verwendeten Felder müssen Bestandteil der Struktur VLCACTDATA_ITEM_S (Positionsdaten) oder der Struktur VLCACTDATA_ HEAD_S (Kopfdaten) sein. Damit sind sie automatisch Bestandteil der Kommunikationsstruktur VLCACTDATA_CS, so dass der Datentransport vom PREPARE-Baustein über den Aktionsscreen zum EXECUTE-Baustein funktioniert.

• Modifikationsgruppen

Die folgenden Modifikationsgruppen werden vom PBO-Modul M_DETERMINE_LAYOUT (siehe 3.2.2.1) automatisch in der unten beschriebenen Weise behandelt. Ordnen Sie die Screenfelder den Modifikationsgruppen entsprechend zu:

• IN1: Musseingabefelder einer Aktion, die nur vor der Aktionsausführung eingabebereit sind

• IN2: Kanneingabefelder einer Aktion, die nur vor der Aktionsausführung eingabebereit sind

• OU1: Reine Ausgabefelder, die erst nach der Aktionsausführung sichtbar sind. Felder dieser Modifikationsgruppe müssen auf dem Subscreen als unsichtbar und Nur-Ausgabefeld definiert sein.

• Verwendete Drucktasten

• BUTTON_KONF

Aufruf des IPC (Funktionscode KONF); wird nach der Aktionsausführung unsichtbar geschaltet

Die Drucktaste kann entsprechend den Einstellungen im Aktionscustomizing (siehe 2.2) unsichtbar geschaltet werden; für die Steuerung ist das PBO-Modul M_DETERMINE_ LAYOUT (siehe 3.2.2.1) verantwortlich.

• BUTTON_AKTN

Start der Aktionsausführung (Funktionscode AKTN); muss von jedem Aktionsscreen verwendet werden; wird nach der Aktionsausführung unsichtbar geschaltet

• BUTTON_ADDR

Aufruf der zentralen Adressverwaltung (Funktionscode ADDR); wird nicht auf jedem Aktionsscreen verwendet; wird nach der Aktionsausführung unsichtbar geschaltet

• Custom-Control (bei Qualifiern, siehe 3.3.2)

Wenn Sie mit Fahrzeug-Qualifiern arbeiten wollen, müssen Sie auf dem Aktionsscreen ein Custom-Control mit dem technischen Namen ADDDATA_CONTAINER aufbringen. Der Aktionsscreen 100 in der Funktionsgruppe VELO15 (Aktion SMOD Fahrzeug ändern) kann als Vorlage dienen.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 37 von 78

3.2.2 Ablauflogik

SAP empfiehlt, nur die Standardmodule zu nutzen, da Sie dann wartungsfreie Aktionsscreens verwenden; in aller Regel reichen die Möglichkeiten dieser Module. In der Ablauflogik müssen die existierenden Module in einer vorgeschriebenen Reihenfolge durchlaufen werden:

* Action XXXX (text) *======================================================================= PROCESS BEFORE OUTPUT. * Get VLCACTDATA to fill the fields of the subscreen MODULE M_PREPARE_DATA. * Find out which buttons / fields / ... should be visible MODULE M_DETERMINE_LAYOUT. * Determine the line of VLCACTDATA_ITEM_GT which has to be displayed now MODULE M_DETERMINE_VEHICLE_DISPLAY. * Prepare and display the alv-list and fill VLCADDDATA_VHCL_GT MODULE M_ADDITIONAL_VEHICLE_DATA_PBO. *======================================================================= PROCESS AFTER INPUT. CHAIN. FIELD VLCACTDATA_ITEM_S-VHVIN. FIELD VLCACTDATA_ITEM_S-PDDATU. FIELD VLCACTDATA_ITEM_S-VHUSG. FIELD VLCACTDATA_ITEM_S-VHSAR. FIELD VLCACTDATA_ITEM_S-SHLVL. * Find out if all mandatory entry fields have been filled by the user MODULE M_CHECK_ENTRY_FIELDS_FILLED. ENDCHAIN. * Put the modified data of the previously selected vehicle back to table * VLCACTDATA_ITEM_GT MODULE M_MODIFY_ITAB_FROM_DISP. * Check data entered in the alv-list and fill VLCADDDATA_ITEM_GT MODULE M_ADDITIONAL_VEHICLE_DATA_PAI. * Fill VLCACTDATA using the data entered on the subscreen MODULE M_TRANSFER_DATA. *=======================================================================

Jenachdem, ob der Aktionsscreen mit Kopfdaten, mit Positionsdaten und/oder mit Qualifierdaten arbeitet (siehe 1.5), werden bestimmte Module benötigt oder nicht (siehe unten).

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 38 von 78

Listen Sie unbedingt die Eingabefelder in der CHAIN-Anweisung auf; dies ist wichtig, damit nach einer fehlerhaften Eingabe das Feld wieder eingabebereit ist.

3.2.2.1 Module im Process Before Output

Die folgenden Module befinden sich in der Funktionsgruppe VELO15 und sind in die eigene Aktionsfunktionsgruppen inkludiert:

• M_PREPARE_DATA

Wird für alle Aktionen benötigt. Das Modul wird einmalig beim Neuaufruf einer Aktion prozessiert. Die Aufgabe des Moduls ist es, Daten, die von VELONN_<ACTION>_PREPARE-Bausteinen in die VLCACTDATA geschrieben werden, auf die Oberfläche zu bringen, indem die VLCACTDATA_HEAD_S und die VLCACTDATA_ITEM_GT gefüllt werden.

• M_DETERMINE_LAYOUT

Wird für alle Aktionen benötigt. Dieses Modul dient dazu, das Aussehen der aktionsspezifischen Subscreens in Abhängigkeit von der Variablen BEFORE_AFTER_GV zu steuern. Hier wird zum Beispiel die Sichtbarkeit und Eingabebereitschaft von Eingabefeldern geregelt, ebenso die Sichtbarkeit von Drucktasten. Beispielsweise sind Eingabefelder nach der Aktionsausführung nicht mehr eingabebereit.

Die Sichtbarkeit der Konfigurieren-Drucktaste (BUTTON_KONF) wird über das Aktionscustomizing (siehe 2.2) gesteuert.

• M_DETERMINE_VEHICLE_DISPLAY

Wird nur für Aktionen verwendet, bei denen es neben Kopf- auch Positionsdaten gibt, also Daten, die für die an der Aktion beteiligten Fahrzeuge verschieden sind. Mit diesem Modul wird sichergestellt, dass die Daten zum Fahrzeug, das in der Fahrzeugliste ausgewählt wurde, im Positionsdatenteil des Subscreens angezeigt werden. Hierzu werden die Daten aus der internen Tabelle VLCACTDATA_ITEM_GT in die Struktur VLCACTDATA_ITEM_S geschrieben. Die Nummer des ausgewählten Fahrzeugs wird aus der globalen Variable SELECTED_VEHICLE_GV gelesen.

• M_ADDITIONAL_VEHICLE_DATA_PBO

Wird nur für Aktionen mit Qualifierdaten benötigt. Dient dazu, die Zusatzdaten des in der Fahrzeugliste selektierten Fahrzeugs in die interne Tabelle zu schreiben und deren Inhalt auf dem Aktionsscreen als ALV anzuzeigen.

3.2.2.2 Module im Process After Input

Die folgenden Module befinden sich in der Funktionsgruppe VELO15 und sind in die eigene Aktionsfunktionsgruppen inkludiert:

• M_CHECK_ENTRY_FIELDS_FILLED

Prüft, ob alle Eingabefelder der Modifikationsgruppe IN1 (Muss-Eingabefelder) gefüllt sind, wenn der Benutzer die Drucktaste Aktion ausführen gewählt hat. Erst dann wird die Aktion ausgeführt.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 39 von 78

• M_MODIFY_ITAB_FROM_DISP

Wird nur für Aktionen verwendet, bei denen es neben Kopf- auch Positionsdaten gibt, und stellt das Gegenstück zu M_DETERMINE_VEHICLE_DISPLAY dar. Die auf dem Subscreen eingegebenen Positionsdaten werden dazu verwendet, in der internen Tabelle der für die Aktion relevanten Fahrzeuge die Daten des markierten Fahrzeugs zu aktualisieren.

• M_TRANSFER_DATA

Wenn der Benutzer die Drucktaste Aktion ausführen gewählt hat, werden die interne Tabelle VLCACTDATA_ITEM_GT und die Struktur VLCACTDATA_HEAD_S in die VLCACTDATA geschrieben. Der Transfer der Daten in der VLCACTDATA hin zu den VELO<NN>_<ACTION>_ EXECUTE-Bausteinen wird automatisch sichergestellt.

• M_ADDITIONAL_VEHICLE_DATA_PAI

Wird nur für Aktionen mit Qualifierdaten benötigt. Das Modul schreibt die interne Zusatzdatentabelle des angezeigten Fahrzeugs zurück in die interne Zusatzdatentabelle aller Fahrzeuge.

3.2.3 Aktionsscreen der Aktion zuordnen

Ordnen Sie den neu angelegten Aktionsscreen der Aktion zu (siehe 2.2).

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 40 von 78

3.3 Verarbeitung kundeneigener Zusatzdaten einrichten

Für die Verarbeitung und Speicherung von kundeneigenen Zusatzdaten gibt es im Vehicle Management System unter anderem zwei verschiedene Techniken:

• Fahrzeugattribute

• Qualifier

Dabei verursacht die Qualifier-Technik keinen und die Fahrzeugattribute-Technik fast keinen Entwicklungsaufwand.

3.3.1 Kundeneigene Zusatzdaten als Fahrzeugattribute verarbeiten

Fahrzeugattribute werden in der zentralen Fahrzeugtabelle VLCVEHICLE gespeichert; sie sind Felder dieser Tabelle.

Sie können entscheiden, ob bei der Aktionsverarbeitung ein Attribut für alle beteiligten Fahrzeuge gilt oder ob es fahrzeugspezifische Daten trägt.

Sie müssen neue kundeneigene Attribute als Datenelemente definieren und in die Fahrzeugtabelle VLCVEHICLE und die Kommunikationsstruktur VLCACTDATA aufnehmen.

3.3.1.1 Struktur VLCACTDATA erweitern Der Aufbau der Struktur VLCACTDATA wurde bereits erläutert (siehe 1.5). Je nachdem, ob ein Attribut bei der Aktionsverarbeitung für alle Fahrzeuge gelten soll oder nur fahrzeugspezifische Daten tragen soll, müssen Sie die VLCACTDATA_HEAD_S beziehungsweise die VLCACTDATA_ITEM_S erweitern:

• Kopfdaten (Struktur VLCACTDATA_HEAD_S)

Daten, die für alle an der Aktion beteiligten Fahrzeuge gelten. Beispiel: Wird ein Kundenauftrag für drei Fahrzeuge angelegt, so ist der Auftraggeber ein Kopfdatum.

Die Struktur VLCACTDATA_HEAD_S gliedert sich auf in weitere Unterstrukturen (siehe 1.5), in die die Fahrzeugattribute thematisch sortiert sind.

Sie sollten für kundeneigene Felder stets eine der Unterstrukturen erweitern. Eventuell ist es auch sinnvoll, eine neue Struktur in die VLCACTDATA_HEAD_S zu inkludieren.

• Positionsdaten (Tabellentyp VLCACTDATA_ITEM_T; Feld ADDDATA_ITEM)

Daten, die bei der Aktionsausführung nur für ein Fahrzeug gelten. Beispiel: Wird die Aktion SMOD Fahrzeug ändern für mehrere Fahrzeuge gleichzeitig durchgeführt, so wird zum Beispiel auf dem Aktionsscreen die Fahrzeugidentifikationsnummer nur für das ausgewählte Fahrzeug angezeigt.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 41 von 78

Wenn Sie die Struktur VLCACTDATA_ITEM_S erweitern wollen, gelten die selben Regeln wie bei der VLCACTDATA_HEAD_S. Sie müssen die neuen Attribute mit Hilfe der Append-Technik in die Fahrzeugtabelle VLCVEHICLE aufnehmen. Dabei ist wichtig, dass die Feldnamen in der Fahrzeugtabelle und der VLCACTDATA identisch sind.

Sie können Attribute zusätzlich auch in die Fahrzeughistorientabelle VLCHISTORY aufnehmen; wenn die Feldnamen mit denen in der Fahrzeugtabelle übereinstimmen, wird die Fahrzeughistorie bei der Aktionsverarbeitung automatisch mit den gewünschten Daten versorgt.

3.3.1.2 Fahrzeugattribute der Aktion zuordnen

Fahrzeugattribute werden in der IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen den Aktionen zugeordnet; dies bewirkt, dass die Daten beim Ausführen der Aktion automatisch verarbeitet werden.

Führen Sie dort die folgenden Schritte aus:

1. Markieren Sie die gewünschte Elementaraktion.

2. Geben Sie die Fahrzeugattribute zur Elementaraktion ein.

Sie müssen zuvor in der Transaktion VELO_SA die neuen Fahrzeugattribute in die Steuertabelle VLCVALIDFIELDS eintragen.

3. Definieren Sie, ob es sich bei einem Feld um ein Kopf- oder ein Positionsfeld handelt.

Kopffeld bedeutet, dass bei der Aktionsausführung das Feld aus der VLCACTDATA_HEAD_S in die Fahrzeugdaten aller beteiligten Fahrzeuge kopiert wird. Dieser Vorgang ist natürlich nur dann erfolgreich, wenn das Feld sowohl in der VLCACTDATA_HEAD_S als auch in der Fahrzeugtabelle VLCVEHICLE vorhanden ist.

Positionsfeld bedeutet, dass bei der Aktionsausführung das Feld aus der VLCACTDATA_ITEM_S in die Fahrzeugdaten eines betreffenden Fahrzeugs kopiert wird; dabei ist für jedes beteiligte Fahrzeug ein separater Datensatz vorhanden. Dieser Vorgang ist natürlich nur dann erfolgreich, wenn das Feld sowohl in der VLCACTDATA_ITEM_S als auch in der Fahrzeugtabelle VLCVEHICLE vorhanden ist.

Damit die Daten auf dem Aktionsscreen dargestellt/gepflegt werden können, müssen Sie einige Entwicklungen durchführen (siehe 3.2): Der Aktionsscreen muss die Felder der VLCACTDATA beinhalten; in der Ablauflogik werden die beschriebenen Module benötigt. Wenn Sie Positionsdaten verwenden, müssen Sie insbesondere die Module M_DETERMINE_VEHICLE_DISPLAY und M_MODIFY_ITAB_FROM_DISP integrieren.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 42 von 78

3.3.2 Kundeneigene Zusatzdaten als Qualifier verarbeiten

Qualifier sind im Customizing frei definierbar; sie tragen bei der Aktionsausführung fahrzeugspezifische Daten, die in der Datenbank in eine separate Tabelle VLCADDDATA geschrieben werden. Sie belasten also nicht die zentrale Fahrzeugtabelle.

Auf den Aktionsscreens werden sie als ALV-Liste dargestellt.

Da die Qualifier im Customizing frei definiert werden können, müssen Sie keine Strukturerweiterungen vornehmen.

3.3.2.1 Qualifier definieren

Legen Sie in der IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen für jeden Qualifier einen Schlüssel und eine Bezeichnung fest.

3.3.2.2 Qualifier der Aktion zuordnen

Qualifier werden in der IMG-Aktivität Zusatzdaten zum Fahrzeug festlegen den Aktionen zugeordnet; dies bewirkt, dass die Qualifier beim Ausführen der Aktion automatisch verarbeitet werden.

Führen Sie dort die folgenden Schritte aus:

1. Markieren Sie die gewünschte Elementaraktion.

2. Geben Sie die Qualifier zur Elementaraktion ein.

3. Wählen Sie den gewünschten Pflegetyp (Muss, Kann, Anzeige).

Damit die Qualifier auf dem Aktionsscreen dargestellt/gepflegt werden können, müssen Sie einige Entwicklungen durchführen (siehe 3.2): Der Aktionsscreen muss im Layout ein Custom-Control mit dem technischen Namen ADDDATA_CONTAINER beinhalten, und in der Ablauflogik müssen Sie insbesondere die beiden Module M_ADDITIONAL_VEHICLE_DATA_PBO und M_ADDITIONAL_VEHICLE_DATA _PAI integrieren.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 43 von 78

3.3.3 Qualifier versus Fahrzeugattribute

Das Arbeiten mit Attributen und Qualifiern ist dann sinnvoll, wenn Sie zusätzliche Informationen zu einem Fahrzeug benötigen, die nicht durch Merkmale abgedeckt sind, beispielsweise Kfz-Kennzeichen, Zulassungsnummer etc., und wenn Sie diese Informationen auf Aktionsscreens und bei der Fahrzeugsuche zugänglich machen möchten.

Aus betriebswirtschaftlicher Sicht ist die Verwendung von Qualifiern oder Fahrzeugattributen gleichbedeutend. Beide Konzepte stellen Parameter mit zusätzlichen kundenspezifischen Informationen zu einem Fahrzeug zur Verfügung.

Aus technischer Sicht gibt es folgende Unterschiede:

• Attribute werden direkt in die Fahrzeugtabelle VLCVEHICLE geschrieben. Der Umfang der Fahrzeugtabelle wird dadurch vergrößert, was unter Umständen Auswirkungen auf die Performance bei der Ausführung von Aktionen haben kann. Auf dem Aktionsscreen werden Attribute als zusätzliche einzelne Felder angezeigt.

• Qualifier dagegen werden in einer eigenen Zusatztabelle VLCADDDATA verwaltet. Der Umfang der Fahrzeugtabelle wird dadurch also nicht verändert, und die Performance bleibt unverändert. Auf dem Aktionsscreen werden Qualifier in einem eigenen Bereich als ALV-Liste angezeigt.

Verwenden Sie deshalb Qualifier dann, wenn Sie zusätzliche Daten zu einem Fahrzeug hinterlegen wollen, die folgende Kriterien erfüllen:

• Die Daten sind beschreibend, nicht steuernd.

• Die Anzahl der benötigten Datenfelder ist relativ groß.

• Die Daten werden nur bei wenigen Aktionen gebraucht.

Wenn diese Kriterien nicht zutreffen, sollten Sie die Technik der Fahrzeugattribute verwenden.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 44 von 78

3.4 Eigenen PREPARE-Baustein anlegen und aufrufen

Nicht jede Aktion benötigt einen eigenen PREPARE-Baustein. Aktionsspezifische PREPARE-Bausteine haben im wesentlichen folgende Aufgaben:

• Daten werden gelesen und aufbereitet, um sie der Kommunikationsstruktur VLCACTDATA_CS zu übergeben und somit auf dem Aktionsscreen als Vorschlagswert oder Information anzuzeigen.

• Der PREPARE-Baustein wird bei der Ausführung von Aktionen in der Transaktion VELO direkt nach Auswahl der Aktion, die durchgeführt werden soll, aufgerufen.

Hier kann also direkt zu Beginn der Aktionsverarbeitung geprüft werden, ob die Aktion aufgrund der aktuellen Datenkonstellation durchgeführt werden kann. Ein möglicher Abbruch an dieser Stelle ist wesentlich benutzerfreundlicher als einer, der erst in der EXECUTE-Verarbeitung auftritt, nachdem der Benutzer auf dem Aktionsscreen mühsam Daten eingegeben und die Drucktaste Aktion ausführen gewählt hat.

Beispiele für eine Prüfung:

• Die Aktion CHCO Kundenauftrag ändern prüft, ob überhaupt ein Kundenauftrag zum Fahrzeug existiert; falls nicht, wird die Verarbeitung abgebrochen.

• Die Aktion OUIV Ausgangsrechnung anlegen prüft, ob als Vorgängerbeleg ein Kundenauftrag existiert; falls nicht, wird die Verarbeitung abgebrochen.

Zunächst müssen Sie eine kundeneigene Aktionsfunktionsgruppe anlegen (siehe 3.1), die den PREPARE- und den EXECUTE-Baustein sowie den Aktionsscreen aufnehmen kann.

3.4.1 Namenskonvention

Halten Sie die folgende Namenskonvention für die PREPARE-Bausteine ein:

<FugrName>_<Aktionskürzel>_PREPARE

3.4.2 Dokumentation

Die Standard-Aktionsbausteine haben im Coding zum Teil dieselben beziehungsweise ähnliche Kommentarblöcke. Achten Sie auf eine einheitliche Art der Kommentierung auch bei den eigenen Aktionsbausteinen, um möglichst große Übersichtlichkeit und Transparenz zu erreichen.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 45 von 78

3.4.3 Schnittstelle

Die Schnittstelle der PREPARE-Bausteine ist relativ fest vorgegeben. Kopieren Sie einfach einen Standard-Baustein (in Aktionsfunktionsgruppen nachschauen (siehe 1.2); dadurch kopieren Sie neben der Schnittstelle auch die generelle Struktur und die Kommentarblöcke.

FUNCTION VELO10_MORD_PREPARE. *"---------------------------------------------------------------------- *"*"Lokale Schnittstelle: *" IMPORTING *" REFERENCE(XINTERLINKED_IV) LIKE CVLC03-INTRLK OPTIONAL *" REFERENCE(XCALLEDBYEXECUTE_IV) TYPE VLC_XCALLEDBYEXECUTE *" OPTIONAL *" TABLES *" VLCDIAVEHI_IT STRUCTURE VLCDIAVEHI OPTIONAL *" VLCGUIDCUOBJ_ET STRUCTURE VLCGUIDCUOBJ OPTIONAL *" CHANGING *" REFERENCE(VLCACTDATA_CS) TYPE VLCACTDATA *" EXCEPTIONS *" VEHICLES_OF_SEVERAL_ORDERS *" NO_PORDERS_FOUND_IN_VLC *" ERROR_IN_BAPI_PO_GETDETAIL *" NOT_PERFORMED *"----------------------------------------------------------------------

• XINTERLINKED_IV (optional)

Dieses Flag hat den Wert X, wenn die Aktion als Elementaraktion einer Verkettungsaktion ausgeführt wird. Sie können das Flag im Coding abfragen, um mit Hilfe eines IF-Statements zum Beispiel eine Prüfung bei Verkettungsaktionen auszuschalten, die dann später im EXECUTE-Baustein durchgeführt werden soll. Das ist beispielsweise dann sinnvoll, wenn die Existenz eines Vorgängerbelegs geprüft wird.

Beispiel einer Verkettung der Aktionen CUOR Kundenauftrag anlegen und OUIV Ausgangsrechnung anlegen:

Zum PREPARE-Zeitpunkt werden nacheinander die aktionsspezifischen PREPARE-Bausteine beider Aktionen durchlaufen (siehe 1.3.3). Im PREPARE-Baustein der Ausgangsrechnung wird geprüft, ob der Vorgängerbeleg, nämlich ein Kundenauftrag, existiert. Bei einer Verkettungsaktion existiert der Kundenauftrag natürlich noch nicht; eine Fehlermeldung und damit der Abbruch der Aktionsverarbeitung muss daher unterdrückt werden.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 46 von 78

• XCALLEDBYEXECUTE_IV (optional)

Dieses Flag hat den Wert X, wenn der PREPARE-Baustein vom EXECUTE-Baustein aufgerufen wird.

Hintergrund: Die Prüfungen, die im PREPARE-Baustein gemacht werden, müssen im EXECUTE-Baustein wiederholt werden (siehe 3.5.4.2.2). Daher kann es sinnvoll sein, den PREPARE-Baustein im EXECUTE-Baustein erneut aufzurufen.

Sie können dieses Flag im Coding abfragen, um beim Aufruf aus dem EXECUTE-Baustein zum Beispiel weniger tolerant auf das Fehlen von Vorgängerbelegen reagieren zu können.

• VLCDIAVEHI_IT (notwendig)

Interne Tabelle, die alle von der Aktion betroffenen Fahrzeuge beinhaltet. Es sind alle Felder der Fahrzeugtabelle und weitere aufbereitete Felder wie Kurztexte und aufgeschlüsselte Zeitstempel (Datum, Uhrzeit) enthalten.

Der Inhalt dieser Tabelle dient lediglich zur Information und darf im PREPARE-Baustein nicht verändert werden.

• VLCGUIDCUOBJ_ET (optional)

Export-Tabelle, in der die Vorlagekonfiguration festgelegt wird. Die Vorlagekonfiguration wird im IPC angezeigt und kann vom Benutzer geändert werden.

Der PREPARE-Baustein legt die Vorlagekonfiguration fest. Beispiel: Bei der Aktion CUOR Kundenauftrag anlegen wird die Konfiguration eines möglicherweise existierenden Angebots als Vorlage verwendet; wenn kein Angebot existiert, wird die Fahrzeugkonfiguration als Vorlage verwendet.

• VLCACTDATA_CS (notwendig)

Kommunikationsstruktur, die für den Datenfluss vom PREPARE-Baustein zum Aktionsscreen und von dort zum EXECUTE-Baustein sorgt.

In diese Struktur werden Daten geschrieben, die zum Beispiel auf dem Aktionsscreen angezeigt werden sollen oder die an den EXECUTE-Baustein übergeben werden sollen.

Wegen der Möglichkeit von Verkettungen darf ein PREPARE-Baustein diese Struktur niemals löschen; es dürfen nur Daten hinzugefügt werden.

• Ausnahmen (meistens notwendig)

Es gibt einen Grundsatz in der Entwicklung des VMS: Fehlermeldungen dürfen nicht innerhalb eines Funktionsbausteins ausgelöst werden, sondern werden Stufe für Stufe bis zur Oberfläche hochgereicht. Daraus folgt:

Wenn im PREPARE-Baustein eine Fehlersituation auftritt, wird die Fehlermeldung mit der RAISING-Anweisung an das aufrufende Programm übergeben (Codingbeispiel: MESSAGE E001 RAISING NOT_PERFORMED).

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 47 von 78

3.4.4 Quelltext

Implementieren Sie die PREPARE-Bausteine grundsätzlich so, dass sie verkettet werden könnten. Beachten Sie dazu die Bermerkungen zur Variablen XINTERLINKED_IV (siehe 3.4.3), und halten Sie den Grundsatz ein, dass die Kommunikationsstruktur VLCACTDATA_CS niemals gelöscht werden darf und dass lediglich Daten hinzugefügt werden dürfen. Der Refresh wird übrigens an zentraler Stelle gemacht.

Nutzen Sie grundsätzlich die Möglichkeit, Quelltext aus den Standardaktionen zu kopieren; das geht schnell und stellt Konsistenz der Logik sicher.

Kopieren Sie aus den Funktionsbausteinen der Standard-Aktionsfunktionsgruppen VELO10, VELO11, VELO15 etc. die Elemente, die Sie für Ihren Fall benötigen.

Im Folgenden finden Sie exemplarisch einige Codingbeispiele:

3.4.4.1 Datendeklarationen

Es ist hilfreich, wenn in den verschiedenen PREPARE-Bausteinen gleiche Variablen auch gleich benannt werden. Daher gilt auch hier: Kopieren geht schnell und stellt Konsistenz der Logik sicher.

*"---------------------------------------------------------------------- * This function module reads checks and prepares data needed for the * action XYZW before the subscreen of the action can be displayed. The * function module fills structure VLCACTDATA_CS with action specific * data. This function module must be processed before the PBO of the * action's subscreen is processed. *----------------------------------------------------------------------- * Declarations * ============ * Vehicles selected for XYZW DATA: VLCDIAVEHI_LS TYPE VLCDIAVEHI, * VLCACTDATA VLCACTDATA_ITEM_BEFORE_LT TYPE VLCACTDATA_ITEM_T, VLCACTDATA_ITEM_AFTER_LT TYPE VLCACTDATA_ITEM_T, VLCACTDATA_ITEM_LS TYPE VLCACTDATA_ITEM_S, * Local structure / table for the cust. quotation table of the VMS VLCOFFER_LS LIKE VLCOFFER, VLCOFFER_LT LIKE TABLE OF VLCOFFER, * GUIDs of the selected vehicles (for order selection) VLCGUID_LT LIKE TABLE OF VLCGUID, VLCGUID_LS LIKE VLCGUID, * Other variables ...

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 48 von 78

• VLCDIAVEHI_LS

Lokale Fahrzeugstruktur, die benötigt wird, wenn die Fahrzeugtabelle VLCDIAVEHI_IT (Schnittstelle; siehe 3.4.3) gelesen werden muss.

• VLCACTDATA_ITEM

Datenobjekte, die benötigt werden, wenn Sie mit Positionsdaten (siehe 1.5) der Kommunikationsstruktur arbeiten.

• VLCOFFER_LT

VMS-Belegtabelle des Standardbelegs Angebot; es gibt für die unterschiedlichen Belegtypen eigene VMS-Belegtabellen (siehe 4.1.1).

In den Belegtabellen ist die Verknüpfung von Fahrzeug und Belegnummer/Position gespeichert. Wenn Sie das Fahrzeug kennen, können Sie in diesen Tabellen die zugehörigen Belege ermitteln.

• VLCGUID_LT

GUID (Global Unique IDentifier), das heißt der Schlüssel der Fahrzeugtabelle VLCVEHICLE, der ein Fahrzeug eindeutig identifiziert.

Hier wird eine interne Tabelle deklariert, die mit den GUIDs der betroffenen Fahrzeuge gefüllt werden kann, um Daten aus verschiedenen Tabellen zu selektieren.

• Andere Variablen (Other variables)

Hier werden meist einfache nicht strukturierte Variablen deklariert.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 49 von 78

3.4.4.2 Prüfungen Eine wesentliche Aufgabe der PREPARE-Bausteine ist die Durchführung von Prüfungen.

Im Folgenden finden Sie zwei Beispiele:

3.4.4.2.1 Lesen/Prüfen des Vorgängerbelegs

*----------------------------------------------------------------------- * Step 1 * Fill table of GUIDs (needed as import parameter for * VELO04_READ_SEVERAL_OFFER) LOOP AT VLCDIAVEHI_IT INTO VLCDIAVEHI_LS. CLEAR: VLCGUID_LS. VLCGUID_LS-VGUID = VLCDIAVEHI_LS-VGUID. APPEND VLCGUID_LS TO VLCGUID_LT. ENDLOOP. "VLCDIAVEHI_IT *----------------------------------------------------------------------- * Step 2 * Verify that the customer quotation exists for the selected vehicles by * reading the Customer Quotation table of the Vehicle Manager CALL FUNCTION 'VELO04_READ_SEVERAL_OFFER' EXPORTING VLCACTDOCTYPE_IV = ABA_OFFE_GC TABLES VLCGUID_IT = VLCGUID_LT VLCOFFER_ET = VLCOFFER_LT EXCEPTIONS NO_OFFER_FOUND = 1 OTHERS = 2. IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4 RAISING NO_CUSTOMER_QUOTATION_FOUND. ENDIF. *-----------------------------------------------------------------------

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 50 von 78

• Schritt 1 (Step 1)

Die interne Tabelle VLCGUID_LT wird mit den GUIDs der betroffenen Fahrzeuge gefüllt.


Es werden in der VMS-Belegtabelle VLCOFFER alle Angebote (Belegnummer/Position) zu den betroffenen Fahrzeugen gelesen.

Zusätzlich wird mit dem Aktionsbelegtyp selektiert. Der Aktionsbelegtyp wurde eingeführt, damit nicht für jeden Belegtyp eine eigene VMS-Belegtabelle angelegt werden musste (Feld ACTDOCTYPE in VMS-Belegtabellen).

In die VMS-Belegtabelle VLCCUORDER werden beispielsweise sowohl Kundenaufträge als auch Retouren eingetragen. Technisch werden auch im R/3 diese beiden Belegtypen in der gleichen Tabelle abgelegt. Meistens kann als Aktionsbelegtyp das Aktionskürzel verwendet werden.

Beim Schreiben und Lesen in den VMS-Belegtabellen muss stets der Aktionsbelegtyp (Feld ACTDOCTYPE) berücksichtigt werden; meistens wird das Aktionskürzel der Standardaktion als Aktionsbelegtyp verwendet.

Fehlerhandling: Wenn ein Fehler auftritt, wird die Fehlermeldung nicht an dieser Stelle ausgelöst, sondern mit der RAISING-Anweisung an das aufrufende Programm übergeben.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 51 von 78

3.4.4.2.2 Bedingte Prüfungen

Im Folgenden sehen Sie einen Ausschnitt aus dem Coding der Aktion GOIS Warenausgang buchen. Um einen Warenausgang durchzuführen, wird obligatorisch als Vorgängerbeleg eine Lieferung benötigt:

*---------------------------------------------------------------------- * Read the delivery numbers for the selected vehicles from the delivery * table of the Vehicle Management System * (Function module VELO14_READ_DELIVERIES replaces VELO04_READ_DELIVERY) CALL FUNCTION 'VELO14_READ_DELIVERIES' EXPORTING ACTDOCTYPE_IV = ABA_DELIVDOC_LV LATEST_IV = 'X' " flag added for CRT4 TABLES VGUIDS_IT = VLCGUID_LT * ACTDOCTYPE_IT = DELIS_ET = VLCDELIVERY_LT EXCEPTIONS NO_ENTRIES_FOUND = 1 NO_DATA_RECEIVED = 2 OTHERS = 3. * Error handling IF SY-SUBRC <> 0. IF NOT XINTERLINKED_IV IS INITIAL AND XCALLEDBYEXECUTE_IV IS INITIAL. EXIT. * The existing of the delivery is not mandatory if the action is * performed as an interlinked action and if the calling function * module is not the EXECUTE function module. In this case the * processing of this function module is stopped. ELSE. * Error: no delivery found. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4 RAISING DELIVERY_NOT_FOUND1. ENDIF. " IF XINTERLINKED_IV IS INITIAL. ENDIF. "SY-SUBRC *----------------------------------------------------------------------

• Der Funktionsbaustein VELO14_READ_DELIVERIES liest in der VMS-Belegtabelle VLCDELIVERY, ob Lieferungen als Vorgängerbelege existieren.

• Wenn keine Lieferungen existieren, ist dies eine Fehlersituation. Mit Hilfe der Parameter XINTERLINKED_IV und XCALLEDBYEXECUTE_IV wird entschieden, ob der Fehler zu diesem Zeitpunkt möglicherweise unterdrückt werden soll (Hintergrund siehe 3.4.3).

à Wenn keine Verkettung vorliegt (XINTERLINKED_IV IS INITIAL), passiert unweigerlich der Fehler.

à Wenn der PREPARE-Baustein vom EXECUTE-Baustein aufgerufen wurde (NOT XCALLEDBYEXECUTE_IV IS INITIAL), passiert ebenfalls unweigerlich der Fehler.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 52 von 78

3.4.4.3 Füllen der Kommunikationsstruktur

Der PREPARE-Baustein darf keinesfalls die VLCACTDATA_CS löschen, da sonst keine Verkettung der Aktionen möglich ist. Es dürfen aber Daten hinzugefügt werden.

3.4.4.3.1 Kopfdaten

Im PREPARE-Baustein der Aktion CHCO Kundenauftrag ändern werden Daten des betroffenen Kundenauftrags in das Kopfsegment der Kommunikationsstruktur geschrieben, damit sie auf dem Aktionsscreen angezeigt werden.

*----------------------------------------------------------------------- * In order to display the data on the action subscreen, the data will be * moved to the structure VLCACTDATA_CS. VLCACTDATA_CS-KUNNR = VBAK_LS-KUNNR. VLCACTDATA_CS-KUNAM = KUNAM_LV. VLCACTDATA_CS-VBELN = VBELN_LV. VLCACTDATA_CS-AUART = VBAK_LS-AUART. VLCACTDATA_CS-VKORG = VBAK_LS-VKORG. VLCACTDATA_CS-VTWEG = VBAK_LS-VTWEG. VLCACTDATA_CS-SPART = VBAK_LS-SPART. VLCACTDATA_CS-BSTNK = VBAK_LS-BSTNK. *-----------------------------------------------------------------------

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 53 von 78

3.4.4.3.2 Positionsdaten

.... * PREPARE table containing existing old data of VLCACTDATA VLCACTDATA_ITEM_BEFORE_LT[] = VLCACTDATA_CS-ACTDATA_ITEM. * One line per vehicle ... LOOP AT VLCDIAVEHI_CT INTO VLCDIAVEHI_LS. * Don’t mix data of different vehicles CLEAR VLCACTDATA_ITEM_LS. * Use existing old data of VLCACTDATA_CS (This read does only find * entries in case of interlinked actions) READ TABLE VLCACTDATA_ITEM_BEFORE_LT INTO VLCACTDATA_ITEM_LS WITH KEY VGUID = VLCDIAVEHI_LS-VGUID. * Write GUID into the new VLCACTDATA (needed if VLCACTDATA_ITEM_LS is initial) VLCACTDATA_ITEM_LS-VGUID = VLCDIAVEHI_LS-VGUID. * Add action-specific data to VLCACTDATA_ITEM_LS .... * Add line to new VLCACTDATA APPEND VLCACTDATA_ITEM_LS TO VLCACTDATA_ITEM_AFTER_LT. ENDLOOP. " VLCDIAVEHI_CT INTO VLCDIAVEHI_LS * Replace old VLCACTDATA by new VLCACTDATA. Contains the entries of the * old VLCACTDATA and in addition data of the action. CLEAR VLCACTDATA_CS-ACTDATA_ITEM. VLCACTDATA_CS-ACTDATA_ITEM[] = VLCACTDATA_ITEM_AFTER_LT[]. ....

• Zunächst wird das Feld VLCACTDATA_CS-ACTDATA_ITEM (enthält Positionsdaten) in die BEFORE-Tabelle geschrieben.

• Aus dieser alten VLCACTDATA-Version wird nun – falls vorhanden – die Zeile gelesen, die zum aktuellen Fahrzeug passt. Die Zeile wird mit den aktionsspezifischen Daten (insbesondere mit der GUID) angereichert und an die AFTER-Tabelle angehängt.

• Anschließend wird das Feld VLCACTDATA_CS-ACTDATA_ITEM gelöscht und mit der AFTER-Tabelle überschrieben.

Durch dieses Verfahren ist sichergestellt, dass die Tabelle nicht aktualisiert wird, sondern dass sie nur mit zusätzlichen neuen Daten angereichert wird; dies ist bei Verkettungen von Bedeutung.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 54 von 78

3.4.4.4 Festlegen der Vorlagekonfiguration

Im PREPARE-Baustein kann die Vorlagekonfiguration festgelegt werden. Diese Konfiguration wird im IPC angezeigt und kann vom Benutzer geändert werden.

*---------------------------------------------------------------------- IF VLCGUIDCUOBJ_ET IS REQUESTED. * Provide a table containing a list of GUIDs and the CUOBJs of the * action's template configurations (in this case, the vehicle cfg is * the templete cfg) LOOP AT VLCDIAVEHI_IT INTO VLCDIAVEHI_LS. VLCGUIDCUOBJ_LS-VGUID = VLCDIAVEHI_LS-VGUID. * take the vehicle configuration VLCGUIDCUOBJ_LS-CUOBJ = VLCDIAVEHI_LS-CUOBJ. * Add template configuration's CUOBJ to the list APPEND VLCGUIDCUOBJ_LS TO VLCGUIDCUOBJ_ET. CLEAR VLCGUIDCUOBJ_LS. ENDLOOP. " LOOP AT VLCDIAVEHI_IT INTO VLCDIAVEHI_LS ENDIF. " IF VLCGUIDCUOBJ_ET IS REQUESTED. *----------------------------------------------------------------------

• In der internen Tabelle VLCGUIDCUOBJ_ET kann pro Fahrzeug festgelegt werden, welche Konfiguration als Vorlagekonfiguration verwendet werden soll.

Hintergrund: Die Konfiguration wird im R/3 in der IBase abgelegt; es gibt einen Schlüssel (CUOBJ), der eindeutig eine konkrete Konfiguration repräsentiert.

Die Fahrzeugkonfiguration wird hier im Coding durch das Feld VLCDIAVEHI_LS-CUOBJ repräsentiert. In der zentralen Fahrzeugtabelle VLCVEHICLE entspricht dieses Feld dem Feld VLCVEHICLE-CUOBJ.

• In der internen Tabelle VLCGUIDCUOBJ_ET wird die Verknüpfung von Fahrzeug (GUID) und Konfiguration (CUOBJ) gespeichert.

• Die Tabelle VLCGUIDCUOBJ_ET wird aus dem aktionsspezifischen PREPARE-Baustein exportiert und an zentraler Stelle weiterverwendet.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 55 von 78

3.4.5 Aufruf

Legen Sie in der Transaktion SE18 für das BAdI VLC_PREPARE_ACTION eine Implementierung an. In der BAdI-Methode PREPARE_FURTHER_ACTIONS wird der aktionsspezifische PREPARE-Baustein aufgerufen.

Coding-Beispiel:

********************* CASE - LOOP on all actions ********************* CASE ACTION_TO_BE_PERFORMED_IV. WHEN ‘<Aktionskürzel1>’. " Customer’s first action ! *::::::::::::::::::::::::: ACTION: <Aktionskürzel> ::::::::::::::::::::::::: CALL FUNCTION '<FugrName>_<Aktionskürzel1>_PREPARE' EXPORTING XINTERLINKED_IV = INCOMING_ACTION_IS-INTRLK TABLES VLCDIAVEHI_IT = LIST_OF_VEHICLES_IT VLCGUIDCUOBJ_ET = VLCGUIDCUOBJ_ET CHANGING VLCACTDATA_CS = VLCACTDATA_CS EXCEPTIONS NOT_PERFORMED = 1 OTHERS = 2. IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4 RAISING ACTION_PREPARE_NOT_PERFORMED. ENDIF. WHEN ‘<Aktionskürzel2>’. " Customer’s second action ! *:::::::::::::::::::::::: ACTION: <Aktionskürzel2> :::::::::::::::::::::::: ... usw. ENDCASE.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 56 von 78

3.5 Eigenen EXECUTE-Baustein anlegen und aufrufen

Der EXECUTE-Baustein wird aufgerufe,n wenn der Benutzer die Drucktaste Aktion ausführen wählt; hier wird der betriebswirtschaftliche Prozessschritt für alle betroffenen Fahrzeuge durchgeführt, und es werden Daten und gegebenenfalls Belege in die Datenbank geschrieben.

Bei Aktionsausführung über VMS-BAPIs werden nur die EXECUTE-Bausteine durchlaufen. Daher müssen die in den PREPARE-Bausteinen implementierten Prüfungen in den EXECUTE-Bausteinen ebenfalls durchgeführt werden. Anders ausgedrückt:


Aktionsspezifische EXECUTE-Bausteine haben unter anderem folgende Aufgaben:

• Prüfen, ob die Aktion auf Grundlage der aktuellen Datenkonstellation für die übergebenen Fahrzeuge durchgeführt werden darf

• Daten von der Kommunikationsstruktur VLCACTDATA_CS in die Fahrzeugdaten schreiben

• Gegebenenfalls VMS-BAPIs aufrufen, um zum Beispiel SAP-Standardbelege anzulegen, zu ändern oder zu löschen

• VMS-Belegtabellen fortschreiben, falls nötig

3.5.1 Namenskonvention

Halten Sie die folgende Namenskonvention für die EXECUTE-Bausteine ein:

<FugrName>_<Aktionskürzel>_ EXECUTE

3.5.2 Dokumentation

Die Standard-Aktionsbausteine haben im Coding zum Teil dieselben beziehungsweise ähnliche Kommentarblöcke. Achten Sie auf eine einheitliche Art der Kommentierung auch bei den eigenen Aktionsbausteinen, um möglichst große Übersichtlichkeit und Transparenz zu erreichen.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 57 von 78

3.5.3 Schnittstelle

Die Schnittstelle der EXECUTE-Bausteine ist relativ fest vorgegeben. Kopieren Sie einfach einen Standard-Baustein (in Aktionsfunktionsgruppen nachschauen (siehe 1.2); dadurch kopieren Sie neben der Schnittstelle auch die generelle Struktur und die Kommentarblöcke.

FUNCTION VELO11_CUOR_EXECUTE . *"---------------------------------------------------------------------- *"*"Lokale Schnittstelle: *" IMPORTING *" REFERENCE(DIALOGUE_ALLOWED_IV) TYPE C OPTIONAL *" TABLES *" VLCDIAVEHI_CT STRUCTURE VLCDIAVEHI *" VLCH_MSSG_CT TYPE VLCH_MSSG_PT *" VLCBAPICU_IT TYPE VLCBAPICU_T *" CHANGING *" REFERENCE(VLCACTDATA_CS) TYPE VLCACTDATA *" EXCEPTIONS *" DIFFERENT_KUNNR *" SEVERAL_OFFERS_CONCERNED *" CONTR_ENTITY_NOT_FOUND *" DIFFERENT_CONTR_ENTITY *" CUSTOMER_DATA_NOT_FOUND *" VEHIUSAGE_NOT_FOUND *" PARTNER_ERROR *" ACTION_NOT_PERFORMED *" UPDATE_NOT_PERFORMED *" SET_TARGET_CFG_ERROR *"----------------------------------------------------------------------

• DIALOGUE_ALLOWED_IV (optional)

Wird nur benötigt, wenn im EXECUTE-Baustein Screens aufgerufen werden; dies betrifft natürlich auch Bausteine, die vom EXECUTE-Baustein aufgerufen werden.

Dieses Flag hat den Wert X, wenn die Aktion von der Transaktion VELO aufgerufen wird; in diesem Fall darf der EXECUTE-Baustein Screens aufrufen.

Wenn die Aktion durch ein VMS-BAPI aufgerufen wird (Batch-Job, IDoc-Schnittstelle, Web-Interface), ist das Flag initial, und im EXECUTE-Baustein dürfen keine Screens aufgerufen werden.

Im EXECUTE-Baustein dürfen Screens nur dann aufgerufen werden, wenn die Variable DIALOGUE_ALLOWED_IV den Wert X hat. Jeder Screenaufruf muss also in ein entsprechendes IF-Statement eingebettet werden.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 58 von 78

• VLCDIAVEHI_IT (notwendig)

Interne Tabelle, die alle von der Aktion betroffenen Fahrzeuge enthält. Es sind alle Felder der Fahrzeugtabelle und weitere aufbereitete Felder wie Kurztexte und aufgeschlüsselte Zeitstempel (Datum, Uhrzeit) enthalten.

Im EXECUTE-Baustein können Daten dieser internen Tabelle geändert werden. Im weiteren Programmverlauf werden diese Daten mit MOVE-CORRESPONDING in die Fahrzeugtabelle VLCVEHICLE und in die Fahrzeughistorie VLCHISTORY geschrieben.

Damit Daten in die Fahrzeug- und/oder Historientabelle übertragen werden, müssen sie in die interne Tabelle VLCDIAVEHI_CT geschrieben werden.

• VLCH_MSSG_CT (notwendig)

Interne Tabelle, in der alle relevanten aufgetretenen Meldungen (unabhängig vom Typ) gesammelt werden. Insbesondere die Fehlermeldungen müssen in diese Tabelle geschrieben werden, damit der Benutzer in einem Protokoll über den Fehler informiert werden kann.

Zum Füllen der Tabelle ruft der EXECUTE-Baustein den Baustein VELO03_FILL_ERROR_TABLE auf; Beispiel: 3.5.4.2.1.

• VLCBAPICU_IT (optional)

Interne Tabelle, die für jedes zu verarbeitende Fahrzeug die neue beziehungsweise geänderte Konfiguration beinhaltet. In der Komponente BAPICUVAL stehen die Merkmale und Merkmalwerte.

Die Konfigurationsdaten können im EXECUTE-Baustein beispielsweise den Kundenauftrags- beziehungsweise Bestell-BAPIs übergeben werden, um die Konfiguration in die Standardbelege zu schreiben, oder sie können mit dem Baustein VELO03_SET_SINGLE_CONFIG als Fahrzeugkonfiguration abgelegt werden.

• VLCACTDATA_CS (notwendig)

Kommunikationsstruktur, die für den Datenfluss vom PREPARE-Baustein über den Aktionsscreen zum EXECUTE-Baustein und von dort zurück zum Aktionsscreen sorgt.

Aus dieser Struktur werden Zusatzdaten für die Aktionsausführung gelesen.

Außerdem können in diese Struktur Daten geschrieben werden, die auf dem Aktionsscreen angezeigt werden sollen. Beispiel: Wenn im EXECUTE-Baustein ein Beleg angelegt wurde, kann die Belegnummer in die Struktur geschrieben werden, damit sie auf dem Aktionsscreen angezeigt wird.

Wegen der Möglichkeit von Verkettungen darf ein EXECUTE-Baustein den Inhalt dieser Struktur niemals löschen; es dürfen nur Daten hinzugefügt werden.



Es gibt einen Grundsatz in der Entwicklung des VMS: Fehlermeldungen dürfen nicht innerhalb eines Funktionsbausteins ausgelöst werden, sondern werden Stufe für Stufe bis zur Oberfläche hochgereicht.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 59 von 78

In den EXECUTE-Bausteinen müssen Meldungen in die Message Tabelle VLCH_ MSSG_CT geschrieben werden, damit sie dem Benutzer als Protokoll zur Verfügung gestellt werden können.

Wenn im EXECUTE-Baustein eine Fehlersituation auftritt, wird die Fehlermeldung in die Message-Tabelle VLCH_MSSG_CT geschrieben, und die Fehlersituation wird mit der RAISE-Anweisung (Codingbeispiel: RAISE VEHIUSAGE_NOT_FOUND) dem aufrufenden Programm übergeben.

Wenn der EXECUTE-Baustein einen Fehler auslöst, wird die Aktion für alle Fahrzeuge, die dem Baustein übergeben wurden, abgebrochen.

3.5.4 Quelltext

3.5.4.1 Datendeklarationen

*"---------------------------------------------------------------------- * Action CUOR: Creates the Sales Order * All error messages are written into table VLCH_MSSG_CT *----------------------------------------------------------------------- * Declarations * ============ * Local structure for data of VLCDIAVEHI_CT DATA: VLCDIAVEHI_LS TYPE VLCDIAVEHI, * Action specific header data of VLCACTDATA_CS VLCACTDATA_HEAD_LS TYPE VLCACTDATA_HEAD_S, * Action specific item data of VLCACTDATA_CS VLCACTDATA_ITEM_LS TYPE VLCACTDATA_ITEM_S, VLCACTDATA_ITEM_LT TYPE VLCACTDATA_ITEM_T, * Local structure / table for the Sales Order table of the VMS VLCCUORDER_LS LIKE VLCCUORDER, VLCCUORDER_LT LIKE TABLE OF VLCCUORDER, * List of vehicles relvant for the action VLCGUID_LT LIKE TABLE OF VLCGUID, VLCGUID_LS LIKE VLCGUID, * Structure and table for action document type ACTDOCTYPE_LT TYPE VLCH_ACTDOCTYPE_PT, ACTDOCTYPE_LS TYPE VLCH_ACTDOCTYPE_PS, * Configuration stuff VLCBAPICU_LS TYPE VLCBAPICU, * Local structure / table for BAPI_SALESORDER_CREATEFROMDAT2 … * Other variables …

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 60 von 78

• VLCDIAVEHI_LS

Lokale Fahrzeugstruktur, die benötigt wird, wenn die Fahrzeugtabelle VLCDIAVEHI_IT (Schnittstelle; siehe 3.5.3) gelesen beziehungsweise geändert werden muss.

• VLCACTDATA

Datenobjekte, die benötigt werden, wenn Sie mit Kopf- beziehungsweise Positionsdaten (siehe 1.5) der Kommunikationsstruktur arbeiten.

• VLCCUORDER_LT

VMS-Belegtabelle des Standardbelegs Kundenauftrag; es gibt für die unterschiedlichen Belegtypen eigene VMS-Belegtabellen (siehe 4.1.1).

In den Belegtabellen ist die Verknüpfung von Fahrzeug und Belegnummer/Position gespeichert. Wenn Sie das Fahrzeug kennen, können Sie in diesen Tabellen die zugehörigen Belege ermitteln.

• VLCGUID_LT

GUID (Global Unique IDentifier), das heißt der Schlüssel der Fahrzeugtabelle VLCVEHICLE, der ein Fahrzeug eindeutig identifiziert.

Hier wird eine interne Tabelle deklariert, die mit den GUIDs der betroffenen Fahrzeuge gefüllt werden kann, um Daten aus verschiedenen Tabellen zu selektieren.

• ORDER_ACTDOCTYPE_LT

Interne Tabelle, die mit dem Aktionsbelegtyp gefüllt wird, um Daten aus den jeweiligen VMS-Belegtabellen zu selektieren (siehe 3.5.4.2.1).

• VLCBAPICU_LS

Lokale Konfigurationsdatenstruktur, die benötigt wird, wenn die interne Tabelle VLCBAPICU_IT (Schnittstelle; siehe 3.5.3) gelesen werden muss.

• Lokale Struktur/Tabelle für BAPIs

Wenn im EXECUTE-Baustein ein Standard-BAPI aufgerufen wird, müssen zuvor die Schnittstellenparameter gefüllt werden; hier werden die benötigten Datenobjekte deklariert.

• Andere Variablen (Other variables)

Hier werden meist einfache, nicht strukturierte Variablen deklariert.

3.5.4.2 Prüfungen

Es müssen alle in den PREPARE-Bausteinen implementierten Prüfungen in den EXECUTE-Bausteinen wiederholt werden.

Dazu können Sie entweder die Prüfungen direkt im EXECUTE-Baustein implementieren oder den PREPARE-Baustein im EXECUTE-Baustein aufrufen. Welche Methode die bessere ist, müssen Sie von Fall zu Fall entscheiden.

3.5.4.2.1 Lesen/Prüfen des Vorgängerbelegs

Dies ist ein vereinfachter Ausschnitt aus dem Coding des EXECUTE-Bausteins der Aktion DECO Kundenauftrag löschen. Damit ein Kundenauftrag gelöscht werden kann, muss vorher ein Kundenauftrag für die betroffenen Fahrzeuge existieren.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 61 von 78

*----------------------------------------------------------------------- * Step 1 * Fill table of GUIDs (needed as import parameter for function module * VELO04_READ_SALESORDER) LOOP AT VLCDIAVEHI_CT INTO VLCDIAVEHI_LS. CLEAR: VLCGUID_LS. VLCGUID_LS-VGUID = VLCDIAVEHI_LS-VGUID. APPEND VLCGUID_LS TO VLCGUID_LT. ENDLOOP. "VLCDIAVEHI_CT *---------------------------------------------------------------------- * Step 2 * Read the entries for the selected vehicles from the Sales Order table * of the Vehicle Manager * Action CUOR ACTDOCTYPE_LS-SIGN = 'I'. ACTDOCTYPE_LS-OPTION = 'EQ'. ACTDOCTYPE_LS-LOW = ABA_CUOR_GC. APPEND ACTDOCTYPE_LS TO ACTDOCTYPE _LT. * Step 3 * Read the sales orders from the vehicle manager table vlcuorder CALL FUNCTION 'VELO04_READ_SALESORDERS' EXPORTING LATEST_IV = 'Y' " flag added for CRT4 TABLES VLCGUID_IT = VLCGUID_LT VLCACTDOCTYPE_IT = ACTDOCTYPE_LT VLCCUORDER_ET = VLCCUORDER_LT EXCEPTIONS NO_DATA_RECEIVED = 1 NOTHING_FOUND = 2 OTHERS = 3. * Error handling IF SY-SUBRC NE 0. CALL FUNCTION 'VELO03_FILL_ERROR_TABLE' EXPORTING MSGID_IV = SY-MSGID MSGTY_IV = SY-MSGTY MSGNO_IV = SY-MSGNO MSGV1_IV = SY-MSGV1 MSGV2_IV = SY-MSGV2 MSGV3_IV = SY-MSGV3 MSGV4_IV = SY-MSGV4 TABLES VLCH_MSSG_CT = VLCH_MSSG_CT. RAISE NO_SALES_ORDER_FOUND. ENDIF. "SY-SUBRC *----------------------------------------------------------------------

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 62 von 78


Die interne Tabelle VLCGUID_LT wird mit den GUIDs der betroffenen Fahrzeuge gefüllt.


Die interne Tabelle ACTDOCTYPE _LT wird mit dem Aktionsbelegtyp gefüllt.


In der VMS-Belegtabelle VLCCUORDER werden alle Kundenaufträge (Belegnummer/Position) zu den betroffenen Fahrzeugen gelesen.

Weitere Informationen zum Aktionsbelegtyp finden Sie unter 3.4.4.2.1.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 63 von 78

3.5.4.2.2 Aufruf des PREPARE-Bausteins

Damit Sie Prüfungen nicht doppelt implementieren müssen, können Sie den PREPARE-Baustein im EXECUTE-Baustein aufrufen. Dazu setzen Sie den Import-Parameter XCALLEDBYEXECUTE_IV (siehe 3.4.3) auf den Wert X, so dass Sie im PREPARE-Baustein auf diese Situation logisch reagieren können. Der PREPARE-Baustein zum EXECUTE-Zeitpunkt sollte beispielsweise in der Regel keine Daten mehr vorbereiten.

Alle Prüfungen, die bei Verkettungsaktionen zum PREPARE-Zeitpunkt ausgeschaltet sind (zum Beispiel Prüfung auf Existenz von Vorgängerbelegen; siehe 3.4.4.2.2), müssen zum EXECUTE-Zeitpunkt durchlaufen werden.

Dies ist ein vereinfachter Ausschnitt aus dem Coding der Aktion MORD Bestellung ändern. Der EXECUTE-Baustein ruft den PREPARE-Baustein auf:

*====================================================================== * # Step 1 # * PREPARATIONS *====================================================================== * Read necessary data, perform some checks. Most of this is also done * in VELO10_MORD_PREPARE. In case of interlinked actions and action * execution without subscreens (IDOC, BAPI) it is necessary to perform * this in the VELO10_MORD_EXECUTE function module, too * Perform preparations (again) CALL FUNCTION 'VELO10_MORD_PREPARE' EXPORTING * XINTERLINKED_IV = XCALLEDBYEXECUTE_IV = 'X' TABLES VLCDIAVEHI_IT = VLCDIAVEHI_CT CHANGING VLCACTDATA_CS = VLCACTDATA_CS EXCEPTIONS VEHICLES_OF_SEVERAL_ORDERS = 1 NO_PORDERS_FOUND_IN_VLC = 2 ERROR_IN_BAPI_PO_GETDETAIL = 3 NOT_PERFORMED = 4 OTHERS = 5. * Error handling IF SY-SUBRC <> 0. CALL FUNCTION 'VELO03_FILL_ERROR_TABLE' EXPORTING MSGID_IV = SY-MSGID MSGTY_IV = SY-MSGTY MSGNO_IV = SY-MSGNO MSGV1_IV = SY-MSGV1 MSGV2_IV = SY-MSGV2 MSGV3_IV = SY-MSGV3 MSGV4_IV = SY-MSGV4 TABLES VLCH_MSSG_CT = VLCH_MSSG_CT. RAISE PREPARE_ERROR. ENDIF. *----------------------------------------------------------------------

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 64 von 78

Wenn Sie den PREPARE-Bausteins im EXECUTE-Baustein aufrufen, wird der Parameter XCALLEDBYEXECUTE_IV auf den Wert X gesetzt. Der Parameter XINTERLINKED_IV kann nicht versorgt werden und ist somit immer initial.

3.5.4.3 Anlegen/Ändern/Löschen von SAP-Standardbelegen

Sie sollten SAP-Standardbelege soweit wie möglich nur mit BAPIs bearbeiten. Im Coding müssen Sie drei wesentliche Schritte durchführen:

1. Daten lesen

2. Daten in die BAPI-Strukturen konvertieren beziehungsweise kopieren

3. BAPI aufrufen

Das folgende vereinfachte Coding-Beispiel zeigt den Aufruf des BAPIs zum Anlegen eines Kundenauftrags im EXECUTE-Baustein der Aktion CUOR:

* Step B.2 * Create the customer order * Call the function module SD_SALESDOCUMENT_CREATE CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2' EXPORTING SALESDOCUMENTIN = SALESDOCUMENTIN_LV ORDER_HEADER_IN = SD_HEAD_LS ORDER_HEADER_INX = ORDER_HEADER_INX_LS SENDER = SENDER_LV BINARY_RELATIONSHIPTYPE = BINARY_RELATIONSHIPTYPE_LV INT_NUMBER_ASSIGNMENT = INT_NUMBER_ASSIGNMENT_LV BEHAVE_WHEN_ERROR = BEHAVE_WHEN_ERROR_LV LOGIC_SWITCH = LOGIC_SWITCH_LS TESTRUN = TESTRUN_LV CONVERT = CONVERT_LV IMPORTING SALESDOCUMENT = VBELN_LV TABLES RETURN = RETURN_LT ORDER_ITEMS_IN = SD_ITEM_LT ORDER_ITEMS_INX = ORDER_ITEMS_INX_LT ORDER_PARTNERS = SD_PART_LT ORDER_SCHEDULES_IN = SD_SCHE_LT ORDER_SCHEDULES_INX = ORDER_SCHEDULES_INX_LT ORDER_CONDITIONS_IN = ORDER_CONDITIONS_IN_LT ORDER_CONDITIONS_INX = ORDER_CONDITIONS_INX_LT ORDER_CFGS_REF = BAPICUCFG_LT ORDER_CFGS_INST = BAPICUINS_LT ORDER_CFGS_PART_OF = BAPICUPRT_LT ORDER_CFGS_VALUE = BAPICUVAL_LT ORDER_CFGS_BLOB = ORDER_CFGS_BLOB_LT ORDER_CFGS_VK = BAPICUVK_LT ORDER_CFGS_REFINST = BAPICUREF_LT ORDER_CCARD = ORDER_CCARD_LT ORDER_TEXT = ORDER_TEXT_LT ORDER_KEYS = ORDER_KEYS_LT

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 65 von 78

EXTENSIONIN = EXTENSIONIN_LT PARTNERADDRESSES = BAPIADDR1_LT. *----------------------------------------------------------------------- * Step B.3 * Error handling for the BAPI * Clear the error-flag CLEAR RAISE_FLAG_LV. * Loop over the return-message-table and write ALL messages into the * Vehicle Manager message table VLCH_MSSG_CT LOOP AT RETURN_LT INTO RETURN_LS. CALL FUNCTION 'VELO03_FILL_ERROR_TABLE' EXPORTING MSGID_IV = RETURN_LS-ID MSGTY_IV = RETURN_LS-TYPE MSGNO_IV = RETURN_LS-NUMBER MSGV1_IV = RETURN_LS-MESSAGE_V1 MSGV2_IV = RETURN_LS-MESSAGE_V2 MSGV3_IV = RETURN_LS-MESSAGE_V3 MSGV4_IV = RETURN_LS-MESSAGE_V4 TABLES VLCH_MSSG_CT = VLCH_MSSG_CT. * Set the error flag if there are messages with a specific * message-type IF RETURN_LS-TYPE = 'E' OR RETURN_LS-TYPE = 'A'. RAISE_FLAG_LV = XFLAG_GC. ENDIF. ENDLOOP. "RETURN_LT * If the error-flag is set, raise an error ! IF NOT RAISE_FLAG_LV IS INITIAL. RAISE ACTION_NOT_PERFORMED. ENDIF.

Viele BAPIs liefern eine RETURN-Tabelle zurück, in der die gesammelten Meldungen gespeichert sind. In einer Schleifenverarbeitung über diese Tabelle wird jede Meldung mit Hilfe des Bausteins VELO03_FILL_ERROR_TABLE in die VMS-Message-Tabelle VLCH_MSSG_CT geschrieben; damit stehen die Meldungen im Aktionsprotokoll zur Verfügung.

Bei einer Fehlermeldung oder Abbruchmeldung wird das Fehlerkennzeichen RAISE_FLAG_LV gesetzt und anschließend mit Hilfe der RAISE-Anweisung die Fehlersituation an das rufende Programm übergeben.

Kundeneigene Felder können mit dem Datenobjekt EXTENSIONIN an viele BAPIs übergeben werden.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 66 von 78

3.5.4.4 Fortschreiben der VMS-Belegtabelle

In den VMS-Belegtabellen ist die Verknüpfung von Fahrzeug und Belegnummer/Position gespeichert. Daher muss, wenn ein Beleg angelegt oder gelöscht wurde, ein Eintrag in der entsprechenden VMS-Belegtabelle (siehe 1.4) hinzugefügt oder gelöscht werden.

Das folgende vereinfachte Coding-Beispiel zeigt die entsprechenden Coding-Strecken im EXECUTE-Baustein der Aktion CUOR Kundenauftrag anlegen:

*----------------------------------------------------------------------- * Step 1 * Write entries to the sales order table of the vehicle REFRESH VLCCUORDER_LT[]. LOOP AT VLCDIAVEHI_CT INTO VLCDIAVEHI_LS. CLEAR: VLCCUORDER_LS. LOOP_INDEX_LV = SY-TABIX. * Sales order table READ TABLE SD_ITEM_LT INTO SD_ITEM_LS INDEX LOOP_INDEX_LV. VLCCUORDER_LS-VGUID = VLCDIAVEHI_LS-VGUID. VLCCUORDER_LS-TSTMP = VLCDIAVEHI_LS-NEWTSP. VLCCUORDER_LS-ACTDOCTYPE = ABA_CUOR_GC. VLCCUORDER_LS-VBELN = VBELN_LV. VLCCUORDER_LS-POSNR = SD_ITEM_LS-ITM_NUMBER. VLCCUORDER_LS-BSTNK = VLCACTDATA_HEAD_LS-BSTNK. VLCCUORDER_LS-ERNAM = VLCDIAVEHI_LS-ACTERNAM. APPEND VLCCUORDER_LS TO VLCCUORDER_LT. ENDLOOP. " VLCDIAVEHI_CT *---------------------------------------------------------------------- * Step 2 * Write an entry in the table linking sales doc with vehicle CALL FUNCTION 'VELO04_UPDATE_VLCCUORDER' IN UPDATE TASK TABLES VLCCUORDER_LT = VLCCUORDER_LT EXCEPTIONS NO_DATA_RECEIVED = 1 NO_UPDATE_PERFORMED = 2 OTHERS = 3. * # Begin error handling IF SY-SUBRC <> 0. CALL FUNCTION 'VELO03_FILL_ERROR_TABLE' EXPORTING MSGID_IV = SY-MSGID

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 67 von 78

MSGTY_IV = SY-MSGTY MSGNO_IV = SY-MSGNO MSGV1_IV = SY-MSGV1 MSGV2_IV = SY-MSGV2 MSGV3_IV = SY-MSGV3 MSGV4_IV = SY-MSGV4 TABLES VLCH_MSSG_CT = VLCH_MSSG_CT. RAISE UPDATE_NOT_PERFORMED. * # End error handling ENDIF. *-----------------------------------------------------------------------


In einer Schleifenverarbeitung über alle Fahrzeuge werden die neuen Datensätze der VMS-Belegtabelle (hier: VLCCUORDER) in eine interne Tabelle geschrieben:

• Die Schlüsselfelder der VMS-Belegtabellen sind immer der Fahrzeugschlüssel VGUID und der Zeitstempel TSTMP; beide Felder werden wie im Coding-Beispiel der Struktur VLCDIAVEHI entnommen.

• Der Aktionsbelegtyp entspricht meistens dem Aktionskürzel der Standardaktion.

• Belegnummer und Positionsnummer müssen aus den Datenstrukturen des BAPIs entnommen werden.

• Der Ausführende der Aktion wird der Struktur VLCDIAVEHI entnommen.


Die interne Tabelle (hier: VLCCUORDER_LT) wird nun an den Verbuchungsbaustein übergeben, der die Datensätze in die VMS-Belegtabelle schreibt.

3.5.4.5 Verbuchung

• LUW (Logical Unit Of Work)

Die Kontrolle über die LUW muss beim Baustein VELO09_SET_ACTION liegen:

Die aktionsspezifischen EXECUTE-Bausteine dürfen keinen COMMIT absetzen; andernfalls kommt es zu Dateninkonsistenz.

Das heißt: SAP-Standardbausteine, die einen COMMIT absetzen, dürfen nicht im EXECUTE-Baustein aufgerufen werden. Weiterhin ist der SUBMIT <REPORT>-Befehl nicht erlaubt, da hierbei automatisch ein COMMIT abgesetzt wird. Ebenfalls völlig ungeeignet ist ein CALL TRANSACTION-Befehl, da die Kontrolle an eine andere Transaktion abgegeben wird.

• Verbuchungsbausteine im EXECUTE-Baustein nutzen

Datenbank-Updates werden im VMS grundsätzlich in separaten Verbuchungsbausteinen gekapselt. In den Bausteineigenschaften muss eingestellt sein: Verbuchungsbaustein; Start sofort.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 68 von 78

Die Verbuchungsbausteine werden mit dem Zusatz IN UPDATE TASK aufgerufen (Beispiel: 3.5.4.4). Dies bewirkt, dass der Baustein tatsächlich erst dann durchlaufen wird, wenn zu einem späteren Zeitpunkt der COMMIT-Befehl abgesetzt wird. Wenn Sie diese Bausteine debuggen möchten, müssen Sie im Debugger das Verbuchungs-Debugging einstellen.

• Synchron versus asynchron (siehe 1.3.2.2):

Einzelne Aktionen werden asynchron verbucht; das heißt: Wenn der Benutzer in der Transaktion VELO bereits die Meldung Aktion erfolgreich ausgeführt erhalten hat, ist der Verbucher möglicherweise noch beschäftigt.

Bei Verkettungsaktionen werden die einzelnen Elementaraktionen nacheinander ausgeführt und separat synchron verbucht. Erst wenn eine Elementaraktion verbucht ist, wird die folgende Elementaraktion gestartet.

Wenn Sie ein anderes Verhalten implementieren möchten, können Sie die COMMIT-Methode des BAdIs VLC_EXECUTE_ACTION implementieren.

3.5.4.6 Schreiben der Fahrzeugdaten

Damit Daten in die Fahrzeug- beziehungsweise Historientabelle geschrieben werden können, müssen sie im EXECUTE-Baustein in die interne Tabelle VLCDIAVEHI_CT geschrieben werden.

Das folgende vereinfachte Coding-Beispiel zeigt die entsprechenden Coding-Strecken im EXECUTE-Baustein der Aktion CUOR Kundenauftrag anlegen:

*----------------------------------------------------------------------- * Step C.2 * Write entries to the sales order table of the vehicle manager and to * the Vehicle table VLCDIAVEHI_CT LOOP AT VLCDIAVEHI_CT INTO VLCDIAVEHI_LS. * Find the correct line of VLCACDATA READ TABLE VLCACTDATA_ITEM_LT INTO VLCACTDATA_ITEM_LS WITH KEY VGUID = VLCDIAVEHI_LS-VGUID. * Vehicle data VLCDIAVEHI_LS-KUNNR = VLCACTDATA_HEAD_LS-KUNNR. VLCDIAVEHI_LS-CU_NAME1 = VLCACTDATA_HEAD_LS-KUNAM. VLCDIAVEHI_LS-ENDCU = VLCACTDATA_HEAD_LS-ENDCU. VLCDIAVEHI_LS-VHUSG = VLCACTDATA_HEAD_LS-VHUSG. VLCDIAVEHI_LS-VHUSGTXT = VHUSGT_LV. VLCDIAVEHI_LS-ACTDOCTYPE = ABA_CUOR_GC. MODIFY VLCDIAVEHI_CT FROM VLCDIAVEHI_LS INDEX LOOP_INDEX_LV. *----- ENDLOOP. " VLCDIAVEHI_CT

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 69 von 78

In einer Schleifenverarbeitung über die Fahrzeugtabelle werden Daten in die interne Tabelle VLCDIAVEHI_CT geschrieben. In der Regel werden die neuen Daten aus der Kommunikationsstruktur VLCACTDATA übernommen. Die Daten der Kopfstruktur VLCACTDATA_HEAD_LS gelten für alle Fahrzeuge, die Daten der Positionsstruktur VLCACTDATA_ITEM_LS immer nur für das aktuelle Fahrzeug.

Wenn in der Aktion ein Beleg angelegt wurde, muss der Aktionsbelegtyp gesetzt werden. Das bewirkt unter anderem, dass in der Transaktion VELO in der Fahrzeughistorie eine Beleg-Ikone angezeigt wird.

3.5.4.7 Füllen der Kommunikationsstruktur

Der EXECUTE-Baustein darf keinesfalls die VLCACTDATA_CS löschen, da sonst keine Verkettung der Aktionen möglich ist. Es dürfen aber Daten hinzugefügt werden.

3.5.4.7.1 Kopfdaten

Im EXECUTE-Baustein der Aktion CUOR Kundenauftrag anlegen wird zum Beispiel die Belegnummer des neu angelegten Auftrags in das Kopfsegment der Kommunikationsstruktur geschrieben. Das ermöglicht es, dass die Belegnummer nach der Aktionsausführung auf dem Aktionsscreen angezeigt wird.

************************************************************************ *** processing block C *** * * * Prepare the return data * ************************************************************************ * Step C.0 * Fill the document number into VLCACTDATA_HEAD_S for displaying on * dynpro VLCACTDATA_CS-VBELN = VBELN_LV.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 70 von 78

3.5.4.7.2 Positionsdaten

.... * PREPARE table containing existing old data of VLCACTDATA VLCACTDATA_ITEM_BEFORE_LT[] = VLCACTDATA_CS-ACTDATA_ITEM. * One line per vehicle ... LOOP AT VLCDIAVEHI_CT INTO VLCDIAVEHI_LS. * Don’t mix data of different vehicles CLEAR VLCACTDATA_ITEM_LS. * Use existing old data of VLCACTDATA_CS (This read does only find * entries in case of interlinked actions) READ TABLE VLCACTDATA_ITEM_BEFORE_LT INTO VLCACTDATA_ITEM_LS WITH KEY VGUID = VLCDIAVEHI_LS-VGUID. * Write GUID into the new VLCACTDATA (needed if VLCACTDATA_ITEM_LS is initial) VLCACTDATA_ITEM_LS-VGUID = VLCDIAVEHI_LS-VGUID. * Add action-specific data to VLCACTDATA_ITEM_LS .... * Add line to new VLCACTDATA APPEND VLCACTDATA_ITEM_LS TO VLCACTDATA_ITEM_AFTER_LT. ENDLOOP. " VLCDIAVEHI_CT INTO VLCDIAVEHI_LS * Replace old VLCACTDATA by new VLCACTDATA. Contains the entries of the * old VLCACTDATA and in addition data of the action. CLEAR VLCACTDATA_CS-ACTDATA_ITEM. VLCACTDATA_CS-ACTDATA_ITEM[] = VLCACTDATA_ITEM_AFTER_LT[]. ....

• Zunächst wird das Feld VLCACTDATA_CS-ACTDATA_ITEM (Positionsdaten) in die BEFORE-Tabelle geschrieben.

• Aus dieser alten VLCACTDATA-Version wird nun – falls vorhanden – die Zeile gelesen, die zum aktuellen Fahrzeug passt. Die Zeile wird mit den aktionsspezifischen Daten angereichert (insbesondere mit der GUID) und an die AFTER-Tabelle angehängt.

• Anschließend wird das Feld VLCACTDATA_CS-ACTDATA_ITEM gelöscht und mit der AFTER-Tabelle überschrieben.

Durch dieses Verfahren ist sichergestellt, dass die Tabelle nicht aktualisiert wird, sondern dass sie nur mit zusätzlichen neuen Daten angereichert wird. Das ist bei Verkettung von Aktionen von Bedeutung.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 71 von 78

3.5.5 Aufruf

In der Transaktion SE18 wird für das BAdI VLC_EXECUTE_ACTION eine Implementierung angelegt. In der BAdI-Methode EXECUTE_FURTHER_ACTIONS wird der aktionsspezifische EXECUTE-Baustein aufgerufen. Coding-Beispiel:

********************* CASE - LOOP on all actions ********************* CASE ACTION_TO_BE_PERFORMED_IV. WHEN ‘<Aktionskürzel1>’. " Customer’s first action ! *::::::::::::::::::::::::: ACTION: <Aktionskürzel> ::::::::::::::::::::::::: CALL FUNCTION '<FugrName>_<Aktionskürzel1>_EXECUTE' EXPORTING DIALOGUE_ALLOWED_IV = DIALOGUE_ALLOWED_IV TABLES VLCDIAVEHI_CT = VLCDIAVEHI_CT VLCH_MSSG_CT = VLCH_MSSG_CT VLCBAPICU_IT = VLCBAPICU_IT CHANGING VLCACTDATA_CS = VLCACTDATA_CS EXCEPTIONS ACTION_NOT_PERFORMED = 1 UPDATE_NOT_PERFORMED = 2 OTHERS = 3. IF SY-SUBRC <> 0. * The error message(s) are written into VLCH_MSSG_CT by the * function module RAISE ACTION_NOT_PERFORMED. ENDIF. WHEN ‘<Aktionskürzel2>’. " Customer’s second action ! *:::::::::::::::::::::::: ACTION: <Aktionskürzel2> :::::::::::::::::::::::: ... usw. ENDCASE.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 72 von 78

3.6 Absprung aus der Fahrzeughistorie in Beleg einrichten

Wenn das System eine Aktion ausführt, wird automatisch ein Eintrag in die Historientabelle geschrieben.

Wenn die Aktion einen Beleg angelegt hat, wird dies im Historieneintrag durch eine spezielle Beleg-Ikone angezeigt. Die Verknüpfung zwischen Fahrzeug und Belegnummer/Position ist in der zugehörigen VMS-Belegtabelle gespeichert. Klickt nun der Benutzer auf die Beleg-Ikone, so wird der Beleg aus der VMS-Belegtabelle ermittelt und automatisch in der zugehörigen Transaktion angezeigt.

Dieses Verhalten wird im Funktionsbaustein VELO04_READ_TRANSCALLDATA gesteuert. In Abhängigkeit vom vierstelligen Aktionsschlüssel wird gesteuert, ob ein zugehöriger Standardbeleg angezeigt wird oder ob eine Meldung erscheint, die besagt, dass es zu dem ausgewählten Historieneintrag keinen Standardbeleg gibt.

Der Funktionsbaustein VELO04_READ_TRANSCALLDATA ruft ein BAdI auf, in dem Sie Kundenerweiterungen implementieren können; dies ist insbesondere dann notwendig, wenn Sie eine kundeneigene VMS-Belegtabelle angelegt haben.

Der Absprung von einem Eintrag der Historientabelle in eine Transaktion zum Anzeigen des Belegs wird im BAdI VLC_HISTORY_CALL_TRA implementiert.

Die Beleg-Ikone wird dann automatisch angezeigt, wenn im EXECUTE-Baustein der Aktion, die den Beleg anlegt, das Feld ACTDOCTYPE der Tabelle VLCDIAVEHI_CT gefüllt wurde.

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 73 von 78

4 Anhang

4.1 Tabellen im VMS

4.1.1 Bewegungsdaten

Bewegungsdatentabelle Beschreibung

VLCVEHICLE VELO : Fahrzeug

VLCADDDATA VELO : Qualifierdaten zum Fahrzeug

VLCADDCFG VELO : Zusätzliche Fahrzeugkonfiguration, nicht suchrelevant

VLCHISTORY VELO : Fahrzeughistorie

VLCCUORDER VELO : Kundenauftrag

VLCDELIVERY VELO : Lieferung

VLCGISSUE VELO : Materialbeleg / Warenausgang

VLCGMOVEM VELO : Materialbelege (Sonstige)

VLCGRECEIPT VELO : Materialbeleg / Wareneingang

VLCINCINVOICE VELO : Eingangsrechnung

VLCINQUIRY VELO : Anfrage

VLCINVOICE VELO : Ausgangsrechnung

VLCOFFER VELO : Angebot

VLCPORDER VELO : MM-Bestellung

VLCRCSTRORD VELO : Lohnbearbeitungsbestellung / Umbau

VLCRESERVATION VELO : Reservierung

VLCDEAEND VELO : Verknüpfung zwischen Händler und Endkunde

VLCIDGU VELO : Zuordnung von Fahrzeug zu IDoc-Nummer

VLC_DBCONSTATUS VELO : Status der liveCache-Anbindung (obsolet)

CVLC_TSTMP VELO : Zeitpunkt der letzten BW-Extraktion

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 74 von 78

4.1.2 Stammdaten

Stammdatentabelle Beschreibung

CVLC05 VELO : Steuertabelle Objektmerkmale

CVLC20 VELO : Filterdefinition IBase => liveCache (obsolet)

CVLC23 VELO : Organisationsdaten zu VMS-Rollen zuordnen

CVLC24 VELO : Fahrzeugmodelle zu VMS-Rollen zuordnen

CVLC25 VELO : Benutzer zu VMS-Rollen zuordnen

VLCCHPROFIND VELO : Findung des Konfigurationsänderungsprofils

VLCCHPROHEAD VELO : Konfigurationsänderungsprofile

VLCCHPROHEADT VELO : Text zu VLCCHPROHEAD

VLCCHPROITEM VELO : Konfigurationsänderungsprofile: Merkmalzuordnung

VLCFINDCNTRL VELO : Findung der Aktionssteuerung

VLCSCAMPGN VELO : Verkaufskampagne

VLCSCAMPGNT VELO : Text zu VLCSCAMPGN

CVLC_CHAR_LINK VELO : Zuordnung von Klassenmerkmalen zu BW-Merkmalen

VLCSEARCHPROF VELO : Profile für Fahrzeugsuche

VLCSEARCHPROFT VELO : Texttabelle: Profile für Fahrzeugsuche

VLCSEARCHFIELD VELO : Suchfelder (Selections) Fahrzeugsuche (für Profil)

VLCSEARCHCHAR VELO : Suchfelder (Merkmale) Fahrzeugsuche (für Profil)

VLCBATCHACT VELO : Variante für Aktionsausführung im Batch

4.1.3 Customizing-Tabellen

Customizing-Tabelle Beschreibung

CVLC01 VELO : Aktionssteuerung

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 75 von 78

CVLC01T VELO : Text zu CVLC01

CVLC02 VELO : Fahrzeugstatus


CVLC03 VELO : Aktionen


CVLC03I VELO : Verkettungsaktionen

CVLC04 VELO : Aktionsmatrix

CVLC06 VELO : Aktueller Standort


CVLC11 VELO : Verfügbarkeit, Standorte, geplantes Auslieferungsdatum

CVLC12 VELO : Status - Verfügbarkeit, Standorte, geplantes Auslieferungsdatum

CVLC10 VELO : Verfügbarkeitsstatus


CVLC13 VELO : Fahrzeugverwendung


CVLC14 VELO : Aktionsfindung über externen Status

CVLC15 VELO : Externer Status

CVLC15T VELO : Texte zu CVLC15

CVLC16 VELO : Zuordnen von Qualifiern zu Aktionen

CVLC17 VELO : Zuordnen von Fahrzeugattributen zu Aktionen

CVLC18 VELO : Fahrzeugsuchbereich


CVLC18V VELO : Fahrzeugsuchbereich - Verkaufsorganisation

CVLC18W VELO : Fahreugsuchbereich - Werk

CVLC19 VELO : VMS-Rollen definieren


CVLC21 VELO : Kategorien zuordnen

CVLC22 VELO : Nachrichtenschemata zu Werk zuordnen

CVLC26 VELO : Eigene Dialogmeldungen zuordnen

CVLC27 VELO : Zugriffsrecht bei Fahrzeugsuche


CVLCQUA VELO : Qualifier definieren

CVLCQUAT VELO : Text zu CVLCQUA

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 76 von 78

4.1.4 Steuertabellen

Steuertabelle Beschreibung

VLCSEARCHCONTROL VELO : Steuerungstabelle Suchfunktionalität

VLCGUIDTABLES VELO : Auflistung der suchrelevanten GUID-VMS-Tabellen

VLCVALIDFIELDS VELO : Gültige Fahrzeugattribute aus der VLCDIAVEHI Struktur

4.2 Richtlinien bei der Entwicklung des VMS

Bei der Entwicklung des VMS und der zugehörigen Aktionen wurden weitgehend unten beschriebene Richtlinien eingehalten. Dies erleichtert die Suche, das Lesen und Verstehen der einzelnen Objekte und Codierungen. Bei kundeneigenen Entwicklungen kann auf diese Richtlinien aufgebaut werden.

Definition von Objekten:

• Entwicklungssprache: DE

• Entwicklungskürzel: VLC

• Entwicklungsklasse: ISAUTO_VLC

• DB-Tabellen: sechsstellig, beginnend mit VLCxxx, dazugehörige Texttabellen VLCxxxT

• Customizing-Tabellen: siebenstellig, beginnend mit CVLCxxx, dazugehörige Texttabellen CVLCxxxT

• Strukturen: achtstellig, beginnend mit VLCxxxxx

• Views: sieben- oder achtstellig, beginnend mit V_VLCxxx

• Customizing-Views: V_CVLCxx

• Viewcluster: VC_VLCxxx

• Datenelemente: beginnend mit VLC.....

• Domänen: beginnend mit VLC.....

• Sperrobjekte: E_VLCxxx

• Funktionsgruppen: VELOXX

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 77 von 78

• Funktionsbausteine: VELOXX_<OBJEKT>_<FUNKTION>_<ZUSATZ>

• Reports: zehnstellig, RVLCxxxxxx

• Modulpools: zehnstellig, SAPMJITxxx

• Nachrichtenklasse: fünfstellig, VELOx

• Transaktionscodes: fünfstellig, beginnend mit VELOx

• Customizing-Trx: sechsstellig, beginnend mit OVLCxx

• SET/GET-Parameter beginnend mit VELO_

• Form-Routinen: beginnend mit VLC_

• Includes: beginnend mit LVLC....

• Includes / Constants: beginnend mit LVLCXXCON

Definition von Variablen:

Bei der Definition der Variablen wurde weitgehend die Vorgabe des ABAP Style Guide umgesetzt:

• Variablennamen

- Name + Verwaltungsart + Typ

• Verwaltungsart

- Import (i)

- Export (e)

- Changing (c)

- Tables (t)

- Local (l)

- Global (g)

- Statics (s)

- Parameter (p)

• Typ

- Variable (v)

- Table (t)

- Structure (s)

- Constant (c)

- Field (f)

• Beispiel

- number_iv, counter_lv, jitcu_gt, ...

Allgemeine Richtlinien (weitgehend gültig):

SAP®

© 2003 SAP AG

Neurottstr. 16

D-69190 Walldorf


Version: 5.0

Datum: 26.03.2003

Seite 78 von 78

• DD-Tabellen (TABLES-Anweisung) immer global deklarieren, am besten jedoch auf TABLES-Anweisung verzichten, nur wo dringend erforderlich (zum Beispiel Dynpros, siehe globale Variablen)

• Anstelle von: data vlcvehicle_lt like jitit occurs 0 with header line, besser: data vlcvehicle_lt like vlcvehicle occurs 0 und zusätzlich data vlcvehicle_ls like vlcvehicle (also keine Itabs mit Kopfzeile benutzen, stattdessen wa & Itab ohne Kopfzeile)

• Anzahl globaler Variablen minimieren – globale Variablen nur einsetzen, wenn unbedingt notwendig und sinnvoll (Datenpufferung, ALV, Dynpros, ...)

• Versteckte Übergabe (globale Variable) unbedingt vermeiden

• Externe Formcalls sind verboten (innerhalb Funktionsgruppe möglich, ansonsten durch Funktionsbaustein)

• Alle Namen in Englisch, sprechende Namen verwenden, auch Feldnamen von Tabellen und Strukturen

• Kommentare in Englisch –gut und ausführlich kommentieren, im Zweifelsfall deutsch und englisch kommentieren

• Suchhilfen (DDIC) verwenden (anstelle von Helpviews, Matchcodes usw.)

• Maximal eine Anweisung pro Zeile (gut beim Debugger, auch übersichtlicher)

• Allgemein verwendbare Programmteile in Funktionsbausteine auslagern (jedoch nicht atomisieren!)

• Auskommentiertes Coding vermeiden

• Isolierbare Teilaufgaben isolieren, auf Wiederverwendbarkeit programmieren

• Alle Dynprofelder im DDIC definieren

• Globale Arbeitsfelder im DDIC definieren

• Für jede Form-Routine ein eigenes Include verwenden (max 500 Zeilen Coding ist besser!)

• JEDE Fehlermeldung nach oben bringen. Kein RAISE verwenden, sondern MESSAGE .... RAISING

Vehicle Management System: Aktionserstellung - SAP...Version: 5.0 Datum: 26.03.2003 Autor: SAP AG...

Documents

Transcript of Vehicle Management System: Aktionserstellung - SAP...Version: 5.0 Datum: 26.03.2003 Autor: SAP AG...