Herbers Excel-Forum - das Archiv

sverweis verschachtelt

Bild

Betrifft: sverweis verschachtelt
von: Andreas Wünsche

Geschrieben am: 22.01.2016 13:07:05

Guten Tag ich habe folgendes Problem:
in den ersten Spalten des Blattes stehen Bezeichnungen, dahinter zugehörige Daten.
A B C
UV 01. 01.
W 01. 01. 01.
W 01. 01. 02.
.
.
UV 01. 02.
W 01. 02. 01.
usw.
Ich möchte nun in einem anderen Tabellenblatt Werte weiter verarbeiten, welche immer hinter UV... stehen, die anderen sollen ignoriert werden. Im neuen Blatt sollen die Zeilen auch direkt untereinander stehen, ohne Leerzeilen.
Danke.

Bild

Betrifft: AW: sverweis verschachtelt
von: SF
Geschrieben am: 22.01.2016 13:11:07
Hola,
z.B.
http://www.excelformeln.de/formeln.html?welcher=28
Gruß,
steve1da

Bild

Betrifft: AW: sverweis verschachtelt
von: Jürgen Huber

Geschrieben am: 22.01.2016 14:10:39
ich löse solche Probleme immer mit Pivottabellen.(weniger kompliziert) Hier kann zu nach UV selektieren, die Werte stehen sauber untereinander und du kannst sie weiter bearbeiten. Du kannst auch selbst kreierte Formeln in einer Pivottabelle verwenden.
Gruß
Jürgen Huber

Bild

Betrifft: AW: sverweis verschachtelt
von: Andreas Wünsche
Geschrieben am: 22.01.2016 15:08:04
Herzlichen Dank.
Aber irgendwie trifft es das noch nicht.
UV 01. 01. stehen jeweils in einer Zelle.

Bild

Betrifft: AW: mit INDEX() und AGGREGAT() ...
von: ... neopa C

Geschrieben am: 22.01.2016 20:23:14
Hallo Andreas,
... wenn ich Deine Angaben (nicht ganz eindeutig) richtig interpretiert habe, dann kopiere nachfolgende Formel ziehend weit genug nach rechts und unten:
Tabelle2

 ABCDE
1UVWert_1Wert_2Wert_3 
2 01.01.  
3 01.02.  
4     

Formeln der Tabelle
ZelleFormel
B2=WENN(ZEILE(A1)>ZÄHLENWENN(Tabelle1!$A:$A;$A$1); "";INDEX(Tabelle1!$A:$F;AGGREGAT(15;6;ZEILE($A$1:$A$99)/(Tabelle1!$A$1:$A$99=$A$1); ZEILE(A1)); SPALTE()))&""


Tabelle1

 ABCDE
1KnWert_1Wert_2Wert_3 
2UV01.01.  
3W01.01.01. 
4W01.01.02. 
5.    
6.    
7UV01.02.  
8W01.02.01. 
9     


Excel Tabellen im Web darstellen >> Excel Jeanie HTML 4
Gruß Werner
.. , - ...

Bild

Betrifft: Genau den gleichen Effekt erreicht man auch ...
von: Luc:-?

Geschrieben am: 24.01.2016 02:37:52
…ganz ohne AGGREGAT (auch in älteren Xl-Versionen!), Werner,
mit der ZellFml …
B2[:D4]:=WENN(ZEILE(A1)>ZÄHLENWENN(Tabelle1!$A:$A;$A$1);"";INDEX(Tabelle1!$A:$D;Werte;SPALTE()))&""
…und der benannten Fml …
Werte:=KKLEINSTE(WENNFEHLER(ZEILE(!$A$1:$A$99)/(Tabelle1!$A$1:$A$99=$A$1);"");ZEILE(A1))
…was wohl erneut beweist, dass mit Namen definierte Fmln in vielen Fällen alle Ergebnis­Werte vorhalten, so dass sie mit INDEX einer nach dem anderen abgegriffen wdn können. AGGREGAT hingegen muss den benannten FmlTeil in jeder Zelle neu berechnen.
Man kann natürlich auch noch der ZÄHLENWENN-TeilFml einen Namen geben — dass wäre dann noch rationeller.
Falls ich mich wider Erwarten doch mit der Berechnung benannter Fmln irren sollte, was ich nicht glaube, da sie offensichtlich immer zuerst berechnet wdn, würde meine Aussage auf jeden Fall auf eine mehrzellige MatrixFml zutreffen!
Morrn, Luc :-?
PS: Übrigens hatte ich dir nochmals geantwortet und meine UDF erweitert, aber eigentlich erachte ich die so von ihr erreichte „Matrix­(Fml)Fktionalität“ hier für höchst überflüssig…

Bild

Betrifft: AW: Genau den gleichen Effekt erreicht man auch ...
von: Andreas Wünsche
Geschrieben am: 24.01.2016 13:52:36
Vielen Dank an alle Helfer!
Ich habe es ein mit einer Mischung aus verschiedenen Vorschlägen gelöst.
Andreas

Bild

Betrifft: AW: mE nur das gleiche Ergebnis ...
von: ... neopa C

Geschrieben am: 24.01.2016 18:00:11
Hallo Luc,
... aber vielleicht ist das mE auch etwas zu spitzfindig.
Aber nachtragen muss ich noch, dass man die AGGREGAT()-Formel auch ganz ohne ZÄHLENWENN() schreiben könnte.
In B2: =WENNFEHLER(INDEX(Tabelle1!$A:$F;AGGREGAT(15;6;ZEILE($A$1:$A$99)/(Tabelle1!$A$1:$A$99=$A$1);ZEILE(A1));SPALTE())&"";"")
Man könnte auch diese Formel als Bereichsnamen, z.B.: WERTE definieren und in B2 danach nur noch =WERTE schreiben und diese kopieren.
Dieses ist aber für die AGGREGAT()-Formel nicht wirklich notwendig, weil sie nicht wie die KKLEINSTE()-Formel auf die integrierte Bereichsnamen-Matrixfunktionalität angewiesen ist.
Meine Meinung zu mehrzelligen Matrixformeln hat sich nicht geändert. Sie haben zwar durchaus manchmal Vorteile, aber für die meisten Anwendungen, sind zumindest mir deren Nachteile (unzureichende Flexibilität bei notwendigen Strukturänderungen und die oft nicht bekannte notwendige und richtige Ergebnismatrixausdehnung) schwerwiegende, so dass ich diese bisher fast nie eingesetzt habe.
Gruß Werner
.. , - ...

Bild

Betrifft: AW: mE nur das gleiche Ergebnis ...
von: Daniel

Geschrieben am: 24.01.2016 18:10:12
neopa C schrieb:
" (unzureichende Flexibilität bei notwendigen Strukturänderungen und die oft nicht bekannte notwendige und richtige Ergebnismatrixausdehnung) "
das kann aber auch ein Vorteil sein.
die mehrzelligen Matrixformeln sind quasi "automatisch" vor unbeabsichtigten Überschreiben geschützt.
und wenn man die Matrixausdehung nicht kennt, nutzt man einfach die entsprechende Excel-Menüfunktion um alle Zellen die zu einer Matrix gehören zu selektieren (Inhalte auswählen - aktuelles Array)
Gruß Daniel

Bild

Betrifft: Gemeint war natürlich der Effekt, den die ...
von: Luc:-?

Geschrieben am: 25.01.2016 01:22:44
…benannte Fml hat, Werner,
denn der erfüllt ja schon den HptGrund, warum du AGGREGAT-14/15 einsetzt → 1zellige NormalFmln ganz ohne {}! Allerdings dürfte dabei der „Effekt“ fehlen, dass dieser Teil der AGGREGAT-Fml in jeder Zelle aufs Neue berechnet wdn muss. Meine Auffassung ist, dass benannte Fmln 1malig bei Datei­Öffnung bzw Blatt­Aktivierung berechnet wdn und ansonsten nur bei Änderung an ihren Input-Primär­daten (wie die meisten anderen Fmln ja auch). Mit der zuge­hörigen ZellFml wdn die bereits berechneten Ergebnis­werte nur noch abge­bildet. Sind die genannten Primär­daten adress­fixiert (absolut bzw durch Weg­bewegung der Einzel­ZellFml unbeein­fluss­bar), können diese Ergebnis­Präsentations­ZellFmln auch in unzu­sammen­hängenden Zellen notiert wdn, sind also genauso flexibel wie gleich­artige AGGREGAT-Fmln. Und diese Möglichkeit bietet Xl schon seit vielen Jahren, wenn nicht gar schon immer! Es besteht also gar kein ernst­hafter Grund, AGGREGAT dafür einzu­setzen! Nur, weil das geht, muss man es doch nicht machen! Die Gründe, die dagegen sprechen, kann man doch nicht einfach ignorieren, sei die AGGREGAT-Begeisterung auch noch so groß!
Höchstwahrscheinlich wird dieses AGGREGAT-„Fenster“ nicht einmal ernsthaft für die Fktt lt Nrn 16-19 benötigt, zumal ja bei einem Datenfeld als Arg3 allein das Ausfiltern von Fehler­Werten als besondere neue Option (Arg2) verbleibt. Dafür gibt's jetzt aber schon WENNFEHLER, das hier völlig ausreicht.
Was deine Meinung zu mehrzelligen MatrixFmln betrifft, hat ja Daniel bereits (dankens­werter­weise) ein Pro-Argument (→ vgl nächsten Absatz!) genannt, das bisher kaum thematisiert wurde. Ich hätte mir auch schon etliche Fmln „zerschossen“, wenn sich diese nicht so konsistent verhalten würden. Dem kann man ja mit entsprd TabAufbau rechnung tragen. Es muss ja auch kein Nachteil sein, dass innerhalb des von ihnen aufgespannten Arrays keine Zeilen/Spalten eingefügt wdn können. Soviel Mehrarbeit bedeutet eine gelegentliche Aktuali­sierung ja nun auch nicht. Wer allerdings dauernd daran ändern muss, muss sich auch fragen lassen, warum es so ist und ob er das nicht mit einem sinnvolleren TabAufbau vermeiden könnte!
Was die Auswahl des aktuellen Arrays betrifft, ist es aber nun leider so, dass nur ausgewählt wird, was bereits vorhanden ist, niemals die tatsächlich mögliche Größe. Und das ist ja genau das, was dir missfällt, Werner. Mir hat das schon vor Jahren miss­fallen (man muss ja immer abschätzen u/o aus­pro­bieren, wieviel Zellen in ggf beide Richtungen es wdn) und ich hatte deshalb in den letzten ca 8 Jahren 2× versucht, dieses Problem auf unter­schiedliche Weise zu lösen:
  • Zuerst 2008/9 mit der UDF FlexArr, die, unterstützt durch eine automatisch anlegbare Ereignis­Prozedur und ein von ihr aufge­rufenes Pgm, die von ihr umschlossene MatrixFml auf die Maximal­Größe oder einen argumentierbaren Ausschnitt ausdehnt; man muss nur 2 Zellen auswählen, die die Richtung eines Vektors bzw der Reihe einer rechteckigen Matrix mit den meisten Elementen vorgeben. Außerdem sind noch einige andere Features eingebaut wie u.a. Wiederholung von Werten, Zwangs­Transponierung und Übernahme des Formats der 1.Zelle (nebst angepasstem Übertrag von Zell­Rahmen) in alle unforma­tierten Folge­Zellen (vgl unten!).
  • Jahre später, aber ebenfalls schon vor Jahren, im Zusammen­hang mit in Verbund­Zellen verborgenen Matrix­Fmln, wobei ggf nur 1 Zelle verwendet wdn muss, die Anzeige dieser verborgenen Zellen mit allen aus einer evtl darin enthaltenen MatrixFml resultie­renden Ergebnissen — quasi ein Platzspar­Modell der Tab­Kryptisierung.
  • Unter mehrfachem Einsatz von FlexArr hatte ich damals zB eine Fml entwickelt, mit der man das Kronecker-Tensor­Produkt darstellen (natürlich als mehr­zellige Matrix­Fml!) und so auf eine spezielle Fkt nur dafür verzichten kann. Das kannst du (bzw wer will) ja mal mit Standard­Fmln versuchen, viell sogar mit 1zellig normalen und ggf AGGREGAT…! ;-]
    Da das auch als Extra-Bsp in der Hilfe zu (m)einem AddIn enthalten ist, könnte ich das bei Interesse auch hier zeigen, nur nicht die UDF und ihre HilfsPgmm, auch, weil das zu umfangreich wdn würde.
    Gruß, Luc :-?

    Bild

    Betrifft: AW: ist wenig überzeugend ...
    von: ... neopa C

    Geschrieben am: 25.01.2016 09:35:05
    Hallo Luc,
    ... Du hast wenigstens erkannt, dass die Größenbestimmung des Arrays für eine mehrzellige Matrixformel schon ein Problem darstellt. Was mE wirklich schon ein KO-Kriterium sein kann. Und was den sogenannten Vorteil Schutz gegen Überschreibung/Löschung angeht, halte ich diesen für alle die formelbasierend arbeiten Nutzer für Erstens unnötig, und Zweitens sogar hinderlich. Wenn ich ein Zelle innerhalb einer mehrzelligen Matrix aktiviere, zeigt mir Excel (2010) nämlich nicht an, welche Zellen denn noch dazu gehören, das erschwert bei nachträglichen Strukturänderungen den Anpassungsaufwand doch erheblich. Und Änderungen sind trotzt bester Planung nun mal das "täglich Brot". Und wenn ich einen Formelschutz bräuchte oder wollte, würde ich den dafür von Excel vorgesehen Blattschutz aktivieren.
    Den Vorteil des Einsatzes von Bereichsnamen bzgl. besserer und übersichtlicher Strukturierung von Formeln nutze ich nicht erst seit gestern, auch wenn es bzgl. des Einsatzes von Bereichsnamen auch negative Stimmen gibt.
    Und nochmal: Die spez. AGGREGAT()-Formeln mit dem 1. Argument 14/15 nutze ich, da sie mE effektiver sind als vergleichbare {}-Formeln, weil letztere zwei Funktionen bzw. Funktionalitäten in den Formel mehr benötigen und zumindest für mich Erstere einfacher und schneller konstruiert sind.
    Meinerseits abschließend dazu folgende fragende Feststellung. Warum haben sich wohl SUMMENPRODUKT()-Formeln gegenüber Formeln wie {=SUMME(WENN())} durchgesetzt. Das ist zumindest mein Eindruck. Und wenn Vergleiche auch immer hinken, so sollte man diese doch nicht ganz außer Acht lassen.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Dito wenig überzeugend, ...
    von: Luc:-?

    Geschrieben am: 25.01.2016 12:05:03
    …Werner; ;-)
    1. Um Bereichsnamen geht's hier nicht, sondern um Namen für Fmln!
    2. Eine ZellFml wird in jeder Zelle komplett neu berechnet — benannte und MatrixFmln nicht! Du würdest ja auch nicht jedesmal, wenn du ein Buch lesen willst, eine komplette, unsortierte Bücherkiste durchwühlen wollen, sondern den Griff ins Buchregal vorziehen. ;-)
    3. Unter Xl14/2010 wird nicht mehr der ganze Array-Bereich bei Berechnung markiert, aber bei der von Daniel genannten Methode schon; das wäre also kein GegenArgument!
    4. Der Vorteil von SUMMENPRODUKT ist die Verarbeitbarkeit von Datenfeldern; SUMMEWENNs dagegen ist auf ZellBereiche festgelegt worden, was allein eine Frage der Pgmmierung ist, was ich dir auch mit AggregateXk demonstrieren wollte.
    Gruß, Luc :-?

    Bild

    Betrifft: AW: dazu folgendes ...
    von: ... neopa C

    Geschrieben am: 25.01.2016 19:05:36
    Hallo Luc,
    zu 1.) mit "Bereichsname" hab ich mich falsch artikuliert, srry, natürlich meinte auch ich benannte Formel(n).
    zu 2.) dazu lies doch nochmal, was ich diesbzgl. geschrieben hatte.
    zu 3.) was Du damit konkret meinst, ist mir momentan unklar. Zeig das bitte konkret an einem Beispiel auf.
    zu 4.) ich schrieb nichts von SUMMEWENN() sondern von {=SUMME(WENN())}
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Richtig, {=SUMME(WENN(...))}, ...
    von: Luc:-?

    Geschrieben am: 25.01.2016 20:59:54
    …Werner,
    aber der Vgl hinkt etwas, obwohl es sich in beiden Fällen um Datenfelder als Argument der HptFkt handelt. SUMMENPRODUKT ist so pgmmiert, dass es wie AGGREGAT im speziellen Fall wohl die gleiche Schnittstelle wie benannte Fmln nutzt, d.h., die ganze Ergebnismatrix, weil für diese Fkt nur die Übergabe von Matrizen/Vektoren sinnvoll ist. Das muss bei SUMME nicht unbedingt so sein (es können ja auch zu summierende Werte einzeln aufgeführt wdn!), weshalb der Pgmmierer hier darauf verzichtet hat und das der XlSteuerung überlässt, die dafür eine „Mitteilung“ in Form einer MatrixFml benötigt. Damit stehen in diesem Fall 2 mögliche Alternativen zV. Wer nur die MatrixVariante benötigt, weicht dann gern auf SUMMENPRODUKT aus, das in vielen Fällen ganz ähnlich fktioniert. Aber letztlich wird hierbei (1zellige Fml in beiden Fällen) zellweise auch immer alles neu berechnet, wobei SUMMENPRODUKT(WENN(…)) uU auch MxFmlForm benötigt! Darum ging's hier (vgl Pkt 2!) aber nicht, sondern darum, ob der Preis, den du für den Wegfall der MxFmlForm zahlst, nicht zu hoch ist, da es eine relativ einfache Alternative analoger Form ohne erhöhten RechenAufwand gibt → benannte Fmln bzw FmlTeile!
    Zu 3) muss ich eigentlich kein Bsp bringen; du musst nur Daniels Anweisungen folgen, was ich schließlich auch getan hatte:
    1. Eine beliebige Zelle einer MxFml auswählen!
    2. Menü Suchen & AuswählenInhalte auswählenAktuelles Array
    3. Das ganze Feld wird markiert, sofern es Zellen beansprucht; also alle Zellen mit dieser mehr­zelligen MatrixFml.
    Luc :-?

    Bild

    Betrifft: AW: naja ...
    von: ... neopa C

    Geschrieben am: 26.01.2016 17:07:09
    Hallo Luc,
    ... ich kann nur wieder feststellen, das wir uns diesbzgl. wieder nicht einigen können. Damit will ich aber nicht behaupten, dass es an Dir liegt, um von vornherein den Wind aus den Segeln zu nehmen.
    Hier deshalb nur noch ein paar Feststellungen zu teils eher nebensächlichen Details. Die geschilderte Markierungsmethode setzt mE voraus, dass man auch gleich weiß oder erkennt, dass sich um eine mehrzellige Matrix handelt. Weiterhin ist diese Methodik zumindest mir viel zu Nutzungsunfreundlich. Auch ging es mir darum, dass die notwendige Bereichsgröße vor der Erstellung ja unbekannt ist und sich später noch ändern kann.
    Und dann zeige mir doch mal bitte eine sinnvolle Formel, wo {=SUMMENPRODUKT(WENN(..))} wirklich notwendig ist. Ich kenne bisher keine, wo dies nicht einfach durch {=SUMME(WENN(..))} gelöst wird bzw. gelöst werden könnte.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Nee, nee, kein Wind, nur Rätsel über ...
    von: Luc:-?

    Geschrieben am: 28.01.2016 01:37:52
    …Rätsel, Werner; ;-)
    A: Ich hatte jetzt 'ne Zwangspause in dieser Diskussion einlegen müssen, weil ich versucht habe, das Ganze auf feste Füße zu stellen. Das ist mir nur zT gelungen. Das Hpt­Problem scheint darin zu bestehen, erst einmal eine geeignete Test­Methode für die ab Xl14/2010 möglichen 6 Varianten einer Matrix bzw Vektor ergebenden Fml zu finden. Meine Test­Methode hatte sich darauf verlassen, dass das Anklicken einer in eine Fml einge­bundenen Zelle bei Auto­Kalk'Modus auch alle Berech­nungen durch­führt und man die dabei vergangene Zeit mit Timer in Ereignis­Prozedur …_Calculate messen kann. Das hat zwar geklappt, nur sind die Ergebnisse verwirrend, denn die Unter­schiede zwischen 5 Varianten sind relativ marginal und bewegen sich innerhalb der Toleranzen von Minimum nach Maximum, deren Unterschied leicht bis zum doppelten Minimum betragen kann. Das kann nur einerseits der Xl- und andererseits der Win(10)-Steuerung geschuldet sein (je öfter desto schneller!). Meine Prozessoren schienen dafür auch nur mit einem Bruch­teil ihrer Kapazität zu arbeiten. Da das sicher immer so ist, kann ich dazu also kein abschlie­ßendes Urteil fällen, sondern muss es bei logischen Schluss­folge­rungen belassen.
    Eines haben meine Tests aber mit Sicherheit erbracht, Xl hat anscheinend ein Problem mit der Einzelwert­Wiedergabe von Daten­feldern aus benannten Fmln, also der von mir vorge­schlagenen Alternative für deine Art der AGGREGAT-Nutzung. Es sieht so aus, als ob dabei stets auch der Ausdruck neu berechnet wdn würde (was ich nicht ausgeschlossen hatte, aber als wenig wahr­scheinlich befand). Das wider­spricht eigentlich einer sinn­vollen Steuerungs­Logik und könnte interne Ursachen haben. Mit Vektoren von 10Tsd Werten, wie ich sie hierbei verwendet hatte, ist diese 6.Variante jedenfalls hoff­nungslos über­fordert, obwohl es bei 1000 noch so aussah, als ob sie schneller als die entsprd AGGREGAT-Variante wäre und der MxFml­Variante nicht nach­stünde, die bei 1000 Werten auch doppelt so schnell wie die AGGREGAT-Einzelwert­Rückgabe zu sein schien. Es sieht beinahe so aus, als ob die Leistungs­fähigkeit dieser speziellen AGGREGAT-Verwendung mit wachsender Daten­menge zunähme und auch noch relativ unab­hängig von ihrer Angabe­Form, wobei aller­dings begründet davon ausge­gangen wdn kann, dass die MxFml-Variante von AGGREGAT im Schnitt etwas schneller sein dürfte. Der interne Bereinigungs- und Ver­teilungs­Mecha­nismus scheint hierbei jeden­falls keinen relevanten Zeit­Faktor darzu­stellen.
    Das alles schließt natürlich nicht aus, dass man in anderer Hard- und Software-Umgebung bzw bei anderem „Versuchs­aufbau“ auch zu etwas anderen Ergeb­nissen kommen könnte. Deshalb wäre es ggf sinn­voller, fest­zu­stellen, wie oft eine benannte Fml tat­sächlich neu berechnet wird (bei einer Einzel­wert-AGGREGAT-Fml dürfte das von der Zell­Anzahl abhängen, falls nicht doch ein zellen­über­greifender interner Abgleich erfolgt, der aller­dings kaum fest­stellbar wäre). Bei MatrixFmln jedweder Art erfolgt das jeden­falls nur 1×, wie man schon bei einfachem Ersetzen fest­stellen kann.
    B: Zur Vorabbestimmung des Platzbedarfs einer MatrixFml hatte ich mich ja bereits geäußert. Das kann man nur mit Abschätzen und Probieren erreichen, will man nicht, wie ich es könnte (aber meist nicht tue!), VBA einsetzen (vgl meine Bemerkungen zur UDF FlexArr!).
    Warum Xl nun nicht mehr eine Matrix bei Berechnung markiert, wird wohl nur MS beantworten können. Möglicherweise haben sie deshalb dieses weitgehend unbekannte Feature spendiert…!?
    C: Zu {SUMMENPRODUKT(…)} kann ich mich erinnern, so etwas in unseren früheren Diskussionen mal gezeigt zu haben, worauf du (viell war's aber auch WF?) geantwortet hattest, das läge ja auch an WENN! Außerdem bin ich mir sehr sicher, in unseren jüngeren Diskussionen zur sog Matrix(formel)funktionalität (viell kurz MFF oder MxFF) erwähnt zu haben, dass die Erkennung und Berechnung eines aus einem Ausdruck als Argument resultierenden Datenfeldes Grenzen hat — er darf nicht zu komplex sein! Es kann nämlich nicht davon ausgegangen wdn, dass der Pgmmierer das so gelöst hat, wie ich mit Vs1.2 von AggregateXk (dann ließe sich die Fkt nicht AUSWERTEN!).
    Morrn, Luc :-?

    Bild

    Betrifft: AW: Rätsel sind zum lösen da ;-) ...
    von: ... neopa C

    Geschrieben am: 28.01.2016 09:57:52
    Hallo Luc,
    ... wenn nicht Heute, dann eben Morgen oder Übermorgen.
    Ich danke Dir für diesen konstruktiven Beitrag, aber insbesondere für Deine diesen vorausgehenden Untersuchungen.
    Vielleicht können wir folgendes vorläufiges Fazit ziehen. Nicht alle neuen Funktionen /-Funktionalitäten sind von Grund auf viel besser aber auch nicht viel schlechter als bisherige. Aber bei allen Mängeln und nicht realisierten oder gar realisierbaren Wünschen, verdienen sie zumindest Beachtung. Also ich persönlich werde es weiter anstreben (und damit meine ich nicht nur Excel), Neuen wie Jungen eine echte Chance zu geben. Oftmals ergeben sich so teils noch ungeahnte Möglichkeiten sowohl im unmittelbaren Einsatz, als auch in ihrem Entwicklungspotential.
    Guter Wein will auch reifen :-)
    In diesem Sinne wünsche ich Dir noch einen guten Tag.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Gern; dir auch, Werner! ;-) owT
    von: Luc:-?
    Geschrieben am: 28.01.2016 15:23:20
    :-?

    Bild

    Betrifft: Wichtiger Nachtrag zu UDF aus hierher ...
    von: Luc:-?

    Geschrieben am: 29.01.2016 03:44:02
    …verlinkendem Thread:
    Die UDF AggregateXk, Version 1.2, kann zur Version 1.3 aufgerüstet wdn, wenn die Ergänzungen lt folgendem Beitrag vorgenommen wdn:
    Archiv: https://www.herber.de/forum/archiv/1468to1472/t1471659.htm#1471932
    Forum: https://www.herber.de/forum/messages/1471932.html
    Luc :-?

    Bild

    Betrifft: AW: sverweis verschachtelt
    von: Jürgen Huber

    Geschrieben am: 22.01.2016 20:23:50
    werden die Daten von Ihnen erzeugt, oder kommen Sie aus einer fremden Quelle?
    Wenn die Daten von Ihnen erzeugt werden, dürfte es doch kein Problem sein UV und 01.01. In separate Spalten darzustellen. Wenn die Daten nicht von ihnen stammen, können Sie die Daten über die Funktion Teil () entsprechend separat in 2 verschiedenen Spalten darstellen.
    Ich weiß natürlich auch nicht, wie detailliert sie filtern möchten.

     Bild
    Excel-Beispiele zum Thema "sverweis verschachtelt"
    SVERWEIS auf geschlossene Arbeitsmappe aus Makro aufrufen Benutzerdefinierte SVERWEIS-Funktion über mehrere Bereiche
    Arbeitszeittabelle und SVERWEIS-Formel Zugriff über SVERWEIS() auf eine Artikelliste
    SVERWEIS-Formel über mehrere Fundstellen SVERWEIS-, WVERWEIS- und Matrixformel-Beispiele
    SVERWEIS, WVERWEIS, INDEX, VERGLEICH und Zielwertsuche Zweidimensionale Matrix mit der SVERWEIS-Funktion durchsuchen
    Hyperlinks zu SVERWEIS-Bezugstabellen anlegen SVERWEIS als Ereignisprozedur