Datentyp Ausgabeformat (Entitätenwizard)

[Mdoerr]

Hallo,

folgendes Problem: Wir haben für die Menge in der Stückliste sowohl ganzzahlige als auch Kommazahlen. Ich möchte gerne als Ausgabeformat haben (Datentyp 9,4):

Variante 1 (einfach aber nicht schön)
alles wird mit 4 Nachkommastellen angezeigt

Variante 2 (geht mit Ausgabeformat #,##0.####)
Eingabe > Darstellung
14 > 14
14,1 > 14,1
14,1234 > 14,1234

unschön ist in diesem Fall daß die Eingabe seltsam interpretiert wird:
10111 > 10,111
10,111.222 > 10.111,222
zum einen muss man mit Punkt und Komma vertauscht eingeben zum anderen scheinen mit 4 oder mehr Stellen mit Nachkommastellen interpretiert zu werden (xxxx > x,xxx)

Variante 2.1 (0.###)
Funktioniert besser als 2.0, muss ich halt auf 1000er Trennzeichen verzichten (ist i.O.)

Variante 3 (perfekte Lösung)
Zahlen wie Variante 2 aber zusätzlich (leer) > „NB“ wahlweise 0 > „NB“

Die Darstellung sollte idealerweise im Layout und in Tabellen (Unterformularen) gleich sein.

Selbst wenn die Varianten 2/3 gehen sollten… muss das dann in jedem Jsaperreport auch entsprechend formatiert werden ?

Danke !

Gruß, Matthias

[Hugo]

Hallo!

z.B. so: [#.# ‚NB‘] würde [14 NB] oder [14,1234 NB] ergeben
Die eckigen Klammern sollen nur die Begrenzer sein

Ob ich das mit ‚NB‘ richtig verstanden haben weis ich nicht, sollte aber zur Ideenfindung helfen.

Das Nuclos Ausgabeformat hat mit iREport nichts zu tun, muss also im immer seperat werden.

Gruß
Hugo

[F.pavlic]

Hallo Matthias,
kannst Du bitte ein Beispiel für dein gewünschstes Ergebnis, wie für Variante 2, posten?

Dann verstehe ich es auch vielleicht, was genau Du erreichen willst!

Gruß
Frank

[Mdoerr]

sorry für die späte Antwort…

Was mir wichtig wäre:
Ich möchte den Wert mit bis zu 4 Nachkommastellen eintragen können, möchte diesen jedoch nur so genau anzeigen wie eingegeben wurde – NICHT GERUNDT (sprich: Nullen am Ende nicht anzeigen. Beispiele: 20,0000 anzeigen als 20 | 20,1200 anzeigen als 20,12).

Falls das nicht geht – so wäre es schön wenn das als Optimierung irgendwann in Nuclos aufgenommen werden würde, da es das lesen von Zahlen doch deutlich vereinfacht.

Optional zusätzlich:
„.“ als 1000er Trennzeichen. ABER: Es darf nicht so sein wie oben beschrieben daß ich TausendEinhundertKommaFünf als „1,100.5“ eingeben muss um „1.100,5“ zu erhalten. Auch darf es nicht sein daß die Eingabe „1100“ als 1,100 interpretiert wird. Da scheint Nuclos bei der Eingabe auf Grund des Ausgabeformats etwas falsch zu interpretieren (mir ist aber nicht klar wie da im Hintergrund die Zusammenhänge sind)

Dies funktioniert anscheinend mit Zahlenformat 0.#### (nur kurz getestet)

Optional zusätzlich:
Die Eingabe „0“ bzw. „0,0000“ wird nicht als Zahl sondern als „NB“ angezeigt (obwohl natürlich in der Datenbank Tabelle der Wert „0,0000“ hinterlegt ist. Die Logik dahinter ist daß Stückzahl „0“ = undefiniert ist und somit der Mitarbeiter die Position nach Bedarf verwendet (Typisches Beispiel ist Loctite (Kleber für Schraubensicherung) wo eben nicht vorab definiert werden kann wieviel Tropfen oder Milliliter benötigt werden).

Falls das nicht geht – dann machen wir einfach ein Ja/Nein Feld zusätzlich welches beim Anwählen „0“ in die Menge schreibt.

Gruß, Matthias

[F.pavlic]

Hallo Matthias,
Folgendes Zahlenformat müsste das gewünschte Ergebnis liefern: #,##0.##
Bei der Eingabe der Zahlen musst Du den Punkt nicht angeben, der wird bei Bedarf automatisch eingefügt.

Zum 0 -> NB Problem:
Du willst in einem Zahlenfeld aktiv Zahlen eingeben können und bei 0 soll dann Text angezeigt werden ? Das beisst sich mit der Definition eines Zahlenfeldes !

Die Lösung ist tatsächlich ein Ja/Nein-Feld, wie bereits von dir beschrieben. Zusätzlich kannst du das Feld „Menge“ deaktiveren, wenn das Boolean-Feld auf „Ja“ steht.

Gruß
Frank

[Mdoerr]

Hallo,

Danke für die schnelle Antwort. Wie von Dir beschrieben werden wir das wohl mit dem Ja/Nein Feld lösen.

Die vorgeschlagene Lösung #,##0.#### habe ich in meinem ersten Beitrag bereits beschrieben. Bei diesem Zahlenformat interpretiert Nuclos Eingaben falsch.

Aus Eingabe 11,004.11 wird 11.004,11
Aus Eingabe 11004 wird 11,004

Somit nicht praktikabel. Aber für mich reicht es wie gesagt aus Das Problem mit „NB“ mit dem zusätzlichen Feld zu lösen und auf das Tausendertrennzeichen zu verzichten.

Gruß, Matthias

[F.pavlic]

Hallo Matthias,
komisch, denn dieses Zahlenformat verwenden wir in unserem System und es tut genau das, was es soll. Welche nuclos-Version hast Du im Einsatz, das so ein Problem verursacht?
Es sieht sehr danach aus, als dass dein Java nicht auf „Deutsch“ eingestellt ist. Denn dieses Format sieht nach US-Einstellungen aus . Welche Spracheinstellungen hast Du im Client-PC?

Gruß
Frank

[Mdoerr]

Hallo Frank,

habe eben nochmals getestet. Zahlenformat #,##0.####
Eingabe 10001 wird zu 1000,1 (falsch)
Eingabe 1000 wird zu 1 (falsch)
Eingabe 1000,0 wird zu 1 (falsch)
EIngabe 1000.0 wird zu 1 (falsch)
Eingabe 1000,1 wird zu 1.000,1 (richtig)
Eingabe 1000.1 wird zu 1.000,1 (richtig)

Installiert ist:
Java 7 Update 45
Nuclos 3.15.5

Unter Regions- und Spracheinstellungen (Windows Systemsteuerung) ist in allen Reitern „Deutsch (Deutschland)“ eingetragen (gilt für Server und Client).

Gruß, Matthias

[F.pavlic]

Hallo Matthias,
ich habe nuclos-Version 3.14.9 im Einsatz. Kann natürlich sein, dass die 3.15.5 da ein Problem eingeführt hat, wäre ja leider nicht das Erste. Datumsfelder sind auch nicht ganz so funktional 🙁

Hast Du noch eine 3.14-er Version? Dann kannst Du damit noch einmal verifizieren. Natürlich musst Du dann auch die Java 7 Version downgraden!

Gruß
Frank

[Mdoerr]

Hallo Frank,

leider haben wir keinen „alten“ Snapshot mehr. Aber zum Zeitpunkt des ersten Posts hatten wir 3.14.10 installiert. Nach dem Upgrade auf 3.15.5 haben wir die Snapshots aufgelöst. Da ich aber problemlos auf das Tausendertrennzeichen verzichten kann werd ich erstmal nicht weiter nachforschen.

Gruß, Matthias

[Autor]

Beiträge