Ganz- und Fliesskommazahlen auch ohne Formatierung für LaTeX

[wulf@…]

Der anhaengende Patch ermoeglicht ohne tiefen Eingriff die unformatierte
Uebergabe von Zahlen an LaTeX-Templates und fuehrt den Wert
linetotal_raw ein.

Neuer Configparamter in config/lx-erp.conf.[default]
latex_templates_unformated_numbers = [0|1]
1 führt dazu, das Ganz- und Fliesskommazahlen ohne Formatierung an
die Latexvorlagen uebergeben werden. Ist der Parameter nicht vorhanden
(config/lx-erp.conf nicht aktualisiert) verhaellt sich das System wie
gewohnt. Dies ermoeglicht Rechenoperationen und Formatierungen innerhalb von Latex
ohne das des Zahlenformat des aktuellen users kennen/analysieren zu muessen.

Analog zu <%linetotal%> gibt es nun zusaetzlich <%linetotal_raw%>, dabei
handelt es sich um den gleichen Wert, der allerdings statt auf 2 nur auf
8 Stellen nach dem Komma gerundet wurde. Dies ermoeglicht ein _sauberes_
Rueckrechnen der Umsatzsteuer um z.B. abhaengig vn Template, Kundentyp
oder aehnlichem Rechnungen mit Bruttopreisen zu erzeugen, ohne in
der Rechnung die Option Steuer_im_Preis_inbegriffen auszuwaehlen und
Andere Preise eingeben zu muessen.

FYI <%sellprice%> wird ohnehin schon ohne Rundung weitergegeben.

Es gab dazu einige Diskusion:
​https://lx-office.linet-services.de/bugzilla/show_bug.cgi?id=1393
​http://sourceforge.net/mailarchive/message.php?msg_name=a935743a897c18c8e884b20ac3d8a062.squirrel%40weitan.org

Aktuell greift das Runden nur fuer die Zeilensumme und die Formatierung
nur bei LaTeX. Die Formatierung koennte man auch leicht fuer andere
Templates deaktivieren (auch wenn ich glaube hier ist das Beduerfnis
nicht so gross), Fuer die exportfunktionen muesste ich es mir anschauen.

Beim Runden ist das nicht so trivial, deswegen ersteinmal den Wert der
mir immer Aerger gemacht hat, andere kann ich gerne bei Bedarf
nachruesten.

Lxo trennt nicht eindeutig (das scheint alles doch sehr historisch
gewachsen) die Aufbereitung der Daten fuer die Anzeige im Browser und
zur Weitergabe an die Templates. (So kann man zum Beispiel, eine
Rechnung mit neuen Werten ausdrucken, obwohl diese sich nicht mehr
speichern laesst (und beim naechsten Aufruf natuerlich auch wieder die
alten Daten enthaellt)). Also mal eben laesst sich hier keine gut
strukturierte allgemeine Loesung finden. Grundsaetzlich halte ich hier
eine Umstruckturierung fuer Sinnvoll und wuerde mich da auch einbringen,
aber das geht nur nach Absprache der Marschrichtung. Ich kann auch
verstehen, das das Thema nicht oberste Prioritaet hat.

Patch zur Unformatierten Ausgabe von Zahlen

Gesehen, kurz drüber geschaut. Das Konzept ist gut, steht ja seid März ausserfrage. Zur Umsetzung noch zwei Frage:

1. Es gibt bereits eine Funktion die das Gegenteil von format_amount macht, das ist parse_amount. Gibt es einen Grund, dass Du das in Template/Simple? manuell machst?

2. Das format_amount was das Userencoding erzeugt steht direkt eine Zeile darüber, warum nicht das konditional machen?

Habe noch einmal einen alternativen Patch angehaengt.

1. Es gibt bereits eine Funktion die das Gegenteil von format_amount macht, das

ist parse_amount. Gibt es einen Grund, dass Du das in Template/Simple? manuell
machst?

SL::Form::parse_amount() erwartet einen formatierten numeric Wert, ich
schicke aber alles durch. Man kann natuerlich auch parse_amount anpassen,
und Du hast recht, es ist schicker. Am schoensten waere es in
SL::Template::Plugin::LxERP::format_amount() gewesen, aber da geht
leider nicht alles durch.

Ausserdem muss der Wert fuer latex_templates_unformated_numbers in
config/lx-erp.conf.default natuerlich 0 und nicht 1 heissen.

2. Das format_amount was das Userencoding erzeugt steht direkt eine Zeile

darüber, warum nicht das konditional machen?

Verstehe ich nicht. In SL::Template::Simple::substitute_vars steht
format_string drueber und das ist das Latex-Escaping, oder was meinst
Du?

Ersat fuer ersten patch

Siehe:
​https://lx-office.linet-services.de/bugzilla/show_bug.cgi?id=1497#c2

Der Chunk in SL/TEmplate/Simple.pm den Du geändert hast war genau das was ich mit (In reply to comment #2)

Habe noch einmal einen alternativen Patch angehaengt.

SL::Form::parse_amount() erwartet einen formatierten numeric Wert, ich
schicke aber alles durch. Man kann natuerlich auch parse_amount anpassen,
und Du hast recht, es ist schicker. Am schoensten waere es in
SL::Template::Plugin::LxERP::format_amount() gewesen, aber da geht
leider nicht alles durch.

Ich verstehe zwar nicht was Du damit meinst, aber der Chunk in SL/Template/Simple.pm ist genau das was ich meinte.

2. Das format_amount was das Userencoding erzeugt steht direkt eine Zeile

darüber, warum nicht das konditional machen?

Verstehe ich nicht. In SL::Template::Simple::substitute_vars steht
format_string drueber und das ist das Latex-Escaping, oder was meinst
Du?

Mein Fehler. format_string ne format_amount.

Moin wulf. Ich hab mir das nochmal genauer angeschaut, und so kann das nicht eingespielt werden. Ich weiß jetzt auch was Du mit "parse_amount erwartet einen numeric wert, ich schicke aber alles durch" meintest, das klappt aber nicht so, wie Du Dir das vorstellst.

Die Zeile

return $val_org unless $amount =~ /^{-?(\d+\.?\d*|\.\d+)$/;}

versucht an der Struktur der Daten festzustellen was für ein Datentyp das ist, aber das geht nicht. Man kann nicht unterscheiden ob ein String aussieht wie eine Zahl aber keine ist. Die IP "192.168.101.100" würde im Format "1.000,00" durch die Rexexes umgewandelt in "192168101100", und das würde als korrekte Zahl anerkannt. Gleiches passiert mit dem Datum "12.3.2010".

Das hat auch nichts damit zu tun ob das ganze in SL::Template::Simple oder in SL::Form steht, wobei allerdings parse_amount und format_amount so zentral sind, dass man da besonders vorsichtig sein muss.

(Btw der Ansatz ist für andere Zwecke brauchbar, aber nicht um nachträglich Formatierungen rückgängig zu machen).

alterntive Umsetzung

Moin wulf. Ich hab mir das nochmal genauer angeschaut, und so kann das
nicht eingespielt werden.

Leider finde ich keine schoene generische Loesung das formatieren von vorneherien zu verhindern, da beim Beschreiben von

$form->{TEMPLATE_ARRAYS}->{foo} = $form->format_amount($myconfig, foo, 2 )

noch nicht klar ist, fuer welches Template das mal verwendet wird. Das
gleiche gilt natuerlich fuer Werte die nicht Zeilendetails betreffen.

Der Anhaengende Patch fuehrt nun einfach zusaetzliche Parameter ein. Das
tut er vor allem in {TEMPLATE_ARREYS} koennte das aber auch an anderer
Stelle noch tun (da habe ich es aber noch nicht vermisst und daher
erstmal weggelassen). Fuer das Runden gilt, was ich ganz oben
geschrieben habe.

Ueber Namenskonventionen kann man natuerlich reden, schau Dir auch mal
changelog und doc/dokumentenvorlagen-und-variablen.html an.

Fuer Feedback bin ich gerne zu haben.

aktuelle patches unter

​git://gpl.coulmann.de/git/lxo-wulf.git

branch: publish_1497_raw_numbers

rebased to

commit 915e943a8fa8ab2a32576d4609632d598898cf20
Merge: 7b47939 27ae865
Author: C. Braun <information@…>
Date: Fri May 13 15:46:47 2011 +0200

Den jetzigen Ansatz finde ich prinzipiell gut, habe aber einen Punkt zu bemängeln: die Namensgebung. Einfach nur "_num" anzuhängen, finde ich leicht irreführend. Es soll ja für "numeric" stehen, wobei aber auch die formatierten Werte numerisch sind. Außerdem wird "num" oft genug für "number of..." benutzt, sprich "Anzahl".

Lieber wäre mir ein Prä- oder Postfix, das in Richtung "unformatiert" geht. Beispielsweise "_unformatted", "_raw", "_nofmt", "_unfmt". OK "_raw" mag ich auch nicht so ganz. Lieber eine der anderen Varianten.

Wenn du das entsprechend änderst, übernehme ich es noch in die kommende 2.6.3.

branch: publish_1497_raw_numbers

commit 12b4dfe70cc3b202910f5833650cdeb07d8fae9f
Author: wulf@… <wulf@…>
Date: Mon May 16 18:49:35 2011 +0200

Variablenwerweiterung nun _nofmt statt _num

changelog habe ich auch angepasst

commit a0308172a3cba5ac42de0784c8cc5b84fd61234b
Author: wulf@… <wulf@…>
Date: Mon May 16 19:23:54 2011 +0200

_raw entfehrnt

Danke für die Anpassungen. Ich hab den Branch nochmal auf "eben gerade master" rebaset, einige Kosmetik-Fixes (Einrückung) gemacht und gepusht.