Probleme mit Zahlenanzeige/Berechnung mit verschiedenen Ländereinstellungen

[angihofi]

Hallo zusammen!

Ich bin neu hier (habe zwar schon oft viele nützliche Beiträge gelesen, aber noch nix selber verfasst) 

Ich habe folgendes Problem:

Bei uns schreiben User aus verschiedenen Ländern (mit verschiedenen Regions- und Sprachoptionen) Angebote mit Notes. Die Preisanzeige in den Angeboten passt solange nicht Benutzer mit verschiedenen Ländereinstellungen das gleiche Angebot bearbeiten.

Wenn jetzt z. B. ein Benutzer mit englischer Einstellung ein Angebot, das von einem User mit deutscher Einstellung verfasst wurde, öffnet dann werden ihm die Preise mit deutschen Trennzeichen angezeigt (d.h. 1000 Trennung . und Dezimaltrennzeichen ,)

Die Preise werden in einer Textliste abgespeichert. Bei der Generierung eines PDF-Angebots kommt es dann zum Fehler. Bei der Ermittlung des Gesamtpreises pro Position (Menge * Einzelpreis) wird dann bei der Umwandlung mit cdbl() das , als englische 1000 Trennung angesehen und die Preise werden falsch angezeigt, d.h. 0,41 * 100 wird zu 41.00 * 100

Ich hab' schon im Forum gesucht aber keine Lösung gefunden. Habt Ihr eine Idee wie ich bewerkstelligen kann dass die Preise unabhängig vom Land korrekt berechnet werden?

Vielen Dank.

Grüße, angihofi

[koehlerbv]

Das ist eine typische und logische Folge von Verwendung falscher Datentypen. Du musst Zahlen in Zahlenfelder schreiben, nur dann funktioniert auch die Verwendung unterschiedlicher länderspezifischer Einstellungen.

Bernhard

[Tode]

Es gibt nur sehr wenige Fälle, wo man Zahlenfelder in Textfelder schreiben MUSS (ich hatte kürzlich so einen Fall, weil ich Daten zwischen Dokumenten per Lookup austauschen musste, und nicht 30 Lookups machen konnte, sondern das zu einem einzigen Lookup bündeln musste), aber dann darf man sich nicht auf @text verlassen, da man nie weiss was man kriegt, sondern muss dafür sorgen, dass im textfeld immer ein DEFINIERTER Zustand steht (also z.B. immer mit Komma als Dezimaltrennzeichen).

Für bearbeitbare Felder ist das nicht zuverlässig möglich, weshalb ich Bernhard zustimmen muss: Benutze Zahlenfelder, und das Problem löst sich von selbst.

Tode

[marschul]

Und noch eine Ausnahme:
Ich war auch erst entsetzt, als ich sah, das wir hier Anwendungen haben, die ganz viele Zahlenwerte in Textfeldern speichern.
Grund: Es werden Beträge für unterschiedliche Währungen erfasst oder berechnet. Dabei gibt es abweichende Dezimalstellen (JPY = 0 Nachkommastellen, z.B. EUR = 2 Nachkommastellen). Das wird dann häufig über die Eingabeübersetzung geregelt (z.B. @Text(@ThisValue; @If(ISO = "JPY"; "F,0"; "F,2")), vorher natürlich prüfen, ob eingegebener Wert auch als Zahl interpretiert werden kann, ThisValue ist hier nur exemplarisch eingesetzt, die @Text-Funktion liefert hier nur brauchbare Ergebnisse, wenn stattdessen tatsächlich eine Zahl übergeben wird, was in einem Textfeld natürlich nicht der Fall ist - also vorher umwandeln) - gewöhnungsbedürftig, funktioniert aber. Leider bietet ein Zahlenfeld entsprechende dynamische Funktionen (bedingte Anzahl Dezimalstellen) nicht an. Problematisch würde es natürlich werden, wenn das Zahlenformat auch noch abhängig von der Region des Clients unterschiedlich dargestellt werden muss, dann böte sich wahrscheinlich an, ein reines Zahlenfeld für die Eingabe zu benutzen und ein Berechnet-zur-Anzeige-Feld mit der Berücksichtigung aller Rahmenbedingungen...
Insgesamt gebe ich Bernhard gern Recht