Sie können neue Tabellen in der Materialstammpflege ohne Modifikationen an den Programmen des Materialstamms einbinden.

Die Vorgehensweise für die Aufnahme neuer Felder in bestehende Tabellen ist im Hinweis 44410 beschrieben.

Diese Dokumentation stützt sich insbesondere auf die Möglichkeiten, Anzahl und Aussehen der Haupt- und Nebenbilder des Materialstamms durch den Benutzer zu definieren.

Der Materialstamm sollte Ihnen in seinen Grundzügen vertraut sein.

Sie haben dazu die Customizingeinstellungen in Logistik Allgemein ® Materialstamm ® Konfigurieren des Materialstamms zur Gestaltung der Bilder verwendet. Sie können Bildsequenzen definieren, die eine Folge von Haupt- und Nebenbildern enthalten. Jede Bildsequenz repräsentiert eine Darstellungsform des Materialstamms.

Bei der Integration neuer Tabellen in den Materialstamm sind folgende Anforderungen zu unterscheiden

• teilweise Integration

Die Pflege der Daten muss aus dem Materialstamm heraus erfolgen können. Dabei ist durch die Art der Integration erkennbar, dass es sich hier um ein eigenständiges Objekt handelt, d.h. der Benutzer erwartet nicht, dass die gleiche Funktionalität für die integrierten Daten zur Verfügung steht, wie für die Materialstammdaten (z.B. Feldauswahl, Vorlagehandling, etc.). Durch die Integration soll lediglich eine Pflegevereinfachung für den Benutzer erreicht werden.

• vollständige Integration

Für den Anwender soll nicht erkennbar sein, dass es sich nicht um eine Tabelle des Materialstamms handelt. Die Integration ist also für den Anwender nicht sichtbar, sie unterscheidet sich lediglich technisch von der Einbindung als eigene Materialstammtabelle. Entsprechend sind alle Pflegefunktionen, die für Materialstammdaten verfügbar sind, auch für die integrierten Daten verfügbar.

Die teilweise Integration wird vor allem für solche Daten gewählt, die nicht zwingend für jedes Material gepflegt werden müssen, die zusätzliche Daten sind, die nicht zwingend als Teil des Materialstamms betrachtet werden, z.B. Fertigungsversionen zu einem Material.

Die vollständige Integration wird für solche Daten gewählt, die für alle oder viele Materialien gepflegt werden müssen, die von ihrer Eigenschaft her im Grunde ganz normale Materialstammtabellen darstellen (keine Zusatzdaten) und bei denen der Anwender bewusst keine Unterscheidung zu anderen Materialstammdaten sehen soll, z.B. Bedarfsgruppen zu einem Material (nur im Retailumfeld verfügbar).

Entsprechend der unterschiedlichen Anforderungen an die Integration gibt es auch unterschiedliche Wege der Realisierung:

• Realisierung bei teilweiser Integration

Bei der teilweisen Integration kann die Pflege der neuen Tabelle nur in einem eigenen Bild erfolgen (Nebenbild). Das Bild auf dem die neuen Daten gepflegt werden, hat einen eigenen GUI-Status, unterscheidet sich also von den Bildern des Materialstamms durch Funktionen in der Menüleiste und der verfügbaren Drucktasten. Man kann insbesondere nicht von dem Bild direkt auf andere Materialstammbilder springen und man kann das Bild nicht als eigenes Hauptbild oder als Subscreen auf einem bestehenden Hauptbild unterbringen. Es sind ebenfalls nicht zwingend alle Pflegefunktionen für die integrierten Daten verfügbar.
Das Nebenbild kann entweder über das Menü Zusätze oder über eine Drucktaste geöffnet werden.

• Realisierung bei vollständiger Integration

Bei der vollständigen Integration kann die Pflege der neuen Tabelle wie bei anderen Materialstammtabellen folgendermaßen integriert werden:

• Subscreen (Bildbaustein) auf einem bestehenden Hautbild oder Zusatzbild
  eigenes Hauptbild
• Zusatzbild, das nur über das Menü Zusätze ausgewählt werden kann
• Zusatzbild, das durch Anwählen einer Drucktaste geöffnet wird (und über das Menü Zusätze auswählbar ist)
  Es wird dabei der gleiche GUI-Status wie für die Materialstammbilder verwendet.

Die teilweise Integration ist einfacher als die vollständige Integration. Für die vollständige Integration gibt es außerdem noch einige Einschränkungen:

Zunächst wird die Vorgehensweise für die vollständige Integration beschrieben, bei der teilweisen Integration wird nur noch auf die relevanten Punke hingewiesen.

Für die Integration neuer Objekte stehen die Methoden des BAdIs BADI_MATERIAL_OD zur Verfügung, von denen die anwendungsspezifischen Funktionsbausteine der integrierten Objekte gerufen werden können. Die BAdI-Methoden stellen die erforderlichen Daten bereit, die der Anwendungsbaustein in der jeweiligen Situation benötigt. Die Integration kann auf diese Weise so erfolgen, dass die integrierten Daten im Materialstamm nicht bekannt sein müssen. Die gesamte Logik sowie die zugehörigen Daten sind in den anwendungsspezifischen Funktionsbausteinen zu kapseln.

Als Beispiel für die Integration werden zum einen die im Retail integrierten Bedarfsgruppen angeführt (Funktionsgruppe WRPP). Diese Daten werden auf Ebene des Materials gepflegt (alle Bedarfsgruppen zu einem Material werden in einem Bild gepflegt). Als Beispiel für die Integration von Daten auf Ebene Material/Werk werden die im Retail integrierten Nachschubparameter angeführt (Funktionsgruppe WRPL), da gerade bei der Integration werksspezifischer Daten im Retail-Materialstamm die Problematik der Vorlagebetriebe berücksichtigt werden muss (vgl. Punkt Vorlagehandling). Die Bildbausteine für beide Datentabellen (WRPP und WRPL) sind in der Funktionsgruppe WRPD zu finden.

perform init_baustein.

Die Form-Routine ist in einem Standard-Include des Materialstamms definiert.

Innerhalb der Funktionsgruppe können wie gewohnt Dynpros mit PBO- und PAI-Logik entwickelt werden. Auf eine besondere Nummerierung muss keine Rücksicht genommen werden. Bei der Entwicklung sind folgende Punkte zu beachten.

Die Eigenschaft des Materialstamms, für den Kunden customizebar zu sein, beruht im wesentlichen auf dem Konzept der Datenpufferung und dem Transport der Daten zwischen Subscreens, die zu verschiedenen Programmen gehören können. Im folgenden wird das Konzept kurz beschrieben:

Zum Zeitpunkt PAI soll die Prüfung der Daten stattfinden. Wenn die Prüfroutinen eine fehlende Konsistenz der Daten melden, darf das Bild nicht verlassen werden. Der Anwender muss seine Eingaben korrigieren. Verwendet man für die Ausgabe von Fehlermeldungen E-Meldungen, so stellt das System sicher, dass das Bild erst nach Korrektur des Fehlers verlassen werden kann.

Dieser Fall kann auch bei Warnungen auftreten (nicht alle betroffenen Felder befinden sich auf einem Subscreen). Auch in diesem Fall muss die Meldung als S-Meldung ausgegeben werden, aber zusätzlich muss die sonst vom System bereitgestellte Warnungslogik (Warnung kann bestätigt werden, Bild kann trotzdem verlassen werden) entsprechend programmiert werden (durch ein Flag sicherstellen, dass die Warnung bei unveränderter Eingabe (!) nur einmal hochkommt; beachte: wenn die Daten zwischenzeitlich verändert wurden, muss die Warnung wieder ausgegeben werden).

Prüfungen sollten immer als Funktionsbaustein implementiert werden, da sie auch nach dem Speichern in der Buchungslogik noch mal aufgerufen werden. Bei der Erstellung von Prüfbausteinen für die Prüfung der Eingaben ist folgendes zu beachten:

• Ein Prüfbaustein muss Meldungen für Fehler- und Warnungsfall erzeugen.
• Im Fehlerfall sollte der Baustein mit message raising verlassen werden.

Falls der neue Subscreen ein Step-Loop-Dynpro mit eigenen Funktionscodes zum Blättern enthält (beachte: die Funktionscodes zum Blättern müssen ebenso wie andere Funktionscodes eindeutig sein), so muss die Anwendung nach der Bearbeitung des Funktionscodes das Bildflag setzen (sonst wird auf das nächste Bild gesprungen) und den Funktionscode zurücksetzen.

Folgende Module sind standardmäßig in der PBO-Logik eines Subscreens enthalten.

• MODULE INIT_SUB

Initialisierung; muss immer vorhanden sein

• MODULE GET_DATEN_SUB

Datenbeschaffung der Materialstammdaten aus den Zwischenpuffern (Workarea); muss immer vorhanden sein

• MODULE FELDAUSWAHL

Feldauswahl für Materialstammfelder (T130F)

• MODULE SONDERFAUS

Sonderfeldauswahl für Materialstammfelder

• MODULE SONDERFAUSW_IN_FGRUPPEN

Sonderfeldauswahl für Felder mit Sonderfeldgruppe

• MODULE FAUSW_BEZEICHNUNGEN

Feldauswahl für die Bezeichnungen (wenn ein Datenfeld ausgeblendet wird, so muss auch die zugehörige Bezeichnung ausgeblendet werden)

• MODULE BILDSTATUS

Setzen des Bildstatus

• MODULE FELDHISTORIE

Änderungsdienst (deaktiviert)

• MODULE ZUREF_VORSCHLAGEN_B
  (nur Industrie)

Vorschlagshandling für Materialstammfelder im Industriefall

• MODULE REFDATEN_VORSCHLAGEN

Vorschlagshandling für Materialstammfelder im Industriefall

• MODULE ZUREF_VORSCHLAGEN_A
  (nur Industrie)

Vorschlagshandling für Materialstammfelder im Industriefall

• MODULE BEZEICHNUNGEN_LESEN

Lesen der Bezeichnungen zu den Datenfeldern

• MODULE BEZEICHNUNGEN_LESEN_RT
  (nur Retail)

Vorschlagshandling für Materialstammfelder für Retailfelder

• MODULE SET_DATEN_SUB

Zurückschreiben der Materialstammdaten in den Zwischenpuffer (Workarea)

Die Module für das Vorlagehandling sind nur im Industriefall auf jedem Subscreen enthalten, im Retailfall taucht das Modul nur in den Header-Subscreens (Subscreens mit Keyfeldern) auf, da die Vorlagelogik dort nicht je Subscreen, sondern nur einmal je Bild erfolgt. Für die eigenen Tabellen muss ebenfalls eine Vorschlagslogik programmiert werden, die sich an der Logik des Industrie-Materialstammes bzw. der dazu unterschiedlichen Logik des Retail-Materialstammes orientiert. Die Vorschlagslogik für die zu integrierende Tabelle sollte als Funktionsbaustein gekapselt werden, da auch dann ein Vorschlag erstellt wird, wenn der Subscreen nicht durchlaufen wird und diese Logik in diesem Fall in der Buchungslogik laufen muss.

Im Vorschlagshandling für neue Tabellen ist zu beachten, dass der Vorschlag für eine Tabelle (bzw. Tabelle und Pflegestatus) nur einmal beim Neuanlegen der Daten abläuft. Es dürfen natürlich nicht vom Benutzer durchgeführte Änderungen überschrieben werden.

Folgende Module sind standardmäßig in der PAI-Logik eines Subscreens enthalten

• MODULE GET_DATEN_SUB

Datenbeschaffung der Materialstammdaten aus den Zwischenpuffern (Workarea)

• MODULE SET_DATEN_SUB

Zurückschreiben der Materialstammdaten in den Zwischenpuffer (Workarea)

Im Retail-Materialstamm (nicht im Indutrie-Materialstamm) gibt es eine Massenpflege in der Art, dass Daten zu einem Material gleichzeitig für mehrere Organisationsebenen (z.B. Werke) gepflegt werden können. Außerdem gibt es das Konstrukt des Sammelmaterials mit untergeordneten Varianten, wobei Daten, die auf Ebene des Sammelmaterials gepflegt werden, automatisch an alle Varianten weitergegeben werden. Daten von einer übergeordneten Ebene werden dabei nur dann auf die zugehörigen untergeordneten Ebenen durchgereicht, wenn die untergeordnete Ebene nicht abweichend gepflegt wurde.

Um Abweichungen festzuhalten, werden sogenannte Abweichungszeiger fortgeschrieben (Tabelle MABW). Sie zeigen an, ob eine Abweichung zur entsprechenden Vorlage besteht und werden für jede Art von Organisationsebene geschrieben (siehe Tabelle MABW).
Beispiel: Für eine Variante wurden die Verkaufsdaten (Ebene Vertriebslinie) abweichend vom Sammelmaterial gepflegt. Zu Variante und Vertriebslinie wird ein Abweichungszeiger geschrieben. Die Daten sind auch im Abweichungsfall durchzureichen, aber nur für die nicht unterschiedlich gepflegten Felder.

Durch einen Button können die Abweichungen angezeigt werden (zu einem bestimmten Bild und damit Organisationsebene).

Es müssen auch Daten, die über einen Wechsel des Gültigkeitsbereichs neu eingelesen werden (also zum Zeitpunkt des Durchreichens noch nicht im Puffer waren), an die eventuelle Änderung angepasst werden (Beispiel: Daten von abhängigen Werken werden an die Daten des Vorlagewerks angepasst. Es werden nur die Werke angepasst, für die sich die Daten im Puffer befinden, alle anderen werden erst im Buchen angepasst. Werden jetzt Daten zu einem Werk eingelesen, das zuvor noch nicht im Puffer war, so müssen die Daten für dieses Werk an das Vorlagewerk angepasst werden). Diese Logik sollte von dem entsprechenden Funktionsbaustein zur Erstellung des Vorschlags mit erledigt werden (Unterscheidung zwischen Vorschlag erstellen oder Durchreichen).

WRPP_GET_DIFFERENCES, WRPL_GET_DIFFERENCES

Wenn die Ebene, auf der die neuen Daten gepflegt werden, zu keiner der bestehenden Ebenen passt, auf denen Abweichungen geschrieben werden, so muss die Anwendung eigene Abweichungszeiger schreiben und anzeigen.

Für die Verbuchung der Daten werden drei Funktionen benötigt:

Die Funktionsbausteine können die benötigten Daten aus den Puffern der Funktionsgruppe lesen.

Folgende Möglichkeiten für die Integration in die Pflegeoberfläche des Materialstamms sind möglich:

• Subscreen (Bildbaustein) auf einem bestehenden Hauptbild oder Nebenbild

• eigenes Hauptbild

• Nebenbild, das nur über das Menü ‚Zusätze‘ angewählt werden kann (Zusatzbild)

• Nebenbild, das durch Anwählen einer Drucktaste geöffnet wird

Die Entscheidung, ob ein neues Bild als Haupt- oder als Nebenbild eingebunden wird, wird bei Anlegen eines neuen Bildes über die Einstellung des Bildtyps getroffen. Handelt es sich um ein Hauptbild, so kann die Reihenfolge, in der die Hautbilder durchlaufen werden, eingestellt werden. Handelt es sich um ein Nebenbild, so kann entschieden werden, ob das Bild über eine Drucktaste oder über das Menü Zusätze aufrufbar ist. Ins Menü Zusätze gehören normalerweise nur die Funktionen, die für alle Bilder relevant sind. Alle anderen sollten als Drucktasten realisiert werden.

Generell soll für jedes Nebenbild eine OKCODE-Routine erstellt werden, unabhängig davon, ob das Bild in der Bildsequenz als Zusatzbild oder über Drucktaste aufgerufen wird. Die OKCODE-Routine ist in der eigenen Funktionsgruppe zu implementieren. Für den Aufruf der OKCODE-Routine muss mittels der BAdI-Methode SET_PROGRAM_FOR_OKCODE_ROUTN der Name des eigenen Programms der Ablaufsteuerung des Materialstammes bekannt gemacht werden.

Die OKCODE-Routine wird dem Nebenbild in der OMT3 zugeordnet. Bei vollständiger Integration enthält die OKCODE-Routine in der Regel nur die Prüfung, ob die integrierten Daten überhaupt gepflegt werden dürfen (s.u.).

Zur Prüfung, ob die zu integrierenden Daten überhaupt gepflegt werden dürfen, muss ein Prüfbaustein erstellt werden. Dieser Baustein wird an mehreren Stellen verwendet

• innerhalb des (eigenen) Moduls zur Feldauswahl, um zu entscheiden, ob die neuen Daten ausgeblendet werden müssen

• bei Anwahl über Drucktaste zur Entscheidung, ob die Drucktaste unsichtbar gesetzt werden muss
  Falls die Drucktaste nur sichtbar sein soll, wenn eine bestimmte Materialstamm-Tabelle für das Bild relevant ist, so sollte der Name der Drucktaste mit dem Tabellennamen beginnen (z.B. MARC_QM_PUSH). In diesem Fall wird die Drucktaste durch die Standard-Feldauswahl automatisch ausgeblendet, wenn die entsprechende Tabelle auf dem Bild nicht relevant ist.

• bei Anwahl über einen Menüpunkt zur Entscheidung, ob der entsprechende Menüpunkt inaktiv gesetzt werden muss. Der Aufruf erfolgt durch die BAdI-Methode PF_STATUS_SETZEN.

• in der OKCODE-Routine des Nebenbildes

Bei der teilweisen Integration ist die Pflege der Daten nur innerhalb eines eigenen Nebenbildes möglich. Das Nebenbild kann entweder über das Menü Zusätze oder über eine Drucktaste geöffnet werden

Im Unterschied zur vollständigen Integration sind diesen Nebenbildern nicht über die OMT3 entsprechende Subscreens zugeordnet, sondern das Dynpro, das bei Aufruf des Nebenbildes erscheint, ist ein fixes Dynpro, das nicht vom Benutzer bezüglich seiner Darstellung beeinflusst werden kann. Insbesondere hat das Bild einen eigenen GUI-Status, der vom GUI-Status der Materialstammbilder abweicht. Entsprechend kann von diesem Bild auch nicht direkt auf andere Bilder des Materialstamms gesprungen werden.

Technisch ist die Realisierung solcher Nebenbilder völlig gekapselt. Der Aufruf des Bildes erfolgt über die OKCODE-Routine, die dem Bild zugeordnet ist.

Auch bei der teilweisen Integration werden die benötigten Dynpros und die zugehörigen Funktionen in einer eigenen Funktionsgruppe entwickelt. An diese Funktionsgruppe werden aber keine speziellen Anforderung gestellt wie bei der vollständigen Integration.

Generell gilt, das sich die Anwendung trotz der Kapselung bei teilweiser Integration nach Möglichkeit an die Vorgehensweise und Funktionalität des Materialstamms annähern sollte.

Im folgenden werden die wesentlichen Punkte für die Dynprologik noch mal kurz aufgeführt.

• Für die Datenbeschaffung und die Datenpufferung können eigene Routinen verwendet werden. Trotzdem sollten natürlich auch in diesem Fall sinnvolle Punkte aus dem obigen Konzept realisiert werden (z.B. Daten nur einmal von der Datenbank lesen, ansonsten aus Puffern).

• Falls Zugriffe auf Materialstammtabellen benötigt werden, sollten die Funktionsbausteine des Materialstamms verwendet werden (siehe Funktionsgruppen im Paket MGA bzw. MGW; z.B. MG21 für Zugriffe auf die Tabelle MARA). Auch hier sind entsprechende Berechtigungen zu beachten, falls die Daten zur Anzeige gebracht werden sollen.

• Die Prüfung der Daten sollten sinnvollerweise auch hier über eigene Funktionsbausteine realisiert werden.

• An die Funktionscodes des Nebenbildes werden keine Anforderungen gestellt.

• Ob eine Feldauswahl erforderlich ist, muss die Anwendung entscheiden.

• Ob ein Vorlagehandling erforderlich ist, muss ebenfalls die Anwendung entscheiden.

• Ob das Durchreichen von Daten (Massenpflege) und dementsprechend auch das Abweichungshandling erforderlich ist, muss ebenfalls die Anwendung entscheiden.

Für die Einstellungen der OMT3 gilt das oben Gesagte. Bei der Teilweisen Integration ist aber nur eine Integration als eigenes Nebenbild möglich.

Die Übernahme und Verteilung der neuen Materialdaten erfolgt über ALE und entsprechende IDocs (ab 4.0A über BAPIs). Die benötigten IDocs, sowie Funktionen zum Erstellen, Einbuchen und manuellen Senden von IDocs sind von der jeweiligen Anwendung zu erstellen. Auch für die benötigten ALE-Customizing-Einstellungen hat die Anwendung zu sorgen (Änderungspointer, etc.).

Durch die vom ALE bereitgestellte Serialisierung von Nachrichtentypen wird das Einbuchen im Zielsystem in der richtigen Reihenfolge sichergestellt (zuerst das Material, dann die abhängigen Objekte). Hierfür sind entsprechende Customizing-Einstellungen zu erstellen.

Die Reorganisation bzw. Auslistung von integrierten Daten erfolgt mit Hilfe von entsprechend erforderlichen Funktionsbausteinen in den Reorganisationsprogrammen des Materialstamms. Dazu werden folgende Funktionsbausteine für die zu integrierenden Tabellen benötigt:

• Ein Prüfbaustein, mit dem überprüft werden kann, ob zu dem Material noch entsprechende Daten vorhanden sind bzw. ob diese Daten reorganisiert werden können (ggf. Löschvormerkungen prüfen). Dieser Baustein wird vom Materialreorganisation (Industriefall) bzw. von der Auslistung (Retailfall) aufgerufen. Nur wenn keine abhängigen Daten mehr zu dem Material existieren, kann das Material reorganisiert werden. Der Baustein ist optional und wird nur benötigt, wenn eine entsprechende Prüfung für das Objekt erforderlich ist.

• Ein Baustein, der die Archivierung der integrierten Daten vornimmt.

• Ein Baustein, der die Daten physisch löscht.

Dazu können die Methoden des BAdIs BADI_MM_MATNR genutzt werden. Für weitere Informationen wird auf die Dokumentation des BAdIs verwiesen.

Wenn auf Ebene der zu integrierenden Daten eigene Löschvormerkungen benötigt werden, ist eine Funktion zum Setzen von Löschvormerkungen bereitzustellen. Hierbei ist zu beachten, dass im Materialstamm die Löschvormerkungen von der Materialebene an die abhängigen Objekte weitergereicht werden. Entweder muss bei eigenen Löschvormerkungen das neue Objekt in diese Durchreichelogik integriert werden, oder bei es müssen bei Prüfung der Löschvormerkung für das integrierte Objekt die entsprechenden hierarchisch darüberliegenden Löschvormerkungen abgefragt werden.

In der Regel werden die Löschvormerkungen für das Material ausreichen.

Zur Dokumentation der Änderung von Daten werden bei jeder Veränderung einzelner Felder einer Tabelle im Regelfall Änderungsbelege fortschreiben. Dazu muss für die Tabelle ein Änderungsbelegobjekt erzeugt werden. Das Erstellen der Änderungsbelege geschieht im anwendungsspezifischen Verbuchungsbaustein durch den Aufruf der durch das System generierten Form-Routine.

Zum Anzeigen der Änderungsbelege muss ein entsprechender Report entwickelt werden.