Führende Nullen löschen

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

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

Führende Nullen löschen

Beitrag von thomasxy (ForumUser / 36 / 0 / 0 ) »
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

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Beitrag von Rsimon (ForumUser / 10 / 0 / 1 ) »
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 ) »
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 / 184 / 7 / 1 ) »
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 ) »
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 ) »
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 / 1795 / 213 / 396 ) »
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 / 302 / 50 / 62 ) »
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 (Specialist / 107 / 81 / 45 ) »
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 / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Führende Nullen löschen

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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 / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Führende Nullen löschen

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Romaniac

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Führende Nullen löschen

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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. 😥

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Romaniac


Re: Führende Nullen löschen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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....
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

4
Antw.
2974
Views
Führende Nullen
von Kelly » 05.10.2005 09:48 • Verfasst in ABAP® für Anfänger
9
Antw.
6739
Views
Führende Nullen
von Beginner014 » 24.10.2014 08:51 • Verfasst in ABAP® für Anfänger
18
Antw.
12897
Views
führende Nullen
von tabea* » 14.04.2007 09:21 • Verfasst in ABAP® für Anfänger
5
Antw.
12540
Views
Führende Nullen auffüllen
von ChrissixD » 24.03.2017 12:59 • Verfasst in ABAP® für Anfänger
1
Antw.
5267
Views
Führende Nullen anzeigen
von Michael_1 » 14.10.2004 10:47 • Verfasst in ABAP® Core

Über diesen Beitrag



Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140