Änderungen an SAP-Standardprogrammen

Änderungen an SAP-Standardprogrammen

Hallo,

ich möchte bei einem bestehenden Standard SAP Programm Änderungen vollziehen. D.h. ich möchte auf der sich - nach starten des Programms - zeigende Maske einen Button, und eine Prüfung für das schon existierende Eingabefeld hinzufügen. D.h. die anwendende Person soll nachdem sie eine Eingabe in das dafür bestimmte Feld gemacht hat, auf den von mir hinzugefügten Button drücken und dann eine Meldung erhalten, wenn die Eingabe nicht ganz bestimmten Richtlinien genügt.

Ist es überhaupt möglich ein Standardprogramm zu ändern. So weit ich weiß, darf ich das doch gar nicht, oder? D.h. ich müsste das Programm erst kopieren, in den Kundennamensraum, dann die Änderung vollziehen. Nur ist dann mein Problem, das dieses Programm von anderen Programmen verwendet wird, und dies dann ja, durch den neuen Namen nicht mehr so ohne weiteres möglich ist, oder?

Kann mir da vielleicht jemand helfen?
Viele Grüße
Tabea

Re: Änderungen an SAP-Standardprogrammen

tabea* hat geschrieben:Kann mir da vielleicht jemand helfen?

Also, prinzipiell ist eine Modifikation (eine Änderung eines Programmes, das im SAP-Namensraum liegt) etwas, das man nur machen sollte, wenn es zwingende(!!!) Gründe dafür gibt. Vorher sollte man prüfen:

* Gibt es im Customizing Möglichkeiten, den Aufruf zu "verbiegen"? Es ist an vielen Stellen so, dass die Namen von Programmen, FuBaus, etc. im Customizing hinterlegt sind und man über Änderungen des Customizings eine Modifikation verhindern kann.

* Gibt es IN dem betreffenden Programm Möglichkeiten, Änderungen einzuarbeitren, ohne es zu modifizieren? Oft ist so etwas vorgesehen.

* Kann man organisatorisch im Unternehmen Änderungen durchführen, die eine Modifikation verhindern? Spätestens wenn man das Kostenargument (siehe unten) bringt, besteht diese Bereitschaft beim Anwender in der Regel.

Falls die Modifikation immer noch notwendig und gewollt ist, gilt es zu prüfen:

* Macht es Sinn, eine oder mehrere Aufrufstellen per Modifkation zu ändern? Manchmal ist das weniger Aufwand (gerade in der Wartung, siehe unten) als die Modifikation des Originals, weil der Eingriff "kleiner" ist.

* Als letzte, aber wirklich allerletzte Möglichkeit bietet sich dann die Modifikation des entsprechenden Programms an. Auch hier würde ich so vorgehen, dass nach Möglichkeit die Modifikation so klein wie möglich zu halten ist, zum Beispiel statt "ich schreib mein Coding in das Programm" lieber die Variante "ich rufe ein externes Programm/FuBau/etc. auf, in dem ich mein Coding im Kundennamensraum habe". Wichtig hierbei: Nutze den Modifikationsassistenten!!!

Zur Beurteilung der o. g. Punkte: Schreibe mal bitte genau, wo du welche Änderung haben willst, dann wird dir hier jemand sagen können, welchen Weg du am besten wählst.

Ich habe eine ganze Reihe von Modifikationen gemacht (z. B. weil ich ziemlich früh an IS-PS rumgestrickt habe, als es noch ziemliche Haken und Ösen hatte).

Das Kostenargument ist dabei ganz entscheidend, du wirst die Stelle immer und immer wieder anpassen müssen, weil sie durch Updates gern überschrieben wird. Der Modifikationsassistent hilft dabei. Und je kleiner dabei die Änderung ist, umso eher ist gewährleistet, dass auch ein anderer das wieder einpflegen kann.

Ganz, ganz, ganz wichtig: Du musst das dokumentieren, ich gehe sogar so weit, dass ich die Anforderung selbst und meine Bedenken dagegen dokumentiere. Die Dokumentation sollte enthalten:

* WAS wurde geändert?
* WARUM wurde es geändert?
* WER hat es angefordert, genehmigt und wer braucht es warum?
(später lassen sich diese Anforderungen vielleicht dann doch mal durch ein Customizing oder organisatorische Änderungen realisieren, dann sollte man die Modifikation wieder aus dem System nehmen)
* WIE wurde geändert, auf welche Art und Weise?
* WO genau wurde geändert (Status, Coding, Texte, etc.) und wie wirken sich die Änderungen aus?
* WELCHE Schritte sind notwendig, um die Änderung nochmal einzupflegen?

Die Dokumentation ist dabei fast noch wichtiger als dein Coding, meine Erfahrung zeigt, dass solche Modifikationen sehr, sehr lang im System bleiben. Eine Reihe von Modifikationen die schlecht oder gar nicht dokumentiert waren, musste ich warten - dabei kriegt man echt das Kotzen.

Du brauchst einen Objektschlüssel, das heisst dass du bei der SAP "bescheidsagen" musst, welches Programm in deren Namensraum du geändert hast. Gehe davon aus, dass die SAP im OSS jegliche kostenlose Wartung und Hilfestellung nicht nur in diesem Objekt, sondern auch in allen möglichen Objekten drumherum ablehnt. Ehe du (oder jemand anderes) also eine OSS-Anfrage machst, die im Umfeld des modifizierten Programms liegt, nimm erst die Modifikation raus, damit die SAP auch sieht, dass ohne Modifikation der gemeldete Fehler auch auftritt.

Ralf

Hallo Tabea,

also ganz so krasse wir Ralf das beschreibt würde ich es nicht sehen. Es kommt auch immer drauf an in welchem Programm was genau modifiziert werden soll. Und da ist eine zusätzliche Eingabeprüfung (aus meiner Sicht) nicht so kritisch zu bewerten wie bspw. die Modifikation eine SAP-Standard-Schnittstelle...

Aber das muss man im Einzefall genau abwägen und prüfen und mit der SAP Basis abstimmen... in manchen Firmen sind die Vorschriften zur Prüfung ob eine Modifikation eingebaut werden darf sehr viel umfangreicher als in anderern Firmen...

Ganz unabhängig davon ist der Weg, den Ralf aufgezeigt hat, zuerst diverse Themen abzuprüfen ob es ohne Modifikation geht unbedingt einzuhalten. Und in diesem Fall geht es sehr einfach ohne... die SAP sieht für die Stammdatenpflege im HR explizit vor, dass zusätzliche kundeneigne Prüfungen durchgeführt werden. Hier gibt es die Erweiterung PBAS0001. Für diese muss in der CMOD ein eigenes Projekt angelegt werden und dann können die zusätzlichen Prüfungen im Funktionsexit EXIT_SAPFP50M_002 programmiert werden (im EXIT_SAPFP50M_001 können zusätzliche kundeneigene Vorschlagswerte für das Anlegen von Infotypen programmiert werden).

Der Userexit ist leider relativ schlecht dokumentiert... daher würde ich vorschlagen, dass Du Dir entweder Unterstützung holst oder genügend Zeit einplanst um Dir das Thema selbst genauer anzuschauen.

Und jetzt noch was anderes... was ist dass denn für ein Feld im IT 32? LBV-Nummer sagt wir da nichts... könnte es sein, dass dies sowieso schon ein eigenes Feld ist? Dann kannst Du die Prüfungen auch im Kundencoding für das Zusatzfeld hinterlegen... es müsste dann den Modulpool ZP003200 geben und das Dynpro ZP003200 / 0200.

Grüße
Christian

Hallo,

ich hätte dann jetzt tatsächlich noch eine Frage

ChrisB hat geschrieben:Und jetzt noch was anderes... was ist dass denn für ein Feld im IT 32? LBV-Nummer sagt wir da nichts... könnte es sein, dass dies sowieso schon ein eigenes Feld ist? Dann kannst Du die Prüfungen auch im Kundencoding für das Zusatzfeld hinterlegen... es müsste dann den Modulpool ZP003200 geben und das Dynpro ZP003200 / 0200.

es ist genau so wie du es da beschreibst aber kann ich da jetzt wirklich nicht viel falsch machen? Kann ich da ohne weiteres mein Coding unter bringen, gibt es da vielleicht auch Richtlinien wie man wo was am besten einfügt, etc.? Oh ne, am liebsten hätte ich ja ein Beispiel an das ich mich halten könnte, gibt es so etwas vielleicht?

Viele Grüße
Tabea

ChrisB hat geschrieben:Hallo Tabea,

naja... dann handelt es sich eigentlich um ganz normale Dynpro Programmierung. Sprich im PAI in einem Verprobungsmodul einfügen und dort die gewünschten Verprobungsrichtilinen abprüfen. Ein separater Prüfbutton ist dafür eigentlich nicht nötig...

Ein Beispielcoding hab ich grad nicht greifbar. aber Du kannst Dir auch das Dynpro Coding eines SAP-Standard-Infotyps anschauen... da werden die meissten Felder auch einer Prüfung unterzogen.

Viele Grüße
Chris

Hi Chris,

dir einfach tausend Dank, genau das werde ich morgen machen

viele Grüße
Tabea

Hallo tabea*,

tabea* hat geschrieben:Was passiert:
NICHTS :cry:

Woran kann es liegen????????????

Was soll denn passieren? Gibts Du ggf. eine Fehlermeldung aus und die erscheint nicht?
Manchmal ist auch die Anweisung OUTPUT = INPUT. im FuBa notwendig. Vielleicht schickst Du mal etwas Coding.

Wenn Du den RSMODPRF ohne Angabe eines Datenelements startest, dann erhälst Du eine Liste aller Feldexits. Hat Deiner auch wirklich den Status aktiv?

Hallo tabea,

bin auch zu Hause, genauer gesagt schon im Urlaub :-)

Ich habe 2 Vermutungen:
1) Zuordnung des Datenbankfeldes zu Programmen: Ist die Zuordnung global oder nur zu einem bestimmten Programm?

2) Du schriebst weiter oben:

tabea* hat geschrieben:Was habe ich gemacht:
1. Ein neues Datenelement angelegt

Dein Datenbankfeld (LBV-Nummer) ist möglicherweise in der entsprechenden Datenbanktabelle nicht mit einem Datenelement, sondern nur mit dem Datentyp definiert. Ich finde so etwas ziemlich ?dirty?. Wenn dem so ist, dann musst Du das Datenbankfeld entsprechend mit Deinem neuen Datenelement hinterlegen, d.h. eine Anpassung in der SE11 machen. Prüfe aber vorher, ob der Typ Deines Datenelements auch wirklich dem des Datenbankfelds entspricht. Anderenfalls käme es zu Problemen, weil die Datenbank schon Einträge hat.

Hallo,

black_adept hat geschrieben:Hallo Tabea,

nachdem du den Profilparameter auf "YES" gesetzt hast,muss das SAP-System einmal neu gestartet werden. Wurde das gemacht?

ja das wurde gemacht. Ich weiß wirklich nicht mehr weiter, es wäre so genial für diese Anwendung, deshalb mag ich auch noch nicht aufgeben!

Wenn ich den Funktionsbaustein teste klappt auch alles genau so wie es sein soll.

Vielleicht habe ich auch mein Datenelement falsch erstellt. Ich habe ein ganz normales Dynpro, mit folgendem Coding:
Und diese z_lbvnr ist ein aktives Datenelement Z_LBVNR, der Datentyp ist Eingebauter Typ CHAR der Länge 12.
Kann es sein das es daran liegt?

Vielen Dank für eure Beiträge bis her, ich kann dann auch einfach nicht aufgeben und muss zumindest raus finden, woran es liegt

Viele Grüße
tabea