führende Nullen

Re: führende Nullen

tabea* hat geschrieben:Ergebnis - wenn ich die Kostenstelle z.B. mit write ausgebe:
987654

Schieb sie rechtsbündig in ein NUMC-Feld der Länge 10. Oder setz die vier Nullen beim WRITE einfach links daneben.


Ralf

Re: führende Nullen

tabea* hat geschrieben:Ich muss die Darstellung aber in der kompletten Tabelle csks cskt ändern, d.h. alle Reports die darauf zugreifen, sollen diese Darstellung mit den führenden Nullen übernehmen.

Ach du *!

Ich hab grad kein System zur Hand, aber in der Domäne wirst du fündig werden -- aber ich rate dir: Lass die Finger davon. Sowas wälzt man mit dem Kostenargument ab und damit, dass die SAP alle Untestützungsleistungen für die Objekte ablehnt, die auf modifizierte Elemente basieren. Alle zum Beispiel alle Programme die auf die von dir genannten Tabellen zugreifen.

Sowas würde ich nie machen. Wenns nicht reicht, dass du das sagst, wende dich ans OSS mit der Anforderung, die helfen gern bei Argumentationen.


Ralf

Re: führende Nullen

Hi,

ich hab kein System hier, ich kenne das Feld und dessen Domäne nicht aus dem Kopf, aber es könnte ein Ausgabeexit drinhängen. Es KÖNNTE auch sein dass im Reporting jeweils die Nullen einfach unterdrückt werden. Guck doch mal mit der SE16 in die Tabelle rein. Wenn da schon keine führenden Nullen drinstehen, ist es einfacher.

WENN es ein CHAR-Feld IST und KEIN Ausgabeexit drinhängt könntest du ein concatenate machen, aber das ist dann auch wieder eine Änderung in Standardprogrammen, die den Aufwand nicht rechtfertigt.

ODER (ganz, ganz böse und unter der obigen Annahme) könntest du die Nullen auch in die Tabelle reinschreiben, aber sowas kann auch böse ins Auge gehen wenn die Standardprogramme nicht mit den Nullen rechnen und daher Vergleiche in die Hose gehen, etc pp.


Ralf

Hallo,

was mußt Du denn eigentlich genau machen? Mußt Du den Inhalt der Felder ändern? Oder sind die Inhalte schon mit führenden Nullen in der Tabelle?
Bei einem CHAR Feld kannst Du das sowohl so, als auch so füllen. Und normalerweise wird beim WRITE auch die führende Null mit ausgegeben, wenn Du in der Tabelle den Wert mit führenden Nullen abgelegt hast.

Also ich tippe mal darauf, dass Du die Werte in der Tabelle erstmal ändern mußt. Und das ist eigentlich ziemlich einfach!!

Du schreibst ein Programm, das die Kostenstelle liest (den ganzen Satz, also SELECT * FROM CSKS) legst das auch in Deine interne Tabelle I_CSKS ab, die natürlich die Definition von CSKS hat (z.b. DATA: I_CSKS LIKE CSKS OCCURS 0 WITH HEADER LINE) und löscht zuerst den Satz aus der Tabelle raus. Dann nimmst Du den Satz in der internen Tabelle und rufst den FB "CONVERSION_EXIT_ALPHA_INPUT" auf, der die führenden Nullen anhängt und machst dann einen INSERT auf die CSKS.

Normalerweise sollten die Daten dann mit führenden Nullen in der Tabelle stehen und auch von den anderen Programmen entsprechend ausgegeben werden.

Falls Du noch Fragen dazu hast, kannst mir gerne ne Message schicken, ich schreib Dir dann mal schnell ein Programm (dauert 10 Min.).

lg
Martin

Hallo zusammen,

erst mal tausend Dank für eure ganzen Antworten
Aber wenn ich ehrlich bin, bin ich nun doch etwas verunsichert.

Ich glaube ich habe das Problem auch falsch beschrieben, nämlich schon mit meiner Idee der Lösung. Also beginne ich noch einmal von vorne.

Problem ist wohl, so schilderten es mir die Anwender, das wenn sie Querys über - was auch immer - laufen lassen, die Kostenstellen einmal mit und einmal ohne führende Nullen dargestellt werden. Ja sicher kann man dies ja auch einstellen, also wenn man eine Query macht, aber das ist der Person, die das machen muss, doch zu aufwendig, daher kann dann die Frage an mich, ob ich es nicht so machen könne, das alle Kostenstellen mit den führenden Nullen erscheinen. Ich bin dann davon ausgegangen, das es an dem Feld kostl in den Tabellen csks und cskt liegen muss, weil ich davon ausgegangen bin, dass da alle Kostenstellen aufgelistet und geholt werden.
Mein erster Schritt war dann mir diese Tabellen anzusehen, lässt man sich ein paar eingetragene Kostenstellen anzeigen erscheinen sie in der Liste immer mit den führenden Nullen, sieht man sie sich einzeln an, dann sind die führenden Nullen nicht mehr da, und auch wenn ich eine neue Kostenstelle auf der Tabelle einfüge, mit führenden Nullen, werden diese dann in der Einzelanzeige abgeschnitten, oder wenn ich sie mir mit einem WRITE ausgeben lasse. Also habe ich mir gedacht das es an der Domäne liegt, nur habe ich mir überlegt das man da ja doch etwas machen können müsste, da es ja anscheinend Kostenstellen gibt die mit führenden Nullen eingetragen sind, sonst hätte der Anwender ja gar nicht das Problem.

Ich glaube das war schon daneben, oder? Also was ich dachte und wie ich das Problem lösen wollte, oder?

Und dann hat ja Martin diesen schönen - für mich schönen da anscheinend leicht lösbar - Beitrag geschrieben, aber Ralf du warnst mich davor es so zu machen. Dann frage ich euch nun nochmal unter obiger Beschreibung des Problem, sollte ich die Finger davon lassen? Also geht es nur durch Modifikationen die letztlich zu mehr Problemen führen als das sie eine Erleichterung darstellen?

Vielen Dank euch allen nochmals,
viele Grüße
tabea

Hallo,

ereglam hat geschrieben: Also, lass Dir bitte mal von den Anwendern zeigen, was sie da denn machen und dann kannst Du ja schon mal überprüfen, ob das so überhaupt richtig ist.

Diese Informationen würden uns bei der Fehlersuche auch helfen können.

nun habe ich es mir mal genau zeigen lassen, also was das eigentliche Problem ist, es handelt sich gar nicht um die Kostenstelle, sondern um die Versandart.

Diese ist tatsächlich in der Tabelle mal mit und mal ohne führende Nullen eingetragen. Ich habe nun für einen Testfall die Nummer mittels eines ABAP-Programms ausgelesen und mit führenden Nullen zurückgeschrieben. Ich benutze dabei CONVERSION_EXIT_ALPHA_INPUT.

Nun meine Frage, kann es dadurch zu Problemen kommen die ich nicht überschauen kann? Also ich denke ja eigentlich, das es nicht zu Problemen kommen kann, da die Tabelle ja zur Zeit beides beinhaltet, wäre aber froh, wenn mir vielleicht einer von euch Experten noch etwas dazu sagen kann!

Viele Grüße,
und vielen Dank für all eure Beiträge bis her
tabea

Hallo,

ralf.wenzel hat geschrieben: Ich tippe mal auf nein

das hört sich gut an

ralf.wenzel hat geschrieben: aber das müsste man halbwegs sicher verifizieren.

wie ??????????????

viele Grüße
tabea