Live-Forum - Die aktuellen Beiträge
Anzeige
Archiv - Navigation
1484to1488
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Aggregat mit Summe wenn Bedingung erfüllt

Aggregat mit Summe wenn Bedingung erfüllt
13.04.2016 19:55:49
Alesandro
Liebe Forumsgemeinde,
wie ermittle ich mit AGGREGAT die Summe wenn eine Bedingung erfüllt sein muss?
Im beigefügten file gebe ich in Zelle B1 (Tabellenblatt Projektdetails) die Projektnr ein und ermittle mir mittels AGGREGAT und KKLEINSTE bzw KGRÖSSTE (Tabelle ROH über die Spalten Von und Bis) den START u. das ZIEL.
Das funktioniert auch prima.
Wie man die Gesamtstunden zum Projekt mittels SUMMEWENNS ermittelt weiß ich.
Ich schaffe es leider nicht wie ich die Gesamtstunden des Projekts via AGGREGAT ermittle.
Vielleicht kann mir einer von Euch Profis da weiterhelfen.
https://www.herber.de/bbs/user/104947.xlsx
Vielen Dank im Voraus.
Alesandro

12
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
Tja, das ist bei dir ein Grenzfall, bei dem es ...
14.04.2016 02:39:56
Luc:-?
…auch eine reguläre AGGREGAT-Lösung gibt, Alesandro,
die aber auch die längste Fml hat. Die kürzeste Fml ist deine SUMMEWENNS-Fml, wobei hier auch schon das klassische SUMMEWENN (s.u.) gereicht hätte (1 Zeichen kürzer).
Dazwischen bewegen sich längenmäßig irreguläre AGGREGAT-Fmln wie du sie in den anderen Zellen angewendet hast, deren ErgebnisVektor dann aber noch extra summiert wdn muss, und Lösungen mit AGGREGAT und einer UDF, die ggf einen unzusammenhängenden Bereich erzeugt (bei dir ist er zusammenhängend), der von AGGREGAT als 3.Argument toleriert wird, sowie einer UDF, die gleich die ganze AGGREGAT-Fkt simuliert (in 2 Varianten). Die meisten dieser Fmln sind 1zellige (singulare) {MatrixFmln}:
 65:  =SUMMEWENN(ROH[Projektnr];Projektdetails!$B$1;ROH[Wochenstunden])
 66:  =SUMMEWENNS(ROH[Wochenstunden];ROH[Projektnr];Projektdetails!$B$1)
 73:{=AggregateXk(9;6;(ROH[Projektnr]=Projektdetails!$B$1)*ROH[Wochenstunden])}
 74:  =AggregateXk(-9;6;(ROH[Projektnr]=Projektdetails!$B$1)*ROH[Wochenstunden])
 85:{=AGGREGAT(9;6;ChooseIn(ROH[Wochenstunden];ROH[Projektnr]=Projektdetails!$B$1;WAHR;0))}
102:{=SUMME(AGGREGAT(15;6;ROH[Wochenstunden]*(ROH[Projektnr]=Projektdetails!$B$1);ZEILE(ROH[Projektnr])-1))}
110:  =SUMMENPRODUKT(AGGREGAT(15;6;ROH[Wochenstunden]*(ROH[Projektnr]=Projektdetails!$B$1);ZEILE(ROH[Projektnr])-1))
180:{=AGGREGAT(9;6;INDEX(ROH[Wochenstunden];VERGLEICH(Projektdetails!$B$1;ROH[Projektnr];0)):
        INDEX(ROH[Wochenstunden];MAX((ROH[Projektnr]=Projektdetails!$B$1)*ZEILE(ROH[Projektnr]))-1))}
Die letzte und längste Fml erzeugt/benutzt aber stets einen zusammenhängenden Bereich (die Werte müssen also sortiert sein - bei den anderen Fmln nicht!), denn es gibt mW keine Xl-StandardFkt, die unzusammenhängende Bereiche erzeugen, nur welche, die sie verarbeiten können. AggregateXk ist im Archiv zu finden, ChooseIn nicht, weil bisher unveröffentlicht (Neufassung in Arbeit!).
Feedback nicht unerwünscht! Gruß, Luc :-?
Besser informiert mit …

Anzeige
AW: Tja, das ist bei dir ein Grenzfall, bei dem es ...
14.04.2016 09:34:18
Alesandro
Servus Luc,
deine Antwort ist mehr als umfassend.
Verwende jetzt die Funktion= AggregateXk und die Formel 73 und das funktioniert prima.
Vielen Dank,
lg Alesandro

Na, das ist doch mal 'ne gute Nachricht! ;-) orT
14.04.2016 13:20:48
Luc:-?
Viel Erfolg! Luc :-?

Nachbemerkung (auch f.neopa u.a. Interessenten):
14.04.2016 14:22:33
Luc:-?
Die Fml mit der LängenNr 74 erfordert die AggregateXk-Version 1.3, die ebenfalls im Archiv enthalten ist. Die UDF kann ersatzweise für beide AGGREGAT-Varianten verwendet wdn, wobei sie aber primär die Form der Variante mit Arg4=k hat, wobei k zwar entfallen, aber nicht durch weitere Argg3 ersetzt wdn kann. Die UDF kann also nicht mehrere Datenfelder bzw ZellBereiche verarbeiten und unzusammenhängende Bereiche sind ebenfalls nicht möglich! Da AGGREGAT Letzteres aber kann, was ich im Zusammenhang mit dieser Aufgabe (Fml mit LängenNr 85, auch getestet mit entsprd unterbrochenem ProjektNrn-Bereich → ChooseIn erzeugt dann einen unzusammenhängenden Bereich!) feststellen konnte, muss ich mir überlegen, ob ich noch eine weitere Variante 1.4 erstelle, die das ebenfalls bewältigt.
Allerdings war die UDF ursprünglich nur ein Bsp in einer Diskussion dafür, was für MS machbar gewesen wäre. Ich hatte auch eine bisher unveröffentlichte UDF geschrieben, die nur wenigen bekannt ist, aber punktuell noch mehr kann als AGGREGAT bzw AggregateXk. Da ist so etwas ebenfalls enthalten, so dass ich mir das mit Version1.4 noch sehr überlegen muss, zumal ich zZ an Anderem arbeite… ;-)
Gruß, Luc :-?

Anzeige
Nachbemerkung2: AggregateXk fktt hier ...
14.04.2016 14:36:58
Luc:-?
…auch bei unsortierten bzw unterbrochenen ProjektNr-Bereichen, weil durch den Vgl ein zusammenhängendes Datenfeld über den ganzen Bereich aufgebaut wird, das im Falle der Nichtübereinstimmung 0en enthält. Bei DirektAngabe eines unzusammenhängenden Bereichs wie (A2:A8;A11:A25) als Arg3 würde es nicht klappen.
Luc :-?

AW: kann das so nur bedingt nachvollziehen ...
14.04.2016 18:01:10
...
Hallo Alesandro,
... warum willst Du Deine Summierung unbedingt mit AGGREGAT() vornehmen. SUMMEWENN() liefert doch das korrekte Ergebnis, ist einfach konstruiert und schnell in der Auswertung.
Auf die diesbzgl. Grenzen der AGGREGAT()-Funktion hat Dich Luc ja schon hingewiesen.
Unabhängig von den Möglichkeiten die Dir Luc mit seinen spez. UDFs aufgezeigt hat, muss ich aber noch auf folgendes verweisen. Für die Auswertung Deiner Rohdaten hätte ich überhaupt keine Formel eingesetzt, denn Deine "Rohdaten" "schreien" ;-) regelrecht nach einer PIVOTauswertung.
Gruß Werner
.. , - ...

Anzeige
Na also, endlich hast du auch hierher ...
15.04.2016 00:45:47
Luc:-?
…gefunden, Werner,
auch wenn du nun zum konkreten Daten-/FmlFall und nicht da geantwortet hast, wo ich dich „hinlocken“ wollte… ;-)
Ich bin bei meiner AW ursprünglich davon ausgegangen, dass Alesandro, genau wie du, hiermit nur die Möglichkeiten von AGGREGAT ausloten wollte. Deshalb habe ich auch diesen FmlVgl angefertigt, denn im konkreten Fall ist hier ja sogar eine reguläre AGGREGAT-Lösung möglich, wenn auch unnötig umständlich.
Immerhin konnte ich so erkennen und nachweisen, dass AGGREGAT unzusammenhänge ZellBereiche verarbeiten kann, was nicht unbedingt zu erwarten war (die ~WENNs-Fktt können das nicht!). Das wurde klar, als ich eine ProjektNr innerhalb des Auswahl­bereiches geändert habe. In diesem Fall gibt die UDF ChooseIn (ebenso wie ihr in Erarbeitung befindlicher Nachfolger ChooseIf) nämlich einen aus 2 TeilBereichen zusammen­gesetzten unzusammenhängenden ZellBereich zurück, erkennbar auch daran, dass die UDF, solo angewendet, #WERT! liefert, weil Xl dieses Ergebnis nicht auf einen ZellBereich abbilden kann. Als Argument einer anderen Fkt verwendet, wird aber klar, dass real doch ein Ergebnis geliefert wird, das viele alte XlFktt weiter­verarbeiten können.
Im Zusammenhang mit meinen obigen AWen hatte ich erwähnt, dass Xl zwar viele Fktt hat, die unzusammen­hängende Zell­Bereiche verarbeiten können, aber mW keine, die sie erzeugen kann. Das ist zwar iW richtig, doch das liegt nur daran, dass alle XlFktt so pgmmiert wurden, dass sie stets auch ein abbild­bares Ergebnis liefern. Solche „Hilfs­Fktt“ wie meine UDF ChooseIn kommen also standard­mäßig nicht vor! INDEX, das sowohl Daten­felder als auch beide Arten von Zell­Bereichen verarbeiten kann, hätte auch dazu das Potenzial, wenn das nicht (bewusst) eingeschränkt worden wäre. Im folgenden Bsp zeige ich das:
 ABCDEFGHI
21alphabetagammadeltaepsilonvauzetaeta
32betaC2:I2:=INDEX($B$2:$B$12;SPALTE(B2);1)
43gamma 118E4⇒18F4⇒18
54deltaWAHR3E4:F4: {=SUMME(INDEX($A$2:$A$10;{1;3;6;8};1)*1^ZEILE(A1:A4))}
65epsilonFALSCH618E6⇒18F6⇒18
76vauFALSCH8E6:F6: {=AggregateXk(9;6;INDEX($A$2:$A$10;{1;3;6;8};1)*1^ZEILE(A1:A4))}
87zetaWAHR18D4:D7: {=INDEX($A$2:$A$12;{1;3;6;8};1)}D8:=SUMME(D4:D7)
98etaC5:C8: {=IsColor(INDEX($B$2:$B$12;{1;3;6;8};1);TxEval(T(JETZT())&"CellColor("&RAddress(C4)&")"))}

Hier kann man einerseits erkennen, dass INDEX sowohl Datenfelder als auch Zell­Bereiche liefern kann, aber nur in einer Matrix­Fml, wenn auch genügend Zellen ausgewählt wurden. Im Bsp ist das der Ergebnis­Bereich C5:C8, der die Farben der zurück­gegebenen 4 Zellen mit Rot vergleicht. Das wäre nicht möglich, wenn nur Zell­Werte geliefert würden.
In D4:D7 geschieht derglei­chen mit Spalte A. Hier kommt es aber auf die Zell­Werte an, die summiert wdn sollen. Wenn man das in einer Fml tun wollte (wie in E4:F4 bzw E6:F6), müsste man diesen unzusammen­hängenden Bereich noch in eine auswert­bare Form bringen, wodurch er zum Daten­feld wird. Trotzdem wird eine 1zellige (singulare) Matrix­Fml immer noch kein richtiges Ergebnis liefern. Dafür benötigt sie einen weiteren Anstoß in Form einer 2., mitaus­gewählten Zelle, so dass eine quasi-1-zellige (duale) MatrixFml entsteht. Diese liefert dann auch das richtige Ergebnis, aber nunmal doppelt, weshalb ich das hier in einer speziellen Verbund­Zelle unter­gebracht habe, die die Xl-Warnung, dass MatrixFmln in Verbund­Zellen nicht möglich sind, ad absurdum führt (bei singularen MxFmln erscheint die Warnung nicht!).
Da die regulären Anwendungen von AGGREGAT (Arg1=1…13) mit Daten­feldern nichts anfangen können und die irregulären das Ganze nur unnötig kompli­zieren würden, habe ich in E6:F6 die UDF AggregateXk eingesetzt, um diesen INDEX-Effekt an einem 2.Bsp zu demonstrieren.
(Anm: Die in C2 angezeigte Fml ist nur ein Stino-KontrastPgm für eine einfache Transponierungs­Aufgabe.)
Gruß, Luc :-?

Anzeige
AW: was heißt endlich? ...
15.04.2016 08:43:04
...
Hallo Luc,
... es waren ja noch nicht mal 24 h vergangen.
Deine neuen Ausführungen schau ich mir am WE mal etwas näher an.
Gruß Werner
.. , - ...

Ich hatte dich hier wohl schon vorher erwartet,...
15.04.2016 13:23:00
Luc:-?
…Werner,
nach meinem 1.BT… ;-)
Ganz neu sind meine Ausführungen zu INDEX nicht, ich hatte das schon mal festgestellt, nur das zu AGGREGAT und unzusam­men­hängenden Bereichen.
SchöWE, Luc :-?

Dazu mal ein 7 Jahre altes NoNet-Problem ...
16.04.2016 14:56:18
Luc:-?
…aus dem Archiv gekramt, Werner;
darin versucht er, mit folgender MxFml eine (richtige) indizierte Summe zu erhalten:
{=SUMME(INDEX({10;20;40};;ZEILE(1:2)))}
Das ergibt natürlich 70, nicht 30 wie beabsichtigt. Mit {=SUMME(INDEX({10;20;40};ZEILE(1:2)))} wdn dann nur die einzelnen Werte durchlaufen, nichts zusammengefasst. Die für ZellBereiche mögliche NotationsForm …
=SUMME(INDEX(A1:A3;1):INDEX(A1:A3;2))
…ist auf Datenfelder (MxKonstante {10;20;40}) natürlich nicht anwendbar.
Damals hatte ich die quasi-1- bzw doppelzelligen (quasi-1- bzw doppelwertigen, kurz dualen) MxFmln noch nicht entdeckt, sonst hätte ich ihm dort auch folgd Lösung anbieten können (er hatte ja ohnehin, wie leider des öfteren, nicht mehr reagiert):
{=SUMME(INDEX({10;20;40};ZEILE(1:2))*1^ZEILE(1:2))}
Natürlich als duale MxFml über 2 Zellen, was dann auch richtig, aber 2×, 30 ergäbe.
NoNet hat mW in Folgejahren nochmals derartige Probleme thematisiert, aber das kannst du ja mal selber recherchieren.
Gruß, Luc :-?

Anzeige
AW: kann das so nur bedingt nachvollziehen ...
15.04.2016 10:18:53
Alesandro
Hallo Werner,
mir ging es nur um die prinzipielle Möglichkeit das mit AGGREGAT zu lösen ;-)
lg Alesandro

AW: dann ist es natürlich nachvollziehbar! owT
15.04.2016 11:04:54
...
Gruß Werner
.. , - ...

228 Forumthreads zu ähnlichen Themen

Anzeige
Anzeige
Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige