Berechnete Spalten summieren

Andi Fandrich Als Antwort am 7 Aug. 2012 08:57

Dazu müßte man die Summe und den Prozentsatz per XSLT selbst ausrechnen und darstellen. D.h. die Ansicht in SharePoint Designer öffnen und anpassen.

Thilo1992 Als Antwort am 7 Aug. 2012 09:33

Ok, ich hab mal nach einer Lösung gesucht, da ich mich mit XSLT nicht auskenne.

http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/acc9a1e0-599f-4464-a032-2766ce16d062

Hier die erste Antwort. Ich nehme an, den ersten Teil, das template kann man irgendwo einfügen und es kann so bleiben und den td Teil muss man dann an der richtigen Stelle einfügen. Wo muss der td Teil dann hin und wie übergebe ich die richtige Reihe?

Andi Fandrich Als Antwort am 7 Aug. 2012 09:53

Man muß das gesamte XSLT schon etwas mehr anfassen, z.B. eine eigene Tabellenzeile für die Summe einfügen. Tut mir sehr leid, aber ich habe im Moment keine Zeit, eine komplette Anleitung dafür zu schreiben. Vielleicht jemand anderes?

Thilo1992 Als Antwort am 16 Aug. 2012 10:58

Ich habe noch eine Möglichkeit gefunden, die funktioniert aber noch nicht ganz.

Ich habe die Webpartseite im Designer geöffnet, das Webpart makiert und dann bei Entwurf die Ergebniszeile hinzugefügt. Dann habe ich folgende Formel eingefügt: sum(/dsQueryResponse/Rows/Row/@Spalte), die laut dieser Seite funktionieren sollte: http://blog.mindbusiness.de/blog/2008/03/06/summen-berechnen-in-datenansichten/

Aber dabei kommt imer 0 als Ergebnis, bei allen Spalten. Muss ich irgendetwas abändern oder funktioniert es so überhaupt nicht?

Andi Fandrich Als Antwort am 16 Aug. 2012 11:14

Ich glaueb die berechneten Spalten geben immer den Datentyp mit aus, den man also zuerst abschneiden müßte. Lasse Dir doch einfach mal die eigentlichen Werte mit ...Row/@Spalte ausgeben.

Thilo1992 Als Antwort am 16 Aug. 2012 11:31

Also einfach nur /dsQueryResponse/Rows/Row/@Spalte eingeben?

Da steht dann der Wert der ersten Spalte im Designer und im Browser nichts, wenn ich es mit sum() mache steht im Designer das richtige aber im Browser 0.

Andi Fandrich Als Antwort am 16 Aug. 2012 12:42

[quote user="Thilo Förster"]steht im Designer das richtige aber im Browser 0[/quote]

Dann greifen da vermutlich rigendwelche Filtereinstellungen. Werden denn überhaupt irgendwelche Zeilen angezeigt?

Ansonsten kann man nur sagen, daß sich die Darstellung im Designer und im Browser sehr oft unterscheiden. Bis so eine Ansicht sich wie gewünscht verhält, ist das oft ein iterativer Prozeß des langsamen Herantastens. D.h. man mach eine kleine Änderung und läßt sich z.B. interne Feldwerte ausgeben, speichert das und schaut es sich im Browser an. Dann die nächste Änderung, speichern, Browser usw.

Thilo1992 Als Antwort am 16 Aug. 2012 13:15

Ich habs hinbekommen.

sum($Rows/@Spalte) so muss es aussehen.

Und beim Prozentsatz dann so rechen: sum($Rows/@Spalte1) div sum($Rows/@Spalte2)

Thilo1992 Als Antwort am 17 Aug. 2012 09:30

Ich habs doch noch nicht ganz, in der Testliste waren alle zahlen unter 1.000, ab 1.000 gibt es mal wieder das Problem mit dem '.' in der Zahl.

Innerhalb von sum() kann man aber kein translate() machen, da man ja einen array übergibt mit allen Reihen. Das müsste man dann in einer Schleife lösen, kann man in einer Formel eine Schleife machen? Wenn nicht wird das Summieren wohl unmöglich sein.

Thomas Östreich Als Antwort am 17 Aug. 2012 09:55

Füg mal am Spaltennamen einen Punkt an " @MyNumberColumn." (Rohwerte). Es gibt im Result Spalten wie Lookup, Url, Date und Number die in verschiedenen Formaten vorhanden sind.

Thilo1992 Als Antwort am 17 Aug. 2012 10:11

Ok, jetzt steht da kein NaN mehr sondern 0 also das Summieren klappt immer noch nicht.

Thomas Östreich Als Antwort am 17 Aug. 2012 10:15

mal im ganzen: sum(number($Rows/@Spalte1.)) div sum(number($Rows/@Splate2.))

Setzt natürlich voraus das es auch tasächlich Felder vom Type Nummer sind.

Thilo1992 Als Antwort am 17 Aug. 2012 10:25

Ja, es sind Zahlenfelder. Das number() hatte ich nicht dazu gemacht, da da schonmal ne Fehlermeldung kam. Ich habe es jetzt dazu gemacht und jetzt kommt wieder die Fehlermeldung: Prozessorstylesheet konnte nicht festgelegt werden: 0x80004005 : Argument 1 muss einen Knotensatz zurückgeben. --> sum(number($Rows/@Spalte.)) <--

Thomas Östreich Als Antwort am 17 Aug. 2012 13:01

Kann es sein das du "null" Werte hast?

sum(number($Rows[not(@Spalte. = '')]/@Spalte.))

Thilo1992 Als Antwort am 17 Aug. 2012 13:13

Nein, es steht überall eine Zahl drin, ich habs mal so gemacht und dann kommt die gleiche Fehlermeldung.

Thilo1992 Als Antwort am 22 Aug. 2012 07:49

Also Schleifen kann man nicht machen?

Andi Fandrich Als Antwort am 22 Aug. 2012 09:09

Schleifen gehen schon (xsl:for-each), aber man kann z.B. nicht in einer Schleife eine Variable hochzählen.

Thilo1992 Als Antwort am 22 Aug. 2012 15:00

Hm blöd, gibts sonst noch eine Möglichkeit die Summe hinzubekommen?

Thilo1992 Als Antwort am 23 Aug. 2012 09:39

Ich hab grade bemerkt, dass es noch eine Spalte gibt mit dem selben Spaltennamen nur mit T_ vornedran und darin ist der Wert ohne '.' und ','.

Dadurch habe ich dasSummieren hinbekommen. So eine Zusatzspalte gibt es aber nur für die Spalte, deswegen besteht das Problem noch bei den anderen Spalten. Außerdem habe ich bemerkt, dass das Summieren nicht funktioniert, wenn ein Minuswert dabei ist (also ein Wert unter 0).

Wie kann ich Minuswerte summieren?

Thilo1992 Als Antwort am 23 Aug. 2012 09:54

Ich hab mal nachgeschaut, was es mit T_Spalte auf sich hat. Die hat jemand erstellt und das ist eine berechnete Spalte, die die Spalte*100 als Text enthält. Ich muss mal nachfragen, wofür die ist.

Aber dadurch bin ich jetzt immerhin auf die Idee gekommen, das man für die Spalten einfach noch eine Spalte, die die Zahl so als Text enthält erstellt.

Dann geht das Summieren.

Thilo1992 Als Antwort am 23 Aug. 2012 10:37

Das Problem mit den Minuswerten hat sich durch das umwandeln in Text auch erledigt. Stehe jetzt nur noch vor einem Problem, beim berechnen vom Prozentsatz kommt eine zahl mit unendlich vielen Nachkommastellen raus und dann steht da Infinity.

Ich habe versucht die Nachkommastellen mit format-number() zu begrenzen, aber das geht nicht. Das muss man wohl schon direkt bei der Division irgendwie machen. Weiß jemand wie das geht?

Andi Fandrich Als Antwort am 23 Aug. 2012 10:51

format-number ist eigentlich schon richtig. Was geht denn dabei nicht?

Thilo1992 Als Antwort am 23 Aug. 2012 11:26

Bei format-number() kommt dann trotzdem noch Infinity als Ergebnis und bei round() auch.

format-number mache ich so: format-number(sum($Rows/@T_Spalte1) div sum($Rows/@T_Spalte2),'##.#%')

So stehts in der Beschreibung. Ich denke, dass es schon Probleme bei der Diviosion hat wegen den Nachkommastellen und man muss das da wohl schon auf eine bestimmte Anzahl an Nachkommastellen begrenzen.

Andi Fandrich Als Antwort am 23 Aug. 2012 11:33

Kann es sein, daß sum($Rows/@T_Spalte2) ziemlich klein ist? Dann kommt nämlich das Ergebnis der Berechnung Infinity ziemlich nahe...

Thilo1992 Als Antwort am 23 Aug. 2012 11:47

Spalte1= -1156 und Spalte2= 4488

Andi Fandrich Als Antwort am 23 Aug. 2012 12:30

Bist Du auch sicher, daß das so in den Feldern steht und nicht etwa als 4.488? Also nicht mit dem in Deutschland üblichen Punkt als Tausendertrennzeichen? Das wird nämlich von XSL als Dezimaltrenner interpretiert.

Thilo1992 Als Antwort am 23 Aug. 2012 12:44

Ja, es ist kein Punkt und kein Komma dabei.

Thilo1992 Als Antwort am 24 Aug. 2012 10:29

Ich habe gerade mal versucht mit substring() die ersten paar Stellen rauszuholen, aber dann holt es di ersten paar Stellen von Infinity, also weiß ich jetzt ganz sicher, dass direkt nach der Division schon Infinity herauskommt also kann man danach nicht mehr ändern, man muss das direkt bei der Division schon begrenzen, geht das nicht?

Thilo1992 Als Antwort am 28 Aug. 2012 13:29

Ich habs hinbekommen, hatte einen Spaltennamen falsch geschrieben und dann wurde durch 0 geteilt.

Es war aber ziemlich verwirrend dann mit dem Infinity, da die Zahl nämlich unendlich Nachkommastellen hat, hat das auch noch Sinn gemacht. Hätte das keinen Sinn gemacht ode hätte da was anderes gestanden hätte ich den Fehler wohl früher bemerkt. Seltsam war ja auch, dass es das dann überhaupt so angenommen hat, sonst funktioniert die Formel nämlich überhaupt nicht wenn ein Spaltenname falsch ist.

Immerhin funktioniert jetzt alles, danke für eure Hilfe.

Thilo1992 Als Antwort am 29 Aug. 2012 11:04

Ein Problem gibt es jetzt doch noch, da ich nach der Rechnung wieder das Format ändere mit , statt . und dem Tausender-Trennzeichen wird es als Text erkannt und mach nach einem Bindestrich einen Zeilenumbruch wenn die Zahl zu lang ist.

Kann man irgendwie dafür sorgen, dass es keinen Zeilenumbruch nach einem Bindestrich macht?

Andi Fandrich Als Antwort am 29 Aug. 2012 12:53

Die Formatierung kannst Du mit format-number() und decimal-format in den Griff bekommen. Den Zeilenumbruch kann man per CSS unterbinden (white-space:nowrap)

Thilo1992 Als Antwort am 29 Aug. 2012 15:22

Wie das mit der Formatierung geht weiß ich, ich meinte nur das es wahrscheinlich bei einer Zahl keinen Zeilenumbruch bei einem Bindestrich machen würde, aber dadurch das ich es wieder anders formatiere wird es wahrscheinlich nicht mehr als Zahl sondern als Text erkannt und bei Text gibt es dann den Zeilenumbruch.

Der CSS Befehl hat geholfen, Danke.

Andi Fandrich Als Antwort am 29 Aug. 2012 15:45

Das hat mit Zahl oder Text überhaupt nichts zu tun. Es ist ein reines HTML-Formatierungs-Problem und damit per CSS zu lösen.

Horst Eisele Als Antwort am 17 Juni 2013 18:17

Hallo,

ich habe das über Zusatzfelder und einem Workflow gelöst.
Also Summe1 ist ein berechnetes Feld.
Gesamtsumme ist ein Zahlenfeld.
Per Workflow einfach Summe1 in Gesamtsumme übertragen, dann kann man über Feld "Gesamtsumme" kummulieren in der Liste. Mit den % müsste das auch gehen.

Viel Erfolg.
Horst Eisele