CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

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

Benutzeroberflächen in SAP®-Systemen.
13 Beiträge • Seite 1 von 1
13 Beiträge Seite 1 von 1

CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von Romaniac (Specialist / 216 / 62 / 27 ) »
Hallo zusammen,

ich finde den Fehler nicht, vielleicht übersehe ich ja was, folgendes Problem:

Ich lese die Kalkulation aus für ein Material und bekomme z.B. 1.322.506 KRW (Südkoreanische Won, Währung hat keine Nachkommastellen)

Im Debugger stimmt der Wert bis zur Ausgabe mit CL_SALV_TABLE, in der Liste steht dann aber 132.250.600 KRW.
  • Währung ist auf 0 Nachkommastellen definiert
  • Betragsfeld in Ausgabestruktur hat Referenz zum Währungsfeld
Habe ich was übersehen? Der Effekt ist, dass die Nachkommastellen(,00) aus dem Feld bei der Ausgabe einfach ohne Komma konvertiert werden weil die Währung eben keine Nachkommastellen hat, dadurch die Verschiebung um Faktor 100.

Bin nach einigen Stunden Suche für Tipps dankbar...

Gruß Wolfgang

Hier nochmal alles zusammengefasst:
SALV Nachkommastellen KRW klein.jpg
Geht nicht gibts nicht

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


Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von a-dead-trousers (Top Expert / 4370 / 222 / 1174 ) »
Blöde Frage:
Hast du das SALV einmal OHNE das Währungsfeld eingetragen zu haben ausgegeben? Der Feldkatalog wird intern nämlich gepuffert.
Die aktuellen Einstellungen kannst du abfragen indem du mit gedrückter SHIFT-Taste einen Doppel-Rechtsklick in den grauen Bereich (wo keine Daten drinnen stehen) vom ALV-Grid machst. Dort kannst du dann den aktuell gesetzten Feldkatalog einsehen. Wenn die Einstellungen dort nicht mit den von dir gesetzten übereinstimmen, kannst du den ALV-Puffer mittels des Reports BALVBUFDEL zurücksetzen.
Anonsten könnte auch eine (standardmäßig) gesetzte ALV-Variante der Grund sein. Wenn das zutrifft müsstest du die entsprechende Variante löschen und neu anlegen.

EDIT:
Zumindest kommt es bei mir mit diesen Einstellung als 1.322.506,00 KRW raus:

Code: Alles auswählen.

TYPES:
  BEGIN OF ts_value,
    netwr TYPE netwr,
    waerk TYPE waerk,
  END OF ts_value,
  tt_value TYPE STANDARD TABLE OF ts_value WITH DEFAULT KEY.

DATA:
  lr_grid  TYPE REF TO cl_salv_table,
  lt_value TYPE tt_value.

APPEND VALUE #( netwr = 1322506 waerk = 'KRW' ) TO lt_value.

cl_salv_table=>factory( IMPORTING r_salv_table = lr_grid
                        CHANGING t_table       = lt_value ).

lr_grid->get_columns( )->get_column( columnname = 'NETWR' )->set_currency_column( value = 'WAERK' ).

lr_grid->display( ).
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von a-dead-trousers (Top Expert / 4370 / 222 / 1174 ) »
Hier ein etwas besseres Beispiel:

Code: Alles auswählen.

TYPES:
  BEGIN OF ts_value,
    netwr    TYPE netwr,
    waerk    TYPE waerk,
    decimals TYPE decimals,
  END OF ts_value,
  tt_value TYPE STANDARD TABLE OF ts_value WITH DEFAULT KEY.

DATA:
  lr_grid  TYPE REF TO cl_salv_table,
  lt_value TYPE tt_value.

APPEND VALUE #( netwr = 1322506 waerk = 'KRW' decimals = 0 ) TO lt_value.
APPEND VALUE #( netwr = 1322506 waerk = 'EUR' decimals = 2 ) TO lt_value.
APPEND VALUE #( netwr = 1322506 waerk = 'JPY' decimals = 0 ) TO lt_value.
APPEND VALUE #( netwr = '13225.06' waerk = 'JPY' decimals = 0 ) TO lt_value.

cl_salv_table=>factory( IMPORTING r_salv_table = lr_grid
                        CHANGING  t_table      = lt_value ).

lr_grid->get_columns( )->get_column( columnname = 'NETWR' )->set_currency_column( value = 'WAERK' ).
lr_grid->get_columns( )->get_column( columnname = 'NETWR' )->set_decimals_column( value = 'DECIMALS' ).

lr_grid->display( ).
Wenn ich das auf unserem System ausführe, kommt folgendes heraus:
1.322.506,00 KRW
1.322.506,00 EUR
132.250.600 JPY
1.322.506 JPY

Conclusio:
  • Das ganze funktioniert NUR mit zwei Dezimalstellen.
  • z.B: muss für Yen der Wert auch in den zwei Dezimalstellen gefüllt sein.
  • Entweder ist KRW sap-intern falsch konfiguriert oder die Werte sind in eurem System falsch abgelegt. Eigentlich müssten die Werte, so wie bei Yen, auch die Dezimalstellen befüllt sein.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von a-dead-trousers (Top Expert / 4370 / 222 / 1174 ) »
Übrigens haben Südkoreanischer Won laut Wikipedia eine Untereinheit:
1 Won = 100 Chon
https://de.wikipedia.org/wiki/S%C3%BCdkoreanischer_Won
Und ich glaube das spiegelt sich auch in der Aufbereitung von KRW in SAP wider.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von Romaniac (Specialist / 216 / 62 / 27 ) »
Hallo ADT,

erst mal vielen Dank für deine Mühe! Ich werde meine Entwicklung am Nachmittag nochmal genauer ansehen und gebe dann Rückmeldung.

Seltsam ist ja nur, dass die übernommenen Werte aus den Auftragspositionen passen.

Gruß Wolfgang
Geht nicht gibts nicht

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von a-dead-trousers (Top Expert / 4370 / 222 / 1174 ) »
Romaniac hat geschrieben:
15.10.2024 11:43
Ich werde meine Entwicklung am Nachmittag nochmal genauer ansehen und gebe dann Rückmeldung.
Ich würde das ändern:
Romaniac hat geschrieben:
15.10.2024 09:46
Währung ist auf 0 Nachkommastellen definiert
Der SAP-Standard erwartet hier zwei Nachkommastellen.
Bei der Ausgabe im SALV werden dann zwar Nachkommastellen angezeigt, aber das ist weniger problematisch als falsche Dezimalpunktsetzung.
Alternativ, wenn du die Ausgabe ohne Nachkommastellen haben willst musst du entweder eine EDIT-Maske angeben oder gleich eine eigene Spalte verwenden, wo du den Inhalt als (vorformatierten) Text ausgibst.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von a-dead-trousers (Top Expert / 4370 / 222 / 1174 ) »
Ich glaube das Problem für die Darstellung liegt an der Tabelle TCURX. Laut ABAP Hilfe vom Zusatz CURRENCY des WRITE Befehls wird die Anzahl der anzuzeigenden Nachkommastellen durch CURRDEC bestimmt.
https://help.sap.com/doc/abapdocu_750_i ... ITION_6@6@
JPY hat hier einen Eintrag, während KRW keinen Eintrag hat. Was eine Änderung hier für Auswirkungen hätte, kann ich leider nicht abschätzen. Ich würde eine OSS-Meldung empfehlen um sich das Verhalten von KRW im Gegensatz zu JPY erklären zu lassen bzw. nachzufragen ob es nicht eine "aktualisierte" Konfiguration für KRW ohne Nachkommastellen gibt.

EDIT:
Okay, ich habs doch ausprobiert und wie ich erwartet habe, wird durch Setzen von KRW = 0 der Wert 1322506 als 132.250.600 ausgegeben. Sprich die auf der Datenbank gespeicherten Werte werden automatisch in der Ausgabe mal 100 gerechnet. Also, Finger weg!!! Außer man kann dem Chef diese "wundersame" Geldvermehrung glaubwürdig verkaufen 😅
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von Romaniac (Specialist / 216 / 62 / 27 ) »
Hallo ADT,

ich kann dem Kunden nicht seine Währungen verstellen, wer weis was da schon alles an Programmen rumfliegt die die Nachkommastellen selbst schon angepasst haben im Code. Ich werde wohl das Komma verschieben müssen vor der Ausgabe? Aber das kann es doch echt nicht sein...
Bei einem anderen Kunden ist die selbe Einstellung für KRW und JPY im System, Decimals = 0, daran darf es eigentlich nicht liegen.
Geht nicht gibts nicht

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von a-dead-trousers (Top Expert / 4370 / 222 / 1174 ) »
Romaniac hat geschrieben:
15.10.2024 12:46
Bei einem anderen Kunden ist die selbe Einstellung für KRW und JPY im System, Decimals = 0, daran darf es eigentlich nicht liegen.
Doch. Der jetztige Kunde hätte vor der "Inbetriebnahme" der Währung den KRW Eintrag machen müssen. Dann würden die Werte zur Aufbereitung passen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von Romaniac (Specialist / 216 / 62 / 27 ) »
Hallo ADT,

Sorry für die Verspätung, hat bei einem Kunden hat ein Thema mal wieder mal gebrannt und gestern war ich bei einem anderen Kunden Stuttgart.

Ich habe jetzt bei meinem Problemkunden (links) und bei einem anderen die Transaktion für Währungsumerechung (EWCT) gestartet für eine Umrechnung 100 EUR -> KRW, gleiches Customizing mit KRW ohne Nachkommastellen, aber auch gleiches Ergebnis. Ich denke an dem Customizing kann es nicht liegen:
EUR_KRW.jpg
Geht nicht gibts nicht

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von Romaniac (Specialist / 216 / 62 / 27 ) »
Ich komme nicht dahinter, ich habe jetzt die Werte aus dem BAPI bei Währung mi Nachkommastelle = 0 durch 100 geteilt.

Wenn ich in einem Testprogramm für dieses Betragsfeld das referenzierende Währungsfeld leer lasse, werden die Werte richtig angezeigt, sobald ich da KRW reinschreibe konvertiert es die Werte * 100 mit 2 Nachkommastellen
Geht nicht gibts nicht

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von tar (ForumUser / 81 / 18 / 27 ) »
Romaniac hat geschrieben:
17.10.2024 11:34
Ich habe jetzt bei meinem Problemkunden (links) und bei einem anderen die Transaktion für Währungsumerechung (EWCT) gestartet für eine Umrechnung 100 EUR -> KRW
Sieht hier so aus - KRW mit und JPY ohne Dezimalstellen, JPY in TCURX mit 0 Dezimalstellen gepflegt:

krw.png
jpy.png

Re: CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe

Beitrag von Romaniac (Specialist / 216 / 62 / 27 ) »
Hallo zusammen,

ich habs... der BAPI_COSTESTIMATE_GETDETAIL, der mir die Kalkulation liefert, rechnet intern schon mit BAPI_CURRENCY_CONV_TO_EXTERNAL auf externe Darstellung um, der SALV macht das dann nochmal... Zuerst habe ich den Sinn dahinter nicht verstanden, aber dann wurde es mir klar: Da der BAPI auch von Extern aufgerufen werden kann, geht der Aufrufer davon aus, das er eine aufbereitete Währungsdarstellung bekommt.

Ich habe jetzt nach dem Aufruf der Kalkulation mit dem BAPI BAPI_CURRENCY_CONV_TO_INTERNAL das wieder zurück gedreht.

Jetzt mache ich das schon so lange, aber dieses Problem hatte ich bisher noch nicht.

Vielen Dank nochmal für die vielen Antworten und Lösungsversuche,

ein schönes Wochenende,

Gruß Wolfgang

Folgende Benutzer bedankten sich beim Autor Romaniac für den Beitrag:
Thomas R.

Geht nicht gibts nicht

Seite 1 von 1

Vergleichbare Themen

1
Antw.
3735
Views
Dezimalstellen eines QUAN bei OO-ALV Ausgabe einschränken
von Foerstar » 08.12.2016 14:28 • Verfasst in ABAP Objects®
1
Antw.
1965
Views
Cl_SALV-Table Summe +Währung automatisch ausgeben
von Bright4.5 » 17.08.2018 19:38 • Verfasst in ABAP® für Anfänger
3
Antw.
1781
Views
Falsche Ausgabe mit WRITE_FORM
von ABAP - Programmierer » 25.01.2006 16:21 • Verfasst in ABAP® für Anfänger
1
Antw.
1871
Views
Falsche Ausgabe nach CALL SELECTION-SCREEN
von Wolke » 02.04.2014 15:42 • Verfasst in ABAP® für Anfänger
2
Antw.
4891
Views
Salv Table - Layouts speichern
von JohnLocklay » 14.06.2019 11:33 • Verfasst in ABAP Objects®

Ü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

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.