Materialkurztext verlängern

Re: Materialkurztext verlängern

BenediktP hat geschrieben:Ich habe derzeit die Aufgabe den Materialkurztext im Materialstamm (MM01-MM03), sowie im Kundenauftrag (VA01-VA03) und im Fertigungsauftrag (CO01-CO03) zu verlängern.

Wer kommt denn auf solch eine schwachsinnige Idee?
Das Datenelement MAKTX wird über den direkten Verwendungsnachweis 3120 mal gefunden, das Tabellen MAKT-MAKTX wird gar an 3556 Stellen verwendet. Eine Verlängerung auf 60 Zeichen wäre mal ne amtliche Modifikation! Viel Spaß beim testen.

Welche Informationen sind denn im Materialkurztext enthalten, so dass man 60 Zeichen benötigt?
Evtl. macht es Sinn Teile dieser Informationen in ein anderes Feld auszulagern (z.b. PRODHA).
Wenn man Romane schreiben will nutzt man besser die Material-Texte: Grunddatentext/Materialnotiz.
Wenn es dann doch zwingend 60 Zeichen sein müssen, würde ich ein ZAPPEND mit einem ZZMTEXT vorschlagen. Dieses in den benötigten Tabellen (MAKT, VBAP,...) anhängen und in den gewünschten Transaktionen als zusätzlichen Feld per User-Exit einbinden.

Re: Materialkurztext verlängern

Fehlposting

Re: Materialkurztext verlängern

a-dead-trousers hat geschrieben:

Unit605 hat geschrieben:.... mindestens 60....

"Kurztext"

Ist mir schon klar... Du meinst also mit 60 Zeichen wird die Anforderung MINDESTENS 60 Zeichen voll erfuellt, oder waere etwas mehr lieber?

Man kann ja mal mit 60 Zeichen anfangen und spaeter, wenn dann doch 65 benoetigt werden, alles noch mal neu machen, nur diesmal mit mindestens 65 Zeichen....

....bis, ja bis dann jemand doch mindestens 66 Zeichen braucht.

Fuer mich waere die MAXIMALE Anzahl Zeichen interessanter, als die MINDEST Anzahl an Zeichen.

Re: Materialkurztext verlängern

Also möglich ist das schon.
Aber du machst dir keine Vorstellung was das für einen Aufwand bedeutet.
In allen Dynpros muss das Feld gekürzt und als Rollbar gekennzeichnet werden.
Allein dafür würde ich 20 Tage veranschlagen.
Das gesamte System muss compiliert werden (erinnert mich gerade an die
beginnende Katastrophe bei Jurassic Parc).
Alle betroffenen Tabellen müssen umgesetzt werden.

Ganz ehrlich: vergiss es!

Re: Materialkurztext verlängern

ralf.wenzel hat geschrieben:Für Rechnung nach Aufwand mache ich alles.

Dann kannst du dort in Rente gehen....ist ja wiederkehrende Arbeit mit jedem SupportStack/ReleaseWechsel.

Re: Materialkurztext verlängern

Was ist denn Sinn und Zweck der Übung?
Warum genau und wo braucht ihr denn 60 Zeichen?
Braucht ihr das um das richtige Material auswählen zu können?
Soll der Text auf Dokumenten ausgegeben werden?
Soll er in Listen erscheinen?

Es gibt ja noch mehr Möglichkeiten, als Ralf eine sichere Rente zu bescheren (Nicht, dass ich dir das nicht gönnen würde, Ralf!

/edit: So ähnlich hatte Hendrik ja auch schon gefragt...

Re: Materialkurztext verlängern

Letztlich sind wir doch alle H*r*n unserer materiellen Bedürfnisse.

Ich habe fast sechs Jahre für einen Kunden gearbeitet, der völlig beratungsresistent war und auf monolithischen Anwendungen bestand, weil er OO nicht begriffen hat (Zitat eines Modulverantwortlichen: "Dann springt der im Debugger ständig zwischen Methoden hin und her, das verstehe ich nicht"). Der hat auch (fast immer) bekommen, was er wollte. Selektionsbild, Geschäftslogik und Datenbankzugriffe in einem Report....

Als ich eine neue Anwendung schreiben sollte, hab ich gleich gesagt "das mache ich so, dass ich die GUI schön abtrenne, damit man auch auf Webdynpro oder sonstwas setzen kann, wenn man das will. Das wurde mir verboten!

Inzwischen schickt das Unternehmen seine Nachwuchsentwickler auf SAP Fiori-Schulungen, ohne dabei zu bedenken, dass die gar keine Anwendungen haben, die man Fiori-fit machen könnte - jede Anwendung, für die man Fiori nutzen will, muss man erstmal schreiben. Und testen. Alles, was sie bisher geschrieben haben bzw. schreiben lassen haben, ist für Fiori praktisch nicht verwertbar (ich schätze das mal auf 50-60 Mannjahre reinen Entwicklungsaufwand, der für Fiori nicht nutzbar ist).

JETZT bin ich gerade Entwickler und sowas wie "Zweiter Entwicklungskoordinator" in einem Projekt, in dem wir für ein Unternehmen der Arzneimittelindustrie eine sehr komplexe Software entwickeln, die das Unternehmen später weiterverkaufen will. Von der Komplexität her ist das ein eigenes SAP-Modul. Das ist wie Urlaub: Alles in OO, damit das überhaupt noch wartbar ist. Alles mit Unit-Tests, weil Validierung gesetzlich vorgeschrieben ist. Alles mit Online-Dokumentation, weil Drittkunden ja ihre Lizenz allein erweitern und warten wollen (wir haben einen eigenen Namensraum und müssen BAdIs einbauen, die Drittkunden dann implementieren können, so wie die SAP das macht), etc.

Das Hauptproblem ist: Finde mal SAP-Entwickler, die auf diesem Niveau operieren.... Kleine Anekdote dazu:

Ein Entwickler (Freiberufler, über 15 Jahre Erfahrung) ruft mich an und erzählt mir stolz, er habe ein schwieriges Problem gelöst. Er habe eine Klasse, von der er nur eine Instanz erzeugen dürfe. Seine Lösung sei, ein Attribut auf 'X' zu setzen, wenn es ein Objekt gebe und nur dann das CREATE OBJECT zu durchlaufen, wenn das auf SPACE steht. Natürlich steht die Instanziierung auf PUBLIC (weil er nix anderes kennt) und das IF muss er außerhalb der Klasse machen. Diese Lösung habe er den Entwicklern beim Kunden gezeigt und die wären total begeistert gewesen.

Da ist es mir dann echt schwer gefallen, mein iPhone nicht fallenzulassen und mir rutschte der Satz raus "Was seid IHR denn für Amateure, habt ihr noch nie was von Entwurfsmustern gehört?". Antwort: "Ich hab mal ein Buch dazu angefangen, das hab ich aber nicht verstanden und dann weggelegt".

DAS ist das Niveau, auf dem die meisten SAP-Entwickler operieren. Bestenfalls.

Ich nenne keine Namen, aber es gibt hier Leute, die den Mann kennen.

Aber jetzt sind wir sowas von OT....


Ralf