Writer: Zahlenformat einer Summenberechnung per Formel festlegen

de-users
#1

Moin.

Ich möchte in einer Tabelle in Writer (LO 6.1) eine Summe berechnen.

Das geht über Tabelle > Formel > =sum<B1:B7> (Beispiel)

Aber wie gebe ich dem Ergebnis ein passendes Format?

Zwei Nachkommastellen, Währungszeichen.

Die Hilfe gibt leider dazu nichts her oder ich bin zu ungeschickt.
file:///Applications/LibreOffice.app/Contents/Resources/help/de/text/swriter/guide/calculate_intext2.html?&DbPAR=WRITER&System=MAC

Über einen Tipp freue ich mich.
Danke.

Gruß, Andreas

#2

Andreas Borutta schrieb:

Ich möchte in einer Tabelle in Writer (LO 6.1) eine Summe berechnen.

Das geht über Tabelle > Formel > =sum<B1:B7> (Beispiel)

Aber wie gebe ich dem Ergebnis ein passendes Format?

Zwei Nachkommastellen, Währungszeichen.

Ergänzung:

Das Berechnen der Summe ist leider fehlerträchtig:

Writer kann offenbar mit einem Umbruch vor einer Zahl nicht umgehen
und lässt die Zahl dann aus.

Beispiel:

https://www.dropbox.com/s/up7puj98r8h7q6o/lo-writer-summe-in-tabelle-berechnen.odt

Das richtige Ergebnis lautet:

Writer zeigt 1276,6 an, der Betrag in Zeile 2 wird nicht mit
eingezogen.

Da es auch keinerlei Warnung gibt, ist das eigentlich ein
"Showstopper".

Oder kann man solche Effekte verhindern?

Gruß, Andreas

#3

Binde doch einfach anstatt einer Writer-Tabelle an der Stelle eine Calc-
Tabelle als OLE-Objet ein.
Dann hast Du alle Möglichkeiten.

Gruß

Harry

#4

Hallo Andreas,

Andreas Borutta schrieb:

> Ich möchte in einer Tabelle in Writer (LO 6.1) eine Summe berechnen.
> Das geht über Tabelle > Formel > =sum<B1:B7> (Beispiel)
> Aber wie gebe ich dem Ergebnis ein passendes Format?
> Zwei Nachkommastellen, Währungszeichen.

Mit Rechtsklick in die Ergebniszelle kommst du in das entsprechende
Kontextmenü.

Ergänzung:

Das Berechnen der Summe ist leider fehlerträchtig:

Writer kann offenbar mit einem Umbruch vor einer Zahl nicht umgehen
und lässt die Zahl dann aus.

Das macht Calc genauso. Was sollte eine Additon z.B. des _Textes_
"<CR>123" mit z.B. 456 ergeben?

Da es auch keinerlei Warnung gibt, ist das eigentlich ein
"Showstopper".

Eigentlich müsste es eine Fehlermeldung geben (Typenunverträglichkeit:
Text+Zahl). Aber irgendwer hat dann entschieden, dass in diesem Falle
der Zahlenwert des Textes als 0 zu interpretieren ist. Das war sogar
bei OpenOffice 1.1.5 schon so.

Als Mathematiker wäre mir eine Fehlermeldung lieber, aber
Office-Programme müssen sich ja "intelligent" verhalten.

In diesem Sinne finde ich es noch inkonsequenter das der _Text_ "123"
addiert zur _Zahl_ 456 tatsächlich 579 als Ergebnis ausspuckt.

So wird die "Intelligenz" von Calc manchmal zu einem Problem...

Gruß,
Michael

#5

Hi Andreas,

Moin.

Ich möchte in einer Tabelle in Writer (LO 6.1) eine Summe berechnen.

Das geht über Tabelle > Formel > =sum<B1:B7> (Beispiel)

Aber wie gebe ich dem Ergebnis ein passendes Format?

Zwei Nachkommastellen, Währungszeichen.

Die Hilfe gibt leider dazu nichts her oder ich bin zu ungeschickt.
file:///Applications/LibreOffice.app/Contents/Resources/help/de/text/swriter/guide/calculate_intext2.html?&DbPAR=WRITER&System=MAC

Über einen Tipp freue ich mich.
Danke.

Geht im Writer nur als direkte Formatierung. Also Menu Tabelle > Zahlenformat. Writer hat eine eigene Formelsprache und da gibt es die Funktion "Vorlage" nicht, die du vielleicht von Calc her kennst.

Mit freundlichen Grüßen
Regina

#6

Regina Henschel schrieb:

Das geht über Tabelle > Formel > =sum<B1:B7> (Beispiel)

Aber wie gebe ich dem Ergebnis ein passendes Format?

Zwei Nachkommastellen, Währungszeichen.

Die Hilfe gibt leider dazu nichts her oder ich bin zu ungeschickt.
file:///Applications/LibreOffice.app/Contents/Resources/help/de/text/swriter/guide/calculate_intext2.html?&DbPAR=WRITER&System=MAC

Über einen Tipp freue ich mich.
Danke.

Geht im Writer nur als direkte Formatierung. Also Menu Tabelle >
Zahlenformat. Writer hat eine eigene Formelsprache und da gibt es die
Funktion "Vorlage" nicht, die du vielleicht von Calc her kennst.

OK, danke.

Das Zahlenformat wird nicht übernommen, wenn man eine weitere leere
Zeile (oberhalb) einfügt. Uff.

Gruß, Andreas

#7

Dr. Harry Knitter schrieb:

Binde doch einfach anstatt einer Writer-Tabelle an der Stelle eine Calc-
Tabelle als OLE-Objet ein.
Dann hast Du alle Möglichkeiten.

Für einfache Aufsummierungen finde ich es übertrieben 2 Dokumente zu
verwenden/archivieren.

Andreas

#8

Michael Höhne schrieb:

Ich möchte in einer Tabelle in Writer (LO 6.1) eine Summe berechnen.
Das geht über Tabelle > Formel > =sum<B1:B7> (Beispiel)
Aber wie gebe ich dem Ergebnis ein passendes Format?
Zwei Nachkommastellen, Währungszeichen.

Mit Rechtsklick in die Ergebniszelle kommst du in das entsprechende
Kontextmenü.

Wie konnte ich das nur übersehen. Verzeihung bitte.

Im engen Sinne scheint es keine Formatierung zu sein, sondern es wird,
anders als bei Calc, Inhalt in die Zelle eingefügt. Also z.B. ein
Leerzeichen und ein "€".

Und wenn man eine neue Zeile einfügt, übernimmt diese das Format
nicht, aber das hatte ich in der Antwort an Regina schon geschrieben.

Ergänzung:

Das Berechnen der Summe ist leider fehlerträchtig:

Writer kann offenbar mit einem Umbruch vor einer Zahl nicht umgehen
und lässt die Zahl dann aus.

Das macht Calc genauso. Was sollte eine Additon z.B. des _Textes_
"<CR>123" mit z.B. 456 ergeben?

Da Calc auch Text in Form von "123 €" als Zahlwert zum Rechnen
verwenden kann, empfinde ich als überraschen, dass dies bei "<CR>123"
nicht so sein soll.

Da es auch keinerlei Warnung gibt, ist das eigentlich ein
"Showstopper".

Eigentlich müsste es eine Fehlermeldung geben (Typenunverträglichkeit:
Text+Zahl). Aber irgendwer hat dann entschieden, dass in diesem Falle
der Zahlenwert des Textes als 0 zu interpretieren ist. Das war sogar
bei OpenOffice 1.1.5 schon so.

Als Mathematiker wäre mir eine Fehlermeldung lieber, aber
Office-Programme müssen sich ja "intelligent" verhalten.

In diesem Sinne finde ich es noch inkonsequenter das der _Text_ "123"
addiert zur _Zahl_ 456 tatsächlich 579 als Ergebnis ausspuckt.

So wird die "Intelligenz" von Calc manchmal zu einem Problem.

Yep.

Andreas

#9

Hallo Andreas,

Da Calc auch Text in Form von "123 €" als Zahlwert zum Rechnen
verwenden kann, empfinde ich als überraschen, dass dies bei "<CR>123"
nicht so sein soll.

Das macht Calc eben nicht. Es erkennt daraus eine Zahl mit einer
Maßeinheit. Das Feld ist anschließend als "Währungsfeld" formatiert.

Gruß

Robert

#10

Robert Großkopf schrieb:

Hallo Andreas,

Da Calc auch Text in Form von "123 €" als Zahlwert zum Rechnen
verwenden kann, empfinde ich als überraschen, dass dies bei "<CR>123"
nicht so sein soll.

Das macht Calc eben nicht. Es erkennt daraus eine Zahl mit einer
Maßeinheit. Das Feld ist anschließend als "Währungsfeld" formatiert.

Schreibfehler von mir.

Ich meinte Writer.

Aber Du hast trotzdem Recht. Writer verhält sich ähnlich wie Calc.
Auch wenn Writer keine echten Formate kennt, sondern nur Text in Form
von Einheitenzeichen etc. in den Zellinhalt einfügt.

Gruß, Andreas

#11

Ergänzung:

Das Berechnen der Summe ist leider fehlerträchtig:

Writer kann offenbar mit einem Umbruch vor einer Zahl nicht umgehen
und lässt die Zahl dann aus.

Das macht Calc genauso. Was sollte eine Additon z.B. des _Textes_
"<CR>123" mit z.B. 456 ergeben?

Da Calc auch Text in Form von "123 €" als Zahlwert zum Rechnen
verwenden kann, empfinde ich als überraschen, dass dies bei "<CR>123"
nicht so sein soll.

Auch Calc kann den String "<CR>123" nicht als Zahl interpetieren (bzw.
nur als Wert 0, dem Wert der Zahl vor dem ersten Nichtzahlzeichen).

Aber Writer kann im Gegensatz zu Calc auch einen String "123 €" nciht
als Zahl interpretieren (nur einen Wert 123, der als "#" €"" o. ä.
formatiert ist. Das liegt schlicht daran, dass Calc ein
*Tabellenkalkulationsprogramm* ist, und writer ein
*Textverarbeitungsprogramm*. Die haben einfach unterschiedliche
*Schwerpunkte*.

Da es auch keinerlei Warnung gibt, ist das eigentlich ein
"Showstopper".

Eigentlich müsste es eine Fehlermeldung geben (Typenunverträglichkeit:
Text+Zahl). Aber irgendwer hat dann entschieden, dass in diesem Falle
der Zahlenwert des Textes als 0 zu interpretieren ist. Das war sogar
bei OpenOffice 1.1.5 schon so.

Als Mathematiker wäre mir eine Fehlermeldung lieber, aber
Office-Programme müssen sich ja "intelligent" verhalten.

In diesem Sinne finde ich es noch inkonsequenter das der _Text_ "123"
addiert zur _Zahl_ 456 tatsächlich 579 als Ergebnis ausspuckt.

So wird die "Intelligenz" von Calc manchmal zu einem Problem.

Yep.

Andreas

Wolfgang

#12

Hallo Andreas, Michael, ...

Hallo Andreas,

Andreas Borutta schrieb:

Ergänzung:

Das Berechnen der Summe ist leider fehlerträchtig:

Writer kann offenbar mit einem Umbruch vor einer Zahl nicht umgehen
und lässt die Zahl dann aus.

Das macht Calc genauso. Was sollte eine Additon z.B. des _Textes_
"<CR>123" mit z.B. 456 ergeben?

Da es auch keinerlei Warnung gibt, ist das eigentlich ein
"Showstopper".

Eigentlich müsste es eine Fehlermeldung geben (Typenunverträglichkeit:
Text+Zahl). Aber irgendwer hat dann entschieden, dass in diesem Falle
der Zahlenwert des Textes als 0 zu interpretieren ist. Das war sogar
bei OpenOffice 1.1.5 schon so.

Als Mathematiker wäre mir eine Fehlermeldung lieber, aber
Office-Programme müssen sich ja "intelligent" verhalten.

In diesem Sinne finde ich es noch inkonsequenter das der _Text_ "123"
addiert zur _Zahl_ 456 tatsächlich 579 als Ergebnis ausspuckt.

So wird die "Intelligenz" von Calc manchmal zu einem Problem...

die Situation sieht wohl so aus, dass Writer bei der Summenbildung
versucht, auch die Zellen mit Zahlen aber mit dem Format 'Text' zu
berücksichtigen. Ansonsten wird der Wert 0 bei der Summenbildung benutzt.

Eine Berücksichtigung ist nur möglich, wenn der Text eindeutig in eine
Zahl umgewandelt werden kann (z.B. "123", "4,56", "20 €"). Daran stört
man sich als Nutzer auch nicht, man sieht in der Zelle eine Zahl, diese
wird berücksichtigt und das Ergebnis ist richtig.

Wenn nun in der Textzelle echter Text mit Buchstaben oder sichtbaren
Sonderzeichen (mal von Zahlen mit Einheiten wie €, %, ... abgesehen)
steht, stört man sich ebenfalls nicht daran; man sieht einen String, den
man selber nicht als Zahl interpretiert, folglich ist dieser auch bei
der Summenbildung nicht zu berücksichtigen und das Ergebnis ist richtig.

Wenn nun unsichtbare Sonderzeichen, wie z.B. <CR> mit Zahlen kombiniert
werden, funktioniert es nicht mehr. LO kann (zumindest z.Z.) den Wert
nicht eindeutig in eine Zahl umwandeln, berücksichtigt diese Zelle daher
nicht bei der Summenbildung. Als Nutzer sieht man aber in der Zelle eine
Zahl und fragt sich, warum ist das Ergebnis falsch.

Ich nehme an, dass das Verhalten bei Calc und Writer identisch ist.

Hierzu 3 Bug Reports, die sich auch mit diesem Thema beschäftigen:

https://bugs.documentfoundation.org/show_bug.cgi?id=75834
https://bugs.documentfoundation.org/show_bug.cgi?id=37132
https://bugs.documentfoundation.org/show_bug.cgi?id=42990

Eine einfache Lösung sehe ich im Augenblick nicht, da das Feld der
unsichtbaren Zeichen und die Benutzung in LO für einen Laien kaum
überschaubar ist. Außerdem werden Zahlen in verschiedenen Sprachen auch
noch unterschiedlich dargestellt (z.B. im Deutschen: "1,23", im
Englischen "1.23"). Und dabei scheint auch noch etwas buggy zu sein. Und
dann gibt es auch noch unterschiedliche Währungen ... ... ... ...

Grüße
Harald K.

#13

Hallo,

snip

Das Zahlenformat wird nicht übernommen, wenn man eine weitere leere
Zeile (oberhalb) einfügt. Uff.

Mal abgesehen von allen anderen Argumenten: ist es eigentlich Absicht, dass du alle Zahlen
mit "." (Dezimalpunkt) schreibst, ausgenommen die Zeichenkette "40,00 €"? Hier verwendest
du ein Komma als Dezimaltrenner.

Oder habe ich da einen Hinweis überlesen?

#14

Matthias Müller schrieb:

Das Zahlenformat wird nicht übernommen, wenn man eine weitere leere
Zeile (oberhalb) einfügt. Uff.

Mal abgesehen von allen anderen Argumenten: ist es eigentlich Absicht, dass du alle Zahlen
mit "." (Dezimalpunkt) schreibst,

Das kann ich nicht nachvollziehen:
https://www.dropbox.com/s/up7puj98r8h7q6o/lo-writer-summe-in-tabelle-berechnen.odt
https://www.dropbox.com/s/0f06uqioqn4o3gr/Screenshot%202018-08-05%2000.06.45.png

Könnte es etwas mit den regionalen Einstellungen zu tun haben?

Gruß Andreas

#15

Guten Morgen Andreas,

was mir aufgefallen ist, wenn man sich die Formate der einzelnen Zeilen Deiner Tabelle e i n z e l n anzeigen lässt:

#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 1.040,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 26,60 €
@ 40,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 20,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 100,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 26,60 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 50,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 1.303,20 €

Ich würde die Tabelle mal neu anlegen, die Spalte mit "#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407]" einheitlich formatieren, die Zahlen eingeben (mit Dezimaltrenner ",") und anschließend die Summe ( =sum <B1:B7> ) bilden - und dann sollte alles passen.

Gruß
Hans-Werner ;-))

------ Originalnachricht ------

#16

OoOHWHOoO schrieb:

was mir aufgefallen ist, wenn man sich die Formate der einzelnen Zeilen
Deiner Tabelle e i n z e l n anzeigen lässt:

#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 1.040,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 26,60 €
@ 40,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 20,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 100,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 26,60 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 50,00 €
#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407] 1.303,20 €

Ich würde die Tabelle mal neu anlegen, die Spalte mit "#.##0,00
[$€-407];[ROT]-#.##0,00 [$€-407]" einheitlich formatieren, die Zahlen
eingeben (mit Dezimaltrenner ",") und anschließend die Summe ( =sum
<B1:B7> ) bilden - und dann sollte alles passen.

Danke für den Hinweis. Ich habe das Format jetzt vereinheitlicht.

Die Zahlen habe ich nicht neu eingegeben. Einen Dezimaltrenner "."
kann ich nicht erkennen.

Gruß, Andreas

#17

Andreas Borutta schrieb:

Das Zahlenformat wird nicht übernommen, wenn man eine weitere leere
Zeile (oberhalb) einfügt. Uff.

Bedienfehler von mir.

Ich hatte nach dem Einfügen einer neuen Zeile und dem Eingeben einer
Zahl aus Gewohnheit (aus Calc) Enter gedrückt.

Das wandelt das - sehr wohl übernommene Format - in das Format Text
um.

Wenn ich nun den Absatz wieder lösche, bleibt dennoch das Format Text
erhalten.

Wenn ich jedoch nicht den Fehler der Eingabe eines Absatzes mache,
sondern nur mit der Pfeiltaste zur nächsten Zelle wechsele, wird das
korrekte - aus der vorherigen Zeile übernommene Format angezeigt.

Mit Tabellen muss man im Writer ganz schön aufpassen.

Auch die nachträgliche Fehleranalyse ist etwas mühsam, weil es keine
Befehle "Ansicht > Zeige statt des Inhaltes den Formatcode" gibt. Oder
"Ansicht > Zeige statt des Ergebnisses die Formel".

Aber auf jeden Fall ist die Kalkulationsoption in Writer eine tolle
Sache :slight_smile:

Schönen Tag euch allen.

Andreas

#18

Hans-Werner meint vermutlich den Tausendertrenner; aber der darf *nicht*
eingegeben werden, der wird durch das Format eingefügt.

Wolfgang

#19

Was meinst Du mit "[...] Einen Dezimaltrenner "." kann ich nicht erkennen. [...]" ?

Vielleicht hilft das Dir weiter:

[1] Nachkommastellen: 2 + Führende Nullen: 1 + Tausendertrennzeichen: NEIN => 0,00 [$EUR];-0,00 [$EUR]
[2] Nachkommastellen: 2 + Führende Nullen: 1 + Tausendertrennzeichen: JA => #.##0,00 [$EUR];-#.##0,00 [$EUR]

Allerdings, so richtig verstehe ich es selbst nicht :open_mouth: ... hat wohl damit zu tun, dass "." im Kontext von "#" die Bedeutung von Tausendertrennzeichen hat.

Gruß
Hans-Werner ;-))

------ Originalnachricht ------

#20

OoOHWHOoO schrieb:

[1] Nachkommastellen: 2 + Führende Nullen: 1 + Tausendertrennzeichen:
NEIN => 0,00 [$EUR];-0,00 [$EUR]
[2] Nachkommastellen: 2 + Führende Nullen: 1 + Tausendertrennzeichen: JA
=> #.##0,00 [$EUR];-#.##0,00 [$EUR]

Letzteres verwende ich fast immer.