CL_SALV_TABLE Währung ohne Dezimalstellen falsche Ausgabe
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
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.
Bin nach einigen Stunden Suche für Tipps dankbar...
Gruß Wolfgang
Hier nochmal alles zusammengefasst:
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
Bin nach einigen Stunden Suche für Tipps dankbar...
Gruß Wolfgang
Hier nochmal alles zusammengefasst:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Geht nicht gibts nicht
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
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:
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
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
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Hier ein etwas besseres Beispiel:
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:
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( ).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
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
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Ü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.
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
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
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
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
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Ich würde das ändern:
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
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
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
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 😅
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
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
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.
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
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
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
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
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:
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:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Geht nicht gibts nicht
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
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
Sieht hier so aus - KRW mit und JPY ohne Dezimalstellen, JPY in TCURX mit 0 Dezimalstellen gepflegt:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
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
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
Geht nicht gibts nicht
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
3761
Views
Views
Dezimalstellen eines QUAN bei OO-ALV Ausgabe einschränken
von Foerstar » 08.12.2016 14:28 • Verfasst in ABAP Objects®
von Foerstar » 08.12.2016 14:28 • Verfasst in ABAP Objects®
1
Antw.
Antw.
1974
Views
Views
Cl_SALV-Table Summe +Währung automatisch ausgeben
von Bright4.5 » 17.08.2018 19:38 • Verfasst in ABAP® für Anfänger
von Bright4.5 » 17.08.2018 19:38 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
1808
Views
Views
Falsche Ausgabe mit WRITE_FORM
von ABAP - Programmierer » 25.01.2006 16:21 • Verfasst in ABAP® für Anfänger
von ABAP - Programmierer » 25.01.2006 16:21 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
1885
Views
Views
Falsche Ausgabe nach CALL SELECTION-SCREEN
von Wolke » 02.04.2014 15:42 • Verfasst in ABAP® für Anfänger
von Wolke » 02.04.2014 15:42 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
4984
Views
Views
Frage die ABAP Experten
Ü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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 18 Stunden von ralf.wenzel 104 / 10238
vor 18 Stunden von ralf.wenzel 104 / 10238
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 18 Stunden von ralf.wenzel 104 / 10238
vor 18 Stunden von ralf.wenzel 104 / 10238