die "BU" und die Jahreszahl habe ich aus dem Dateinamen, findet sich in der Abfrage "Daten".
Wenn Du meine Datei nimmst und diese nicht editieren kann, dann sperrt Dein Windows-System / Sicherheitstools den Zugriff. Nach dem Runterladen hast Du die Datei schon "entblockt"? https://www.ninjaone.com/blog/how-to-unb...n-windows/
Zum andere, Abfragen lassen sich via Drag&Drop oder Copy&Paste von einer Datei in eine andere Übertragen.
Oder kopiere einfach mal die Abfrage Daten, öffne Notepad und füge Sie dort ein, dann siehst Du den Text von allen Abfragen die mit dieser verbunden sind.
Hallo Andreas, ich konnte die Abfrage in mein lokales Testumfeld kopieren - wie vorgeschlagen. Da liess sich der Datenorder auch auf mein lokaes Verzeichnis umstellen.
Bei der der Ausführung kommt jetzt aber eine Fehlermeldung: die Spalte "Typ" der Tabelle wurde nicht gefunden (s. Screenshot). Dieser Fehler kommt sowohl wenn ich in allen Daten-Dateien in Zelle A1 'Unit_x' mit x=1,2,3 stehen habe, als auch wenn in Zelle A1 überall 'Typ' statt 'Unit_x' steht. Der Fehler scheint aus der ~fntextreplaceany-Ecke zu resultieren. ...
Was kann die Ursache sein? Ich bin überfordert. Danke! Hajo
ps: es gibt im Daten-Ordner nur noch 4 Dateien für die Unit_1,2,3, - Unit_3 allerdings einmal für 2024er und einmal 2025er Daten. Falls das für die Abfrage in fntextreplaceany wichtig ist...
(04.12.2025, 12:07)Hajo1 schrieb: Der Fehler scheint aus der ~fntextreplaceany-Ecke zu resultieren. ...
Nee.
Auf der rechten Seite siehst Du die Schritte, der aktuelle Schritt ist "Change Type". Klick einfach mal den Schritt davor an, dann kannst Du die Abfrage zu dem Zeitpunkt sehen.
Und dann wrist Du sehen das es keine Spalte namens "Typ" gibt. Der Grund dafür ist die Transformation und die ist nicht in dieser Abfrage. sondern in der Function "Datei transformieren".
An Deinem Screenshot kann ich sehen das Du da schon eine Menge rumgemurkst hast, von daher weiß ich jetzt nicht ob das folgende noch funktioniert.
Also, wenn man via "Daten \ Aus Ordner" in Excel mit Power Query wie beschrieben Daten importiert, dann erstellt PQ eine ganze Menge Abfragen, u.a. die Function "Datei transformieren" welche die tatsächliche Transformation der Daten macht. Wenn Du diese Abfrage mal anklickst, dann siehst Du in PQ nix, also keine Schritte, keine Daten, nada, nur ein Eingabefeld "Parameter1 was ein Feld vom Typ "binary" erwartet.
Und das ist für die Entwicklung einer Function natürlich blöd, daher hat Microsoft sich da ein Feature ausgedacht was nur bei dieser Vorgehensweise etabliert wird. Und zwar wird zusätzlich eine Abfrage "Beispieldatei transformieren" erzeugt und in der siehst Du alle Schritte, kannst jeden einzelnen Dir anschauen, welche hinzufügen/löschen, usw. Der Trick ist nun das diese Schritte (der MCode dahinter) automatisch in die Function "Datei transformieren" kopiert werden.
Das ist für die Entwicklung einer Transformation ganz angenehm, aber rein faktisch hat die Abfrage "Beispieldatei transformieren" später, wenn wirklich Daten fließen, nix mehr damit zu tun.
Z.B. die Function "fnTextReplaceAny" habe ich selber geschrieben, da gibt es dieses Feature nicht!
Ich würde an Deiner Stelle nochmal ganz von vorne mit einer leeren Datei und ein paar Beispieldateien in einem Ordner anfangen, ich denke das wird einfacher sein als das ganze Gerümpel aufzuräumen das Du bis jetzt fabriziert hast.
Ok, jetzt läuft's. ::puh, daumenhoch (Ich hatte in den Bsp.Dateien schon die erste Zeile gelöscht und Unit_x auf Type geändert etc. aber das passiert ja bereits in Deiner Abfrage, war also doppelt...)
Ich bin nun einen großen Schritt weiter, Danke! Jetzt will ich die laufende Abfrage auf meine realen Daten übertragen. In den Detail-Schritten stehen ja Bsp.-spezifische Kommandos/Inhalte wie Units, Spaltenüberschriften etc., und die lauten in dem Real-case natürlich anders.
Gehe ich dafür durch den Quellcode und ändere es dort manuell (und wo genau: in Bsp.-Datei transformieren / Daten / in beiden? Du sagtest ja auch, dass 'Bsp.Datei transformieren' nachher in die Datenabfrage überführt/kopiert wird ...), oder gibt es einen eleganteren Weg dafür?
...ich denke ja immer noch, dass die Sache nicht ganz legal ist, aber da Andreas (übrigens eine sehr schöne) funktionierende Lösung erstellt hat, ist es jetzt auch egal.... Der Unterschied zu Andreas' Lösung: - Stammverzeichnis kann in der Parametertabelle geändert werden - es ist nur eine einzige Abfrage erforderlich die - quasi volldynamisch auch die unterschiedlichen Dateien, Unitbezeichnungen u.a. händelt. Im Prinzip das, was ich im Post #6 schon beschrieben hatte.
Der sicherste Ansatz für einen Irrtum ist der Glaube, alles im Griff zu haben. Nur, weil ich den Recorder bedienen kann, macht mich das noch lange nicht zum Musiker.
(04.12.2025, 14:34)Hajo1 schrieb: Jetzt will ich die laufende Abfrage auf meine realen Daten übertragen. In den Detail-Schritten stehen ja Bsp.-spezifische Kommandos/Inhalte wie Units, Spaltenüberschriften etc., und die lauten in dem Real-case natürlich anders.
Ich sehe da keine Probleme, es gibt nur eine Überschrift die wirklich abgefragt / geändert wird und das ist die der ersten Spalte (Zelle A2 in der Datei).
In meiner Beispieldatei hatte ich "Eingabe!", "Unit_1" , "Unit_2" , "Unit_3" , "Unit_4" berücksichtigt. Wenn in den restlichen Dateien da nix anderes steht passt das.
Sollten da noch mehr verschiedene Werte stehen, dann müsste man einen MCode schreiben der in der Datei "kuckt" was da steht und dann den Wert immer in "Typ" ändern. Ich habe das absichtlich nicht gemacht um nicht noch mehr Verwirrung zu stiften. Den generierten MCode anpassen ist als Anfänger nicht soo einfach... dauert bis man da durchblickt.
BTW, in Deiner "Beispieldatei transformieren" sollte kein "Change Type" (heißt auf Deutsch "Datentypen ändern"??) vorkommen, es gibt eine Einstellung in Power Query die automatisch diesen Schritt bei manchen Aktionen im UI generiert.
Zitat:Ich sehe da keine Probleme, es gibt nur eine Überschrift die wirklich abgefragt / geändert wird und das ist die der ersten Spalte (Zelle A2 in der Datei).
Ok, konkret ist es so: es gibt ca 20 verschiedene Units (BUs) mit jeweils 5-10 Zeitständen (Geschäftsjahre) - macht grob bis zu 200 Dateien. Im ersten Schritt sind nur 2 Jahre relevant, also 'nur' ca. 40 Dateien.
Zitat:In meiner Beispieldatei hatte ich "Eingabe!", "Unit_1" , "Unit_2" , "Unit_3" , "Unit_4" berücksichtigt. Wenn in den restlichen Dateien da nix anderes steht passt das.
Diese Angaben stehen nur in den Bsp-Dateien. In Real sind die Felder A2 allesamt leer. Die BU-Einheit ergibt sich allein aus den Dateinamen mit folgendem Aufbau: 23Q2 - yy yyyyyy y yyyy.xlsx wobei - 23 das Geschäftsjahr 2023 bezeichnet - Q2 das relevante Quartal - und hinter dem " - " kommt ein Freitext unterschiedlicher Länge mit Lücken bis zur .xlsx-Endung, die die BU bezeichnet. Ich glaube/hoffe, diese Anpassungen wären noch machbar.
Jetzt haben sich aber nochmal die Datei-Kopfzeilen geändert, da sie aus einem geänderten WP-Vorsystem als xls-Download generiert werden : - Die obersten 3 Zeilen kann man ignorieren/entfernen - Die Zeilen 4-6 ergeben nun >zusammen< die Codierung für die Berichtsperioden/Spalten, und zwar bsp.haft - Z. 4: 2024 als Geschäftsjahr - Z. 5: 2. Quartal - Z. 6: Budget/Vorschau/IST-Werte Die Jahreszahl-Spalten wird in jeder Datei für mehrere Jahre angegeben, daher muss man sie gesondert zur Jahreszahl aus dem Dateinamen verwerten. Die Zeilen 4:5 enthalten zudem teilweise horizontal-gruppierte Zellen, die mit den Zellen in Z. 6 verknüpft werden müssen für eine eindeutige Spaltenbezeichnung.
Ich fürchte, das übersteigt damit die Möglichkeiten der Anwender (jetzige und künftige), da hier regelhafte Anpassungen detailliert und tief im Quellcode nötig werden. Änderungen der Datenstruktur scheinen - wie man sieht - ja regelmäßig anzustehen.
Vermutlich wird die Umsetzung via VBA-Makro dann doch einfacher ... alle relevanten Work.sheets erstmal komplett in ein Work.book hochladen, neu-pivotieren und dann verarbeiten.
Danke aber sehr ins Forum, insbesondere auch Dir Andreas!, für die sehr konkrete und geduldige Hilfe ! Viel dazu gelernt.
also ich sehe da nicht wirklich ein größeres Problem.
Zum einen, der Code muss ja nicht immer alle Dateien einlesen. Wenn man Dateien aus der Vergangenheit einmal konvertiert hat, dann kann man die Daten "ordentlich" so in einer "Datenbank" abspeichern das auch zukünftige Generationen davon was haben. Daher kann man das Projekt auch teilen und einen Konverter machen der eine spezifische Gruppe von Dateien verarbeiten. Und bei der nächsten Gruppe passt man den Code halt an.
Sicherlich sind einige Sonderfälle mit VBA einfacher zu lösen, wenn man sich denn nun damit genau auskennt. Aus meiner Sicht ist das nur eine Frage des Wissensstandes. Und ganz zur Not kann man aus einzelnen Dateien auch mal die Daten manuell in die Datenbank überführen.
Außerdem gibt es auch für Firmen die Möglichkeit externe Mitarbeiter, wie mich, "anzumieten" und dann müsste man einfach mal darüber sprechen wie man den Prozess der Datenkonvertierung so im Unternehmen integriert das er auch in Zukunft funktioniert. Nach meiner Erfahrung wissen die oberen Etagen aus Unwissenheit nicht welche Probleme sie erzeugen, weil in der Regel dort "visuell" gearbeitet wird und da ist es dann egal ob die Überschriften auf eine oder mehrere Zeilen verteilt werden.
BTW, auch das ist nicht wirklich ein Problem, man rotiert die Tabelle einmal um 90°, dann hat man die Überschriften in Spalten und kann diese Bequem verbinden, dreht 90° zurück und fertig. Nur so zum Beispiel, es gibt da auch viele andere Möglichkeiten. Ist für mich alles nicht neu.
Wenn Du Hilfe brauchst, sprich mit Deinem Chef und schick mir im Fall der Fälle eine Mail.
05.12.2025, 10:11 (Dieser Beitrag wurde zuletzt bearbeitet: 05.12.2025, 10:11 von Ralf A.)
(04.12.2025, 18:55)Hajo1 schrieb: ...Diese Angaben stehen nur in den Bsp-Dateien. In Real sind die Felder A2 allesamt leer. Die BU-Einheit ergibt sich allein aus den Dateinamen mit folgendem Aufbau: 23Q2 - yy yyyyyy y yyyy.xlsx wobei - 23 das Geschäftsjahr 2023 bezeichnet - Q2 das relevante Quartal - und hinter dem " - " kommt ein Freitext unterschiedlicher Länge mit Lücken bis zur .xlsx-Endung, die die BU bezeichnet. Ich glaube/hoffe, diese Anpassungen wären noch machbar.
Jetzt haben sich aber nochmal die Datei-Kopfzeilen geändert, da sie aus einem geänderten WP-Vorsystem als xls-Download generiert werden : - Die obersten 3 Zeilen kann man ignorieren/entfernen - Die Zeilen 4-6 ergeben nun >zusammen< die Codierung für die Berichtsperioden/Spalten, und zwar bsp.haft - Z. 4: 2024 als Geschäftsjahr - Z. 5: 2. Quartal - Z. 6: Budget/Vorschau/IST-Werte Die Jahreszahl-Spalten wird in jeder Datei für mehrere Jahre angegeben, daher muss man sie gesondert zur Jahreszahl aus dem Dateinamen verwerten. Die Zeilen 4:5 enthalten zudem teilweise horizontal-gruppierte Zellen, die mit den Zellen in Z. 6 verknüpft werden müssen für eine eindeutige Spaltenbezeichnung.
Die in Post #25 angesprochene Wundertüte macht ihrem Namen alle Ehre. Weshalb kannst Du (und alle anderen Wundertütenverteiler) nicht von Anfang an die bekannten Bedingungen angeben? Ich würde an Deiner Stelle Andreas' Angebot annehmen. Erstens weil er gut ist und 2., weil es angebracht scheint und 3,. wenn Du (oder wer auch immer) diese Wundertütentaktik mit sich ständig ändernden Bedingungen/Anforderungen bezahlen müsst, dann hat der Dienstleister wenigstens was davon und Ihr macht Euch evtl. mal Gedanken darüber, ob Geheimnistuerrei und Salamitaktik sinnvoll und wirtschaftlich ist.
Der sicherste Ansatz für einen Irrtum ist der Glaube, alles im Griff zu haben. Nur, weil ich den Recorder bedienen kann, macht mich das noch lange nicht zum Musiker.
Außer wenn mich eine unausgegorene Fragestellung wirklich reizt, beschäftige ich mich noch mit solchen. Ansonsten bin ich es mittlerweile ziemlich leid, dass man bei kostenloser Hilfe den Fragestellern oft die Würmer einzeln aus der Nase ziehen muss, bzw. diese nach jeder Lösung mit neuen Fällen um die Ecke kommen, die noch zu beachten sind.
Auch bin ich es aus meiner aktiven Zeit als (SAP-)Softwareentwickler gewöhnt, den kompletten Kontext einer Anforderung zu kennen, da dann meist die besseren Ergebnisse herausgekommen sind.
:
