...Du meinst, weil die Umbenennung der Datumsspalten unnötig ist? Darauf will ich mich nicht versteifen, denke aber dennoch, dass man darauf verzichten kann. Wenn nicht... dafür gab's ja einen Vorschlag...
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.
die Spalte Stock, also die für die manuellen Einträge, gehört in nicht in die Ergebnis- sondern in die Quelltabelle
und die dazu folgenden Aussagen.
Denn es nutzt überhaupt nichts, wenn die Spalte schon ohne Inhalt vorhanden ist, sich aber bei der nächsten Aktualisierung durch neue bzw. wegfallende Artikel eine andere Reihenfolge ergibt. Da manuelle Einträge ohne Zeilenbezug ja nicht mitwandern.
Deshalb sichere ich vor jeder Aktualisierung die Ergebnistabelle, um dann mit einem Merge, die zuvor gesicherten Bestände, den neuen Daten zuzuordnen.
Durch zwischenzeitliche Zu- und Abgänge sind diese dann zwar im Normalfall falsch, aber dass scheint ja wohl besser zu sein, als die Bestände nach jeder Aktualisierung vollständig neu erfassen zu müssen.
09.11.2024, 12:44 (Dieser Beitrag wurde zuletzt bearbeitet: 09.11.2024, 12:44 von Ralf A.)
(09.11.2024, 09:35)ws-53 schrieb: Denn es nutzt überhaupt nichts, wenn die Spalte schon ohne Inhalt vorhanden ist, sich aber bei der nächsten Aktualisierung durch neue bzw. wegfallende Artikel eine andere Reihenfolge ergibt. Da manuelle Einträge ohne Zeilenbezug ja nicht mitwandern.
Wie kommst Du darauf, die Spalte wäre ohne Inhalt? Mit ihr ist es genauso, wie mit jeder anderen Quellspalte. Daten müssen vorher eingegeben werden. Das ist ja auch der Sinn einer Spalte, die manuell ausgefüllt werden soll. Natürlich muss man die korrekte Reihenfolge beachten. Zuerst die Daten der Quelle pflegen und erst danach auswerten lassen. Nochmal... eine Tabelle kann nicht gleichzeitig Quelle und Ziel sein. Sowenig, wie Du in einer Formel einen Zirkelbezug verwenden kannst.
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.
09.11.2024, 13:09 (Dieser Beitrag wurde zuletzt bearbeitet: 09.11.2024, 13:09 von ws-53.)
Zitat:Nochmal... eine Tabelle kann nicht gleichzeitig Quelle und Ziel sein.
Das wüsste ich aber !!!
Wenn du nach der Erstellung einer Abfrage, die Quelle auf den Namen der erzeugten Tabelle änderst, dann geht es. Dazu gab es von mir im mof-Forum den Beitrag "Hausinterner Geräteverleih".
Auch wenn Ken Puls (excelguru.ca) nicht viel davon hält, funktioniert es bei mir bisher problemlos.
Und in der Quelle soll der Bestand ja nicht eingetragen werden, da dann ja der Anwender in der großen Tabelle immer die richtige Zeile (Filter Forecast Version) eintragen müsste.
Natürlich wäre es viel besser die Bestände ebenfalls zu impoiteren und max. eine Spalte für die manuelle Erfassung von Bestandskorrekturen vorzusehen.
09.11.2024, 13:59 (Dieser Beitrag wurde zuletzt bearbeitet: 09.11.2024, 13:59 von Ralf A.)
(09.11.2024, 13:09)ws-53 schrieb: Das wüsste ich aber !!!
Wenn du nach der Erstellung einer Abfrage, die Quelle auf den Namen der erzeugten Tabelle änderst, dann geht es. Dazu gab es von mir im mof-Forum den Beitrag "Hausinterner Geräteverleih".
Auch wenn Ken Puls (excelguru.ca) nicht viel davon hält, funktioniert es bei mir bisher problemlos.
Und in der Quelle soll der Bestand ja nicht eingetragen werden, da dann ja der Anwender in der großen Tabelle immer die richtige Zeile (Filter Forecast Version) eintragen müsste.
Natürlich wäre es viel besser die Bestände ebenfalls zu impoiteren und max. eine Spalte für die manuelle Erfassung von Bestandskorrekturen vorzusehen.
...smile... das ist jetzt aber ein wenig "Lindnern"... also, die Dinge so hinbiegen, dass sie scheinbar passen.... Wenn Du die Quelle in der Abfrage in einem weiteren Schritt umbenennst, erstellst Du quasi eine neue Tabelle. Hast also eine neue Zieltabelle. Natürlich kannst Du dann weiterhin über den Quellnamen auf die ursprüngliche Originalquelle zugreifen. Aber die neue, die umbenannte ist intern trotzdem eine andere. Man sieht es nur nicht. Ok, ich gebe zu, an die Möglichkeit hatte ich jetzt nicht gedacht, aber die Aussage, Quelle und Ziel als eins geht nicht, bleibt dennoch gültig. Aber das ist jetzt eher eine "akademische" Diskussion...
Zum Punkt "in der Quelle soll nix eingetragen werden (weil zu groß), hatte ich im Post #8 und #10 eine Möglichkeit gepostet. Erst die Quelle so aufbereiten, dass sie passt, inkl. Zusatzspalte mit Standardwert für manuelle Eintragungen anfügen und dann (nach manueller Ergänzung) diese Tabelle als neue Quelle in einer weiteren Abfrage verwenden. Ist im Grunde auch nix anderes...
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.
12.11.2024, 11:29 (Dieser Beitrag wurde zuletzt bearbeitet: 12.11.2024, 11:31 von Hoppolero.)
Sorry, dass ich erst jetzt mich wieder mit "einbringe". Ich arbeite heute erst wieder. Ich werde mir das gleich mal alles anschauen und wieder auf euch zukommen. Ihr könnt euch ja vorstellen wie es ist, es wollen gern alle eine Lösung sehen, aber keiner hat Veständnis das es unter Umständen Zeit kostet. :D Danke für euren Einsatz.
...hab mir das mal genauer angesehen.... ganz schönes Chaos.... Keine Ahnung, ob Dein Code das macht, was Du eigentlich willst, aber zu dem, was mir aufgefallen ist, folgende Anmerkungen:
die Spalte Stock, also die für die manuellen Einträge, gehört in nicht in die Ergebnis- sondern in die Quelltabelle
wenn Du sie schon in eine Ergebnistabelle einfügst (weil Du da schon etwas aufgeräumt hast), muss diese dann die Quelltabelle für die (neu) zu berechnende (Ergebnis)Tabelle sein. Keine Tabelle kann gleichzeitig Quelle und Ziel sein!
Das heißt in Deinem Fall, die tab_matdispo wäre dann die Quelltabelle für die endgültige Endergebnisabfrage.
Die Datumsspalten müssen weder umbenannt werden, noch brauchen die eine Typzuweisung (deshalb ist kein umbenennen nötig), Zudem werden die nirgendwo berechnet oder anderweitig benötigt. Und unter der Voraussetzung, dass die Spaltenanzahl und Reihenfolge immer gleich ist, kannst Du das 2-stellige Dezimalformat auch direkt für die entsprechenden Spalten (im Zieltabellenblattregister selbst) formatieren statt im M-Code anzuweisen. Falls Du sie löschen willst, dann markierst Du halt die, die Du behalten willst und löschst alle anderen... Falls doch ein umbenennen nötig sein sollte, dann kannst Du exemplarisch so vorgehen :
Ansonsten... in den Geänderten Typ - Arbeitsschritten entfernst Du einfach die Spalten und Typangaben für die Datumsfelder. Somit gibt es auch keine Konflikte. Bsp.:
Code:
= Table.TransformColumnTypes(Quelle,{{"Number", Int64.Type}, {"Name", type text}, {"Conversion", type text}, {"Forecast Version", type text}, {"Purchase Deliver To", type text}, {"Stock Main Store", Int64.Type}, {"Stock Float Store", type number}, {"UoM", type text}, {"Max per Day", type number}, {"Sum", type number} })
Viele Schritte kannst Du zusammenfassen (Geänderte Typen, neu anordnen usw.) Aber immer die Reihenfolge und die beabsichtigte Tabelle (Arbeitsschritt) beachten. Deshalb ist es immer wichtig vorher zu überlegen, was man erreichen will. Kurzen Spicker gemacht hilft mitunter dabei.
Zitat:Keine Ahnung, ob Dein Code das macht, was Du eigentlich willst....
Der Stock sollte in die Ergebnistabelle rein, da die Leute welche damit arbeiten, mit einem Tablett im Tiefkühler rumrennen und sie mit dem mobilen Excel arbeiten und dies ja eh schon reduziert funktioniert. Und da wäre ein wechsel zwischen den Registern nicht hilfreich. Vorbereitet wird das File am PC und dann auf das Tablett übertragen. Ich hoffe ich verkompliziere das damit nicht noch.
Den Punkt, dass ich es in der Ergebnistabelle direkt formatieren kann und die Formatierung erhalten bleibt hatte ich nicht gewusst. Ich dachte, das wird immer wieder überschrieben bei der Aktualisierung. Verstehe ich es richtig, ich könnte alle Daten einlesen in die Zieltabelle und dort dann entsprechend alle Spalten löschen die ich brauche und formatieren, diese werden durch eine Aktualisierung aber nicht wieder eingefügt und die Formatierung zurückgesetzt? Das wusste ich nicht und habe immer gedacht, etwas was in der Zieltabelle formatiert wird, bei der Aktualisierung wieder überschrieben wird. Ich hoffe ich habe es jetzt nicht falsch verstanden.
Bzgl. des Punktes mit dem zusammenfassen, habe ich mich schon immer gefragt warum das so merkwürdig gelöst ist in den Schritten. Das habe ich wirklich nicht in Erwägung gezogen. Unerfahrenheit halt...leider.
Das sieht ja schon sehr vielversprechend aus. Ich werde das gleich mal testen. Ich hatte wirklich gedacht, diese Anfrage ist nicht so ein komplexes Thema. Danke für euren Einsatz.
Ich befürchte nur, dass wenn ich das so als Standard freigebe in den Abteilungen und es funktioniert nicht mehr, dann ist das komplette System für den Arsch.
Selbst wenn ich es jetzt irgendwann verstehe (hoffentlich schnell), hoffe ich ja das ich bald mehrere Millionen gewinne und ich dann dies nicht mehr fixen kann und sie dann hilflos sind. :D
13.11.2024, 13:31 (Dieser Beitrag wurde zuletzt bearbeitet: 13.11.2024, 13:32 von Ralf A.)
Moin,
da es offensichtlich Verständnisirritationen gab, muss ich zunächst erst mal ein paar Begrifflichkeiten klarstellen. Wenn ICH von Quelle spreche, dann meine ich damit die Originaldaten. Und die kann ich nicht manipulieren. Das Original bleibt als Original immer unverändert. Wenn ich es manipuliere, dann im Rahmen einer Abfrage. Dort ist es aber eine Kopie des Originals (der Quelle). WS-53 meint aber (vermutlich) den (meist) 1. Arbeitsschritt, der im dt. PQ standardmäßig als Quelle bezeichnet wird. Das ist in diesem Fall aber lediglich ein Variablenname , der nicht von mir gemeint ist und auch Oma Hilde heißen könnte), für eine Kopie der Quelle.
Wenn ich von Ziel spreche, dann meine ich damit das endgültige Ergebnis einer Abfrage. Das kann alles mögliche sein. Ein Text, 'ne Zahl, 'ne Liste, 'ne Tabelle, 'n Pivotchart oder auch nix von allem. Man kann das Ergebnis auch einfach nur ins Datenmodell laden.
So, hoffe, das wäre jetzt geklärt...
Jetzt zu Dir. Ich habe keine Lust, mir auszudenken, was Du willst, vermute aber, du willst die Daten aus den beiden Registerblättern MatDispo und Purchase Order als Quellen nutzen. Daraus willst Du eine für die Erfassung im Kühlhaus und eine für die Auswertung erstellen. Für die Kühlhausarbeit sollen die Daten aber vorher abgespeckt werden und die Spalte Stock hinzugefügt werden. Stell ich mir vor, dass Du Dir das so vorgestellt hast...:) Das heißt, es muss erstmal geklärt werden, welche Daten gebraucht werden. Hier wäre jetzt Dein Spickzettel ganz hilfreich. Am Ende kannst Du die "Stockspalte" hinzufügen. Das wäre die 1. Ergebnistabelle fürs Kühlhaus. Für die Verwaltung, die das dann auswerten soll, wäre diese 1. Ergebnistabelle eine der Grundlagen für eine 2. Abfrage (und somit für ein 2. Ergebnis), in das die berechnete Spalte hinzugefügt wird. Auch hier wäre ein Spickzettel hilfreich. Was wird gebraucht, woher kommt das, was soll damit passieren, usw....
Insgesamt würde ich aber dennoch die Verwendung einer Datenbank empfehlen, da es hier offensichtlich um eine Mehrbenutzeranwendung gehen wird.
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.
Ciao, Ralf
Folgende(r) 1 Nutzer sagt Danke an Ralf A für diesen Beitrag:1 Nutzer sagt Danke an Ralf A für diesen Beitrag 28 • Hoppolero