Mal wieder "runden" in Numbers

[Riven]

Hallo zusammen,

die Suche und Google wurden bereits bemüht, allerdings komme jetzt nicht mehr weiter.
Ich habe eine Abrechnungstabelle für unsere Arbeitsgruppe erstellt bzw. eine Vorlage umfangreich angepasst.

In den Tabellen lass ich die Eurobeträge logischerweise auf zwei Stellen hinter dem Komma, womit je nach Ergebnis dann gerundet wird. In der Addition dieser Beträge entstehen dann leider falsche Werte. Ich habe das nach meiner Suche so verstanden, daß Numbers trotzdem die echten und nicht die gerundeten Zahlen addiert (bis zu 5 Stellen hinter dem Komma?). Also ist es im Prinzip kein falscher Wert, sondern der genaue Wert. Leider ist es unterm Strich dann trotzdem falsch, weil die Beträge in unserem Fall in ihrer gerundeten Form addiert werden müssten.

Ein Weg wäre ja die Funktion "Runden" mit einzubauen. Das habe ich auch erfolgreich an einer Formel ausprobiert. Allerdings ist das gesamte Formular doch recht umfangreich und enthält zu viele unterschiedliche und teilweise sehr komplexe Formeln, die betroffen wären, um das alles mal eben umzuschreiben. Leider ist mir das erst bei der Endkontrolle aufgefallen.

Habe ich vielleicht eine einfache bzw. globale Einstellung übersehen oder bin ich gezwungen mir die Mühe zu machen und muss nochmal in jede Formel einzeln eingreifen? Das wäre ziemlich ärgerlich und zeitraubend. Vielleicht könnt ihr mir weiter helfen.

Vielen Dank
Gruß
Riven

 

[Tomlin]

Ich fürchte, Du kommst um die mathematische Funktion "Runden" nicht herum. Das andere ist, wie du schon festgestellt hast, lediglich die Ansicht der Zahl. Leider kenn' ich Dein Formular nicht, um Dir einen sinnvollen Tipp zum schnelle Einbau der Funktion zu geben.

Eventuell kannst Du noch was an der Herkunft der Zahlen drehen, so dass sozusagen schon die Eingabe oder der Import entsprechend gerundet wird?

 

[Riven]

Danke für die schnelle Antwort.

Die "Runden" Funktion in eine Standardformel (z.B. der Berechnung der Umsatzsteuer) einzubauen ist ja verhältnismäßig leicht. Da geht es eher um die Masse der Eingriffe, die Zeit rauben wird.
Ätzend wird das, wenn ich in komplexere Formeln eingreifen muss, für die ich schon eine gefühlte Ewigkeit zum Erstellen gebraucht habe. "(Summe)Wenn" & Co in ihren asozialsten Kombinationen werden meine Numbers-Hölle, wenn ich da noch mal rein muss.

 

[walfreiheit]

Ohne Fleiß kein Preis.

 

[Riven]

Grins, da hast du Recht. Da steckt auch schon eine Menge Fleiß drin. Schade, daß es dafür keine globale Einstellung zu geben scheint.

 

[Haskelltier]

Und genau deshalb verwendet man möglichst keine Tabellenkalkulationen, wenn man etwas komplexere Dinge berechnen will. Das ganze wird einfach zu schnell zu aufwendig zu warten und auch die Wiederverwertbarkeit ist schlecht. Würde ich mir nicht antun.

Zum Thema: Die Ansicht rundet nicht, das macht korrekterweise nur die gleichnamige Funktion. Wäre auch fatal, wenn je nach Ansicht anders gerechnet würde.

 

[fa66]

Ich habe das nach meiner Suche so verstanden, daß Numbers trotzdem die echten und nicht die gerundeten Zahlen addiert (bis zu 5 Stellen hinter dem Komma?). Also ist es im Prinzip kein falscher Wert, sondern der genaue Wert. Leider ist es unterm Strich dann trotzdem falsch, weil die Beträge in unserem Fall in ihrer gerundeten Form addiert werden müssten.

Ist die von dir als gefordert benannte Additionsweise kaufmännisch (bzw. finanzverwaltungstechnisch) überhaupt richtig?
M.W. soll?/darf? erst der Endbetrag gerundet werden.

 

[Riven]

Vielen Dank für eure Rückmeldung.

Und genau deshalb verwendet man möglichst keine Tabellenkalkulationen, wenn man etwas komplexere Dinge berechnen will. Das ganze wird einfach zu schnell zu aufwendig zu warten und auch die Wiederverwertbarkeit ist schlecht. Würde ich mir nicht antun.

Hätte ich ohne eine Vorlage auch nicht gemacht. Grundsätzlich ist die Berechnung nicht so komplex. Vielmehr sind es die Vorraussetzungen und die weiterführenden Prozesse, die es komplex machen. Das habe ich aber alles hingekriegt. Nur wusste ich bis zur Endkontrolle nicht, daß nicht gerundet wird, obwohl es danach aussieht. Die Wiederverwertbarkeit dürfte kein Problem sein, weil sich außer dem Datum bzw. dem Jahr nichts ändert. Was wäre denn ein alternativer Vorschlag für die Zukunft?

Zum Thema: Die Ansicht rundet nicht, das macht korrekterweise nur die gleichnamige Funktion. Wäre auch fatal, wenn je nach Ansicht anders gerechnet würde.

Ich meinte Zellenformat/Währung/Dezimalen/2. Dann wird in der Ansicht gerundet, aber nicht real. Außer ich verstehe dich jetzt falsch.

Ist die von dir als geforderte benannte Additionsweise kaufmännisch (bzw. finanzverwaltungstechnisch) überhaupt richtig?
M.W. soll?/darf? erst der Endbetrag gerundet werden.

Das kommt sicherlich drauf an. In unserem Fall wäre jeder einzelne Posten zu runden. Es geht im Prinzip immer um das heraus rechnen der USt. und der daraus folgenden Additionen und Subtraktionen.

Soll ich das mal mit einem einfachen Beispiel und ein paar Screenshots verdeutlichen?
Ich bin morgen eh am Gemeinschaftsrechner.

 

[Haskelltier]

Nur wusste ich bis zur Endkontrolle nicht, daß nicht gerundet wird, obwohl es danach aussieht.

Das ist das erste was man sich angewöhnen sollte. Die eigentlichen Werte und die dargestellten Zahlen sind in der Regel nicht gleich, insbesondere ändert die Darstellung nichts am Inhalt. Will man runden, muss man das explizit durch Anwendung entsprechender Funktionen tun.

Was wäre denn ein alternativer Vorschlag für die Zukunft?

Für Berechnungen würde ich R oder Octave einsetzen. Daten kann man importieren, per Skript auswerten und zur Weiterverwendung dann wieder in ein geeignetes Format expotieren. Beides ist wesentlich mächtiger und die Skripte sind wesentlich besser zu lesen und zu erweitern.

Ich meinte Zellenformat/Währung/Dezimalen/2. Dann wird in der Ansicht gerundet, aber nicht real. Außer ich verstehe dich jetzt falsch.

Das meinte ich mit „Ansicht“, wobei Darstellung der bessere Begriff ist. Wie Ergebnisse dargestellt werden hat keinen Einfluss auf den Inhalt.

 

[Riven]

Das ist das erste was man sich angewöhnen sollte. Die eigentlichen Werte und die dargestellten Zahlen sind in der Regel nicht gleich, insbesondere ändert die Darstellung nichts am Inhalt. Will man runden, muss man das explizit durch Anwendung entsprechender Funktionen tun.

Das wusste ich ja leider nicht. Ich bin froh, daß es mir überhaupt aufgefallen ist. Jetzt weiß ich es besser Und wie man in der Funktion rundet, hatte ich ja bereits rausgefunden.

Für Berechnungen würde ich R oder Octave einsetzen. Daten kann man importieren, per Skript auswerten und zur Weiterverwendung dann wieder in ein geeignetes Format expotieren. Beides ist wesentlich mächtiger und die Skripte sind wesentlich besser zu lesen und zu erweitern.

Schau ich mir mal an. Vielleicht ist es ja was für die Zukunft. Bis auf das Numbers da nicht ohne weiteres rundet, sind wir mit der (fast) fertigen Version echt zufrieden und werden damit gut zurecht kommen.

Das meinte ich mit „Ansicht“, wobei Darstellung der bessere Begriff ist. Wie Ergebnisse dargestellt werden hat keinen Einfluss auf den Inhalt.

Echt schade, daß man das nicht global einstellen kann. Naja, dann werde ich mir wohl ein paar Stunden mit "Runden" um die Ohren hauen. Bei der Basisberechnungen wird das "nur" Arbeitsaufwand sein. Zum Glück wird da ein wenig über Copy/Paste zu lösen sein. Bei den Folgerechnungen und automatisch auszufüllenden Feldern mit dem ganzen "Wenn" und "SummeWenn" Zeugs wird das richtiger Denksport.

Danke für die Ausführung und Tipps

 

[Haskelltier]

Echt schade, daß man das nicht global einstellen kann.

Das ist schon okay so. Stell dir mal vor je nach eingestelltem Zellenformat würden in Numbers die Zellen automatisch gerundet werden. Dann hätte ja die Art der Darstellung Einfluss auf die Berechnungen und führt bei verschiedenen Formaten zu unter Umständen komplett anderen Ergebnissen. Mal abgesehen davon, dass man dann für die volle Genauigkeit immer alle Nachkommastellen anzeigen lassen müsste, was meist nicht sehr übersichtlich ist.

 

[Riven]

Mmm... ...das stimmt natürlich. Aber vielleicht reden wir da auch aneinander vorbei. Ich möchte ja nicht alles korrumpieren.
Ich meinte, daß man statt "Runden" in eine Formel einbauen zu müssen, einfach die Option haben sollte, das einfach anzuwählen. Ob jetzt ganz allgemein oder vielleicht besser sogar gezielt. Beispielsweise eine Checkbox beim Zellenformat/Währung unter den Dezimalen für eben genau die Stellen hinterm Komma, die ich haben möchte. Das wäre für mich deutlich angenehmer, als die gewünschten Formeln auch noch mit der "Runden" Funktion auszustatten, damit das was ich sehe auch das ist was ich bekomme.

Naja, ich kann damit leben. Der Weg ist das Ziel
Ich werd versuchen es über die Woche fertig zu bekommen und gebe dann nochmal Rückmeldung.

Bis dahin vielen Dank!

 

[Riven]

Ich will ja nicht zu optimistisch klingen, aber ich glaube ich bin fertig geworden.

Es war doch unkomplizierter als gedacht. Ich musste nur in 4 Hauptformeln runden und das dann jeweils auf alle 12 Monate übertragen. Der Rest ging dann mit Copy/Paste. Die Folgerechnungen mit den ganzen "Wenn" und "SummeWenn" Formeln waren dann zwar etwas schwieriger anzupassen, aber ich habe es relativ schnell hingekriegt und konnte auch da recht viel mit Copy/Paste erledigen. Ein paar Sachen musste ich komplett neu verknüpfen, aber der befürchteten Formel-Hölle bin ich scheinbar entronnen. Hat jetzt vielleicht 2-3 Stunden mit Pausen gedauert. Soweit erstmal alles im grünen Bereich. Fehlt jetzt noch die letzte Endkontrolle, um etwaige Fehler auszuschließen, die sich vielleicht doch noch eingeschlichen haben. Das machen wir dann aber die Tage zu zweit.

 

[Riven]

So, wir haben eben die Endkontrolle durchgeackert. Bis auf eine Formatierung war alles richtig. Alles wird jetzt dort korrekt gerundet, wo das notwendig ist. Die Summen stimmen, die Verknüpfungen stimmen - alles genau so, wie es sein soll.

Abschließend möchte ich noch mal kurz auf die zurecht erwähnten Zweifel von "fa66" eingehen, denn die Frage habe ich mir ja auch gestellt - also ab wann darf bzw. muss gerundet werden?
Ich wiederhole mich, wenn ich sage, daß das auf die Situation bzw. die Abrechnung ankommt. Ich glaube am besten lässt sich das mit einem Einkauf vergleichen.

Nehmen wir z.B. einen Artikel a 100€, der mit 19% MwSt. besteuert wird.
Es werden 20 dieser Artikel verkauft. Ein Kunde kauft 10 und 10 Kunden kaufen einen.
Der eine Kunde bezahlt 1000€. Es fallen 159,66 MwSt an.
Die 10 Kunden bezahlen jeder 100€. Es fallen jeweils 15,97 und insgesamt 159,70 MwSt an.

Beides ist richtig. Fa66 hat also recht. Am Ende eines (nennen wir es) Vorgangs wird gerundet.
Nun macht Numbers aus den 10x 15,97 am Ende dann trotzdem 159,66. Das wäre aber falsch, denn jeder Kunde wurde endgültig mit 15,97 und nicht mit 15,9663865546218 besteuert. Der Vorgang wurde mit 15,97 abgeschlossen. Der Händler muss das abführen was er eingenommen hat, also 10x die 15,97 und 1x die 159,66.
Ich hoffe die Erklärung ist schlüssig.

Vielen Dank nochmal für die schnelle Hilfe
Gruß
Riven