Führende Nullen löschen Thema ist als GELÖST markiert

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
20 Beiträge • Seite 1 von 2 (current) Nächste
20 Beiträge Seite 1 von 2 (current) Nächste

Führende Nullen löschen

Beitrag von thomasxy (ForumUser / 36 / 0 / 0 ) » 27.11.2007 15:08
Hallo zusammen,

ich lese verschiedene Materialnummern ein, die keine sinnhafte Numerierung haben. (unterschiedliche Längen,...)
Nun muss ich die eingelesenen Materialnummern verändern.
Es gibt Materialien mit führenden Nullen. Diese sollen entfernt werden und die korriegierten Daten wieder in eine Tabelle geschrieben werden.
Leider ist die Anzahl der führenden Nullen und auch die Anzahl der Stellen einer Artikelnummer unterschiedlich.

Das Feld der Artikelnummer ist vom Typ char.

Beispiele
Artikelnummer
1234
00123
0123

Ergebnis später
1234
123
123

Hat jemand für mich einen Tipp wie dies in ABAP möglich ist.
Vielen Dank

Gruß
Thomas


Beitrag von Rsimon (ForumUser / 10 / 0 / 1 ) » 27.11.2007 15:40
Hallo Thomas,

ohne es auszuprobieren (gerade kein systemzugriff) ein Vorschlag:
p_var ist dabei das Feld wo der Inhalt drinsteht.

Code: Alles auswählen.

     i_field = 1.
     DO 20 TIMES.
       IF p_var+i_field = '0'.
         p_var+i_field = ' '.
	 i_field = i_field + 1.
       ELSE.
         EXIT.
       ENDIF.
     ENDDO.
So bleiben die Zahlen an ihrer Stelle. Oder soll das ganze ganze dann linksbündig sein ?! dann kannst du evtl. SHIFT nutzen...

Grüße

Richard

Beitrag von thomasxy (ForumUser / 36 / 0 / 0 ) » 27.11.2007 15:41
hallo habe gerade die Lösung gefunden

Code: Alles auswählen.

* führende Nullen entfernen   
SHIFT <Feldname> LEFT DELETING LEADING '0'.
vielen dank

gruß
thomas

Beitrag von khb (Specialist / 181 / 5 / 1 ) » 27.11.2007 15:43
Hallo Thomas,

Code: Alles auswählen.

while matnr(1) = 0. 
  shift matnr. 
endwhile.
oder ganz einfach:

Code: Alles auswählen.

shift matnr left deleting leading '0'.

lg khb

Beitrag von TWP (Specialist / 445 / 0 / 1 ) » 28.11.2007 09:30
Hallo zusammen,

hier mal noch ein ganz anderer ansatz:

1) write: f1 to f2 no-zero.
2) condense f2 no-gaps

damit sind die Nullen weg und alles steht Linksbündig.

MfG

Thomas

Re: Führende Nullen löschen

Beitrag von Rsimon (ForumUser / 10 / 0 / 1 ) » 23.06.2020 10:22
Manche Problemchen kommen immer wieder. Ich hatte damals keinen Systemzugriff und mein Codebeispiel ist nicht ganz korrekt. Nach 13 Jahren ;-) hier die Korrektur:

Code: Alles auswählen.

i_field = 0.
    DO 20 TIMES.
      IF pa_kostl-low+i_field(1) = '0'.
        pa_kostl-low+i_field(1) = ' '.
        i_field = i_field + 1.
      ELSE.
        EXIT.
      ENDIF.
    ENDDO.

Folgende Benutzer bedankten sich beim Autor Rsimon für den Beitrag:
Jan


Re: Führende Nullen löschen

Beitrag von DeathAndPain (Top Expert / 1383 / 147 / 323 ) » 23.06.2020 15:46
Ja, wobei Deine Lösung hoffnungsloser Overkill ist. Den SHIFT ... DELETING LEADING '0' habe ich schon unter Release 3.1i genutzt.

Re: Führende Nullen löschen

Beitrag von msfox (Specialist / 109 / 16 / 15 ) » 23.06.2020 18:48
Ich nehme mal an, hinter MATNR steckt auch das Datenelement MATNR, welches als Domäne MATNR hat. :). Die Domäne hat die Konvertierungs-Routine MATN1 hinterlegt. Somit sollte die Konvertierung über den Fuba CONVERSION_EXIT_MATN1_OUTPUT erfolgen. Ob der Fuba das macht, was hier gewünscht ist, müsste man prüfen.
Bei der Konvertierung von 000000000000012312 werden die Nullen mit dem Fuba gelöscht.
Bei einer ALPHA-Konvertierung macht man es jedenfalls so....

Re: Führende Nullen löschen

Beitrag von qyurryus (ForumUser / 47 / 35 / 12 ) » 24.06.2020 10:20
Oder im Jahr 2020 mit String Templates 🙂

Code: Alles auswählen.

i_field = |{ i_field ALPHA = OUT }|.

Folgende Benutzer bedankten sich beim Autor qyurryus für den Beitrag:
msfox


Re: Führende Nullen löschen

Beitrag von ralf.wenzel (Top Expert / 3526 / 161 / 241 ) » 28.06.2020 15:59
Interessant ist, dass viele Lösungen auf eine zurückgehen. Das String-Template aus dem letzten Vorschlag verwendet die Standard-Konvertierung ALPHA aus dem vorletzten, etc.


Ralf

Re: Führende Nullen löschen

Beitrag von DeathAndPain (Top Expert / 1383 / 147 / 323 ) » 29.06.2020 18:17
So kapselt man eine Lösung in eine andere, der Overhead wird immer größer, die Performance dementsprechend immer schlechter, und man sieht dem Ergebnis immer weniger an, was da genau passiert. Genau wie bei in Klassen gekapselten Funktionsbausteinen. 😁

Re: Führende Nullen löschen

Beitrag von ralf.wenzel (Top Expert / 3526 / 161 / 241 ) » 29.06.2020 22:51
Grundsätzlich ist es nicht falsch, einen FB in eine Methode zu kapseln. Man kann eine Funktionsgruppe derart erweitern, dass man mit mehreren Instanzen arbeiten kann. Man kann sogar statische Methoden verwenden, weil die als funktionale Methoden das Coding nicht so sehr zerschneiden wie das z. B. ein Konvertierungsexit macht. Und manchmal ist ein sprechender Methodenname geeignet, seine Funktion deutlich besser zu erklären als der manchmal vermurkste Name eines FB.

Auch in diesem Falle würde ich eine Methode bauen, die z. B. „strip_leading_0“ heißen könnte.


Ralf

Re: Führende Nullen löschen

Beitrag von black_adept (Top Expert / 3363 / 65 / 631 ) » 30.06.2020 16:52
DeathAndPain hat geschrieben:
29.06.2020 18:17
So kapselt man eine Lösung in eine andere, der Overhead wird immer größer, die Performance dementsprechend immer schlechter, und man sieht dem Ergebnis immer weniger an, was da genau passiert. Genau wie bei in Klassen gekapselten Funktionsbausteinen. 😁
Moin D&P,
wenn du ausschließlich auf die Performance schaust hast du sicherlich recht. Allerdings fürchte ich, dass du bei diesem recht einseitigen Blick doch Wesentliches außer Acht lässt: Nämlich die Lesbarkeit des Codes. So weh es mir tut Ralf zustimmen zu müssen, aber ein gekapselter Aufruf der Alphakonvertierung ( in Zeiten vor den Stringtemplates ) war immer lesbarer als der explizite Aufruf des Conversionexits. Und ich weiß nicht wie du es siehst, aber für mich war und ist das Programmieren immer eine Balance zwischen Performance und Les-/Wartbarkeit, wobei sich auf Grund von immer schneller werdenden Rechnern und i.A. größer werdender Komplexität von Aufgaben man sich immer weiter in Richtung "Lesbarkeit" bewegen kann ohne größere Einbußen bei der Performance hinnehmen zu müssen.
Umgekehrt erinnere ich mich an einen extrem interessanten Vortrag bei einen Codejam wo jemand von einer extrem zeitkritischen Anwendung berichtet hatte und mit was für Tricks er diese immer weiter performanceoptimiert hatte - bis dahin, dass er dafür sorgte, dass Daten im L1 oder L2-Cache des Prozessors gehalten wurde aufgrund der Zugriffe. Allerdings wurde dann auf Nachfrage zugegeben, dass sich in seiner Firma niemand mehr an diesen Code herantraut oder überhaupt nur versteht. Das ist also das andere Extrembeispiel.
Den Fall den du hier (vielleicht zu Recht - ich glaube aber nicht ) bemängelst halte ich allerdings in einem Bereich angesiedelt, wo du die Auswirkung auf die Performance quasi nie zu spüren bekommen wirst - egal was du machst. Ich habe jetzt keine Lust eine Laufzeitmessung für verschiedene Versionen ( SHIFT, CONVERSIONEXIT explizit oder implizit mit WRITE oder Stringtemplates ) zu machen und mir dann zu überlegen welchen Anteil dies in einem normalen Programm wohl an der Gesamtlaufzeit haben mag. Ich fürchte schon letzteres wird sich auf kein Promille der LZ aufsummieren und die Laufzeitdifferenz dementsprechend unterhalb der Messgenauigkeiten der SAT liegen bleiben.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Führende Nullen löschen

Beitrag von DeathAndPain (Top Expert / 1383 / 147 / 323 ) » 30.06.2020 19:43
Ihr habt recht; ich war hier schon etwas sarkastisch. Wobei ich speziell in diesem Fall durchaus der Meinung bin, dass der SHIFT-Befehl nicht nur die schnellste, sondern zugleich auch für den Leser verständlichste Variante ist. Ich jedenfalls würde den SHIFT sofort verstehen, bei

Code: Alles auswählen.

i_field = |{ i_field ALPHA = OUT }|.
aber erst mal grübeln und nachlesen müssen, was diese Syntax mir genau sagen möchte. Und wenn ich sie verstanden hätte, müsste ich mir auch noch ins Gedächtnis rufen, was der Alpha-Konvertierungsexit genau tut. Insofern fallen bei dieser Aufgabenstellung nach meiner Überzeugung Schönheit und Geschwindigkeit zusammen, so dass alles andere auf jeden Fall Overkill ist.
black_adept hat geschrieben:So weh es mir tut Ralf zustimmen zu müssen, aber ein gekapselter Aufruf der Alphakonvertierung ( in Zeiten vor den Stringtemplates ) war immer lesbarer als der explizite Aufruf des Conversionexits.
Die Option der funktionalen Methoden zählen auch zu dem, was mir an OO noch am Sympathischsten ist. Leider gilt das aber halt nur für die Aufrufstelle. Der Preis, den man dafür bezahlt, sind auseinandergerissene Definition und Implementation, was ich schon immer als rein akademisch und praxisfremd empfunden habe, da es die Lesbarkeit der Implementierung drastisch verbessert, wenn man am Kopf derselben die Parameterschnittstelle sieht, so wie bei einem Funktionsbaustein oder einer Formroutine. Wohl deswegen hat die SAP ja in der SE24 so eine Krücke gebaut mit der formularbasierten Darstellung, bei der man bei Methoden die Parameter außerhalb des Quellcodefensters sieht - für den Preis, dass dieses gewaltig schrumpft und man in einem Mäusekino programmiert. Bei Eclipse sieht man die Parameter gar nicht (ich habe mir zur Angewohnheit gemacht, sie mir als Kommentar aus der Definition zu kopieren und am Anfang der Implementierung einzufügen. Aber wehe, man ergänzt oder ändert rasch mal einen Parameter - dann passt der Kommentar nicht mehr).

Wenn man dem Codefluss folgt, sieht man die Aufrufstellen, und die sind bei Methoden - selbst bei nichtfunktionalen - in der Tat bedeutend schöner als bei Funktionsbausteinen oder Formroutinen. Ich finde es nur halr so schade, dass man immer so einen Riesenaufwand treiben muss, um eine neue Methode einzuführen. SE24 mag ich gar nicht wegen des Inputmedienbruchs - ich kann dort nicht alles mit der Tastatur machen, sondern muss ständig zur Maus greifen. In Eclipse sind die Bestandteile der Methoden über den Code verstreut. Seufz. Formroutinen kann man aufrufen, egal wo im Code sie stehen, sogar DDIC-globale TYPE-POOLS sind mittlerweile ohne jede Deklaration im Code überall verfügbar. Nur bei den Methoden, die das Modernste repräsentieren sollen, gibt es die unsinnige Einschränkung, dass die Methode nur gefunden wird, wenn ihre Definition vor der Aufrufstelle liegt. Noch nicht einmal mit einem DEFINITION DEFERRED ist dies wirksam zu umgehen.
Ralf hat geschrieben:Man kann eine Funktionsgruppe derart erweitern, dass man mit mehreren Instanzen arbeiten kann.
Du bist beinahe der Einzige, dem ich zutraue, mit Instanzen vernünftig umzugehen. Ich bin von genug Entwicklern und Beratern umgeben und sehe deren Code. Wenn da Instanzobjekte zum Einsatz kommen, dann nahezu immer in der Form, dass nur ein einziges Objekt erzeugt und damit dann gearbeitet wird. Dann aber ist die Instanz nur ein Wasserkopf, und eine statische Klasse (wie ich sie praktisch nur erstelle) ist die bessere Wahl. Von Vererbung will ich gar nicht erst anfangen. Ein schönes Konzept, aber benutzen tut es außer der SAP und Dir niemand.

Damit einhergehend sind Attribute von Objekten in der Theorie nett und schön, um Objektzustände zu setzen. Die Attribute, die ich freilich real im Code anderer Entwickler sehe, sind von der Art und Weise, wie sie genutzt werden, aber nichts anderes als herkömmliche globale Variablen, mit denen die Kapselung umgangen und die Programmstrukturierung durchbrochen wird, so dass im Code Werte vom Himmel fallen und man nicht weiß, wo sie herkommen. Attribute halte ich für den Hauptgrund, weshalb man fremden objektorientierten Code in aller Regel so viel schlechter verstehen und mit dem Debugger analysieren kann als prozeduralen. Bei prozeduralem Code sind globale Variablen auch möglich, aber gefühlt würde ich sagen, dass die Schlamperei mit globalen Variablen anstelle ordentlicher Übergabeparameter bei OO noch verbreiteter bzw. größer ist - vermutlich deshalb, weil man den Entwicklern, die das machen, das Alibi quasi frei Haus liefert, nämlich dass es ja keine verwerflichen globalen Variablen sind, sondern moderne "Attribute". Das Ziel, mit dem OO mal angetreten ist, nämlich die Entwickler zu einer besseren Kapselung zu drängen, ist damit jedenfalls gründlich verfehlt worden; der Code ist schlechter lesbar als der alte.

Was ich durchaus schade finde, denn die Ideen und Konzepte in OO sind ja eigentlich durchaus gut, etwa dass man Unterroutinen als privat deklarieren kann, die schöneren Aufrufe oder auch funktionale Methoden. Nur die Praxis hält sich halt nicht an das, was die Akademiker sich da ausgedacht haben - und die sind offenbar so praxisfern, dass sie das nicht sehen und darauf mit Anpassungen in der Sprache reagieren. Wie man da rangehen könnte, müsste man mal überlegen. Aus meiner Sicht könnte ein möglicher Weg darin bestehen, dass Attribute gar keine Felder sind, sondern "Speicherslots" des Objektes, in denen man per SET ATTRIBUTE attributname = feld bzw. GET ATTRIBUTE attributname INTO feld Zustandswerte ablegen und wieder zurückholen kann. Das hat zwar etwas von einem IMPORT FROM MEMORY, aber das Ziel, das man in meinen Augen damit erreichen würde, wäre, dass die Bequemlichkeit der globalen Variablen dahin wäre. Wenn die Attribute nicht einfach überall in der Klasse als normale Feldwerte präsent sind, sondern man jedesmal den Aufwand treiben müsste, sich den Wert mit o.g. Befehlen zu beschaffen bzw. darin abzuspeichern, dann würden vermutlich so einige darüber nachdenken, die Werte stattdessen doch lieber als Parameter durchzureichen, womit eine ordentliche Kapselung sich quasi von alleine ergeben würde. Aus Faulheitssicht hätten Attribute dann keinen Vorteil mehr. Zudem könnte man sich damit sicherlich auch die eine oder andere SET- und GET-Methode sparen, da diese Befehle das ja gewissermaßen ersetzen würden.

Nur so eine Idee von mir. Wird eh keiner umsetzen. 😥

Re: Führende Nullen löschen

Beitrag von ralf.wenzel (Top Expert / 3526 / 161 / 241 ) » 30.06.2020 21:01
Danke für die Blumen. Aber ich möchte dir in einigen Punkten widersprechen: Gerade hier laufen einige Leute herum, die eine enorme Klasse haben. Und jeder ist auf seinem Gebiet irgendwo herausragend. Ich nenne jetzt extra keine Namen, aber die Regulars, die ich meine, fühlen sich sicher angesprochen.

Ein Singleton hat durchaus seine Berechtigung, sonst gäbe es kein Singleton-Pattern. Eine statische Methode kann ich in der Ableitung zum Beispiel nicht redefinieren, was einen großen Teil meiner Entwicklungen deutlich erschweren würde.

Dass Attribute etwas anderes sind als Variablen, doziere ich seit Jahr und Tag. Ich frage mich nur: Warum gibt es analog zum Pretty Printer keine Funktion, die zu jedem Attribut eine SET- und eine GET-Methode erzeugt? Warum muss ich sowas selbst schreiben (also eben diesen Generator)? Dann würde die Faulheit "ach, mach ich's halt public" nicht ständig siegen. Auf der anderen Seite muss man diese Entwickler auch fragen, ob sie so einen Murks in anderen Bereichen ihres Lebens dulden würden, wenn sie mit ihm konfrontiert würden.

In aller Regel ist es reine Faulheit, soweit ich das beobachten konnte.


Ralf *tippen mit acht Fingern ist mühselig....


Aktuelle Forenbeiträge

Smartform debuggen Main-Teil
vor einer Stunde von wreichelt 14 / 278
Summen bei Auswertung fett drucken
vor 11 Stunden von Bright4.5 5 / 137

Vergleichbare Themen

Führende Nullen
von Beginner014 » 24.10.2014 08:51
führende Nullen
von tabea* » 14.04.2007 09:21
Führende Nullen
von Kelly » 05.10.2005 09:48
führende Nullen in char fel
von F12_man » 25.05.2007 12:12
Führende Nullen anzeigen
von Michael_1 » 14.10.2004 10:47