im IMG gibt es die Möglichkeit, bei Währungen die Anzahl der Dezimalstellen einzugeben. Wenn ich mir mit der SE11 die BSEG anschaue, sind da 2 Nachkommastellen bei den Betragsfeldern reserviert. Ich nehme an, dass es intern wahrscheinlich gar keine Nachkommastellen gibt. Mir geht esnun darum, wie das System das handelt, wenn ich bei einer Währung 3 Dezimalstellen festlege. Was passiert, wenn ich den Betrag aus der BSEG auslese? Erhalte ich dann schon den Betrag in rihctiger Form oder muss ich den dann noch um eine Stele nach rechts verschieben?
Hat jemand von Euch damit schon Erfahrung gemacht?
Ich suche eine Doku oder etwas Ähnliches zu diesem Thema. Hat jemand einen Tipp für mich?
Herzlichen Dank,
Blueshape
Ich bin für alles offen, solange es anderen nicht ernsthaft schadet.
tabellenintern werden die Währungsbeträge immer so abgelegt, dass die Zahl mit den Anzahl Nachkommastellen in das Währungsfeld geschrieben werden.
Betragsfeld: 13,2
Aber so ganz habe ich nicht verstanden, wie Du das meinst. Wenn ich z.B. EUR auslese aus der BSEG und dann ausgebe, dann weiß das System doch auch, dass es 2 Nachkommastellen ausgeben muss, ohne dass ich explizit eine Verbindung zur Währung herstelle.
Also, Du sagst, ich muss immer die Währung referenzieren, damit ich immer die richtige Anzahl Nachkommstellen in der Ausgabe habe?
Ich dachte, es gibt es zu jedem Betrag die Währung in der Tabelle und somit wäre für mich die Aufbereitung klar?
Viele Grüße,
Blueshape
Ich bin für alles offen, solange es anderen nicht ernsthaft schadet.
ja, das ist so richtig! Sonst kommt eventuell Müll heraus.
Du wirst diverse Stellen im SAP-System finden, wo das Währungskennzeichen nicht in der gleichen Tabelle steht wie der Betrag.
Das gilt z.B. für BKPF/BSEG und die Belegwährung: Betrag BSEG-WRBTR und Währung BKPF-WAERS bzw BSEG-DMBTR/T001-WAERS (Hauswährung).
Das bedeutet, dass Du im einfachsten Fall im Dynpro ein Feld BSEG-WRBTR anlegst und im ABAP in der Struktur BKPF in WAERS die Währung hineinschreiben musst, damit immer die richte Aufbereitung benutzt werden kann. Benutzt Du im Dynpro andere Feldnamen, musst Du dort auch die Referenz auf die entsprechenden Felder setzen.
Gruß
Ereglam
May the Force be with your code || .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
ok für die Ausgabe mit write ist mir das nun klar. Aber wenn ich etwas mit den Beträgen rechnen will, wie mache ich das dann? Das wirkt sich doch sicherlich auch in anderen Module dann aus. So wie das aussieht, ist das nicht zu empfehlen mit den 3 Nachkommastellen, wenns zu verhindern ist
Also muss ich immer aufpassen, dass die richtige Anzahl Dezimalstellen dabei ist, wenn ich mit Beträgen arbeite, die nicht zwei Nachkommastellen haben?
Viele Grüße,
Blueshape
Ich bin für alles offen, solange es anderen nicht ernsthaft schadet.
Hallo Blueshape,
solange Du in einer Währung bleibst dürfte doch nichts passieren. Und EUR mit DEM multiplizieren/addieren... macht ja nicht viel Sinn.
ich will das Problem mal kurz darstellen, auch wenn ich in einer Währung bleibe:
Normal auf dem Papier.
1,567 x 1,567 = 2,455489
Wenn die interne Speicherung aber ohne Nachkommastellen ist dann habe ich doch
1567 * 1567 = 2455489. Und wenn ich nun ein Komma setze bei 3 Nachkommastellen (weil ich dem System erst jetzt bei der Ausgabe sage "dieser Betrag ist die Währung XYZ"), dann habe ich diesen falschen Betrag 2455,489 in XYZ.
Und nun ???
Ich bin für alles offen, solange es anderen nicht ernsthaft schadet.
Hallo Blueshape,
bei Deinem Beispiel hast Du dann eine Währung hoch 2, auch dies macht nicht viel Sinn im SAP Umfeld. Mir jedenfalls ist kein Beispiel bekannt.
Ist nur einer der Faktoren eine Währung, spielen die Nachkommastellen keine Rolle - von daher war mein Beispiel vorher nicht wirklich hilfreich.
so ein Fall dürfte durchaus eintreten, wenn man z.B. Menge mit Betrag rechnet.
Meines Wissens sind bei den FI-Bausteinen, die mit Währungen rechnen, die Festkomma-Arithmetik abgeschaltet und der Programmierer muss sich selbständig um Kommasetzung kümmern.
Das würde in diesem Beispiel bedeuten, dass er die 3 Nachkommastellen aus dem Betrag plus die 3 Nachkommstellen aus der Menge addieren muss und das Ergebnis (hier 2455489) durch 10**6 (10 hoch 6) dividieren muss => 2,455489.
Gruß
Ereglam
May the Force be with your code || .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Na klar gibt es den von ereglam beschriebenen Fall.
Und die Probleme gibt es nur bei abweichenden Währungen (Dezimalen <> 2) - wie von blueshape beschrieben. Bei den anderen greift die automatische Konvertierung bei unterschiedlichen Genauigkeiten.
Es war jedenfalls schon mal gut, dass ich das nicht gleich eingeführt habe, ohne mir Gedanken darüber zu machen.
Ich denke, wenn es nicht lebensnotwendig sollte man davon abraten. Man muss zuviel beachten, alte Programme prüfen und umprogrammieren und bei den neuen immer aufpassen.
Dieser Fall tritt bei uns nur auf, weil unser Payrollsystem die Beträge mit 3 Nachkommastellen ausgibt und auch an SAP weitergibt.
Ich denke, es ist sinnvoller in dem Payrollsystem auf die 3. Stelle zu verzichten, denn der Wert dieser 3. Nachkommastelle geht gegen Null.
Vielen Grüße,
Blueshape
Ich bin für alles offen, solange es anderen nicht ernsthaft schadet.