5
ganz viele Dateien per Batch aufteilen oder - und einpacken
Hallo Leute,
ich habe ein kleineres Problem.
Unsere Buchhaltung hat über lange Zeit Unmengen XML Dateien, die zu den Buchungen gehören, gesammelt.
Da wir einen Haufen Kunden am Tag haben, beläuft sich die Anzahl der XML Dateien momentan auf 25.798 Stück in einem Ordner! (Läd mächtig lange...)
Täglich kommen ca. 100 - 120 Kunden dazu.
Da die Buchhaltung es bis jetzt vernachlässigt hat die XML Dateien in Ordner aufzuteilen die sich an dem Beispiel 2008-07-26 ausrichten möchte ich dies nun per Batch nachholen. Leider bin ich mit Batch Dateien nicht so grün und komme meist über ein NET USE und SHUTDOWN nicht hinaus.
Am liebsten würde ich die XML Dateien wie das Datum ihres Erzeugens in die Ordnerhierarchie verschieben und nachträglich im passenden Ordner per Winrar packen.
(2008-07-26 -> 2008-07-26.rar)
Leider fehlt mir der Ansatzpunkt um dies zu automatisieren.
Ich nutze zwar innig den Totalcommander aber dieser ist mir in dem Fall auch keine Hilfe…
Vielleicht hat jemand eine Idee wie ich dies langfristig automatisieren kann.
INFO:
Shopprogram -> auftragsnr.xml Datei -> Buchungsprogramm -> auftragsnr.xml wird nach auftragsnr.old umbenannt bei gebucht (ca.4 Tage) / bleibt auftragsnr.xml wenn es ein Problem gab -> (verschieben nach Ordnerhierarchie...)
Win XP SP3
LG Tobias
ich habe ein kleineres Problem.
Unsere Buchhaltung hat über lange Zeit Unmengen XML Dateien, die zu den Buchungen gehören, gesammelt.
Da wir einen Haufen Kunden am Tag haben, beläuft sich die Anzahl der XML Dateien momentan auf 25.798 Stück in einem Ordner! (Läd mächtig lange...)
Täglich kommen ca. 100 - 120 Kunden dazu.
Da die Buchhaltung es bis jetzt vernachlässigt hat die XML Dateien in Ordner aufzuteilen die sich an dem Beispiel 2008-07-26 ausrichten möchte ich dies nun per Batch nachholen. Leider bin ich mit Batch Dateien nicht so grün und komme meist über ein NET USE und SHUTDOWN nicht hinaus.
Am liebsten würde ich die XML Dateien wie das Datum ihres Erzeugens in die Ordnerhierarchie verschieben und nachträglich im passenden Ordner per Winrar packen.
(2008-07-26 -> 2008-07-26.rar)
Leider fehlt mir der Ansatzpunkt um dies zu automatisieren.
Ich nutze zwar innig den Totalcommander aber dieser ist mir in dem Fall auch keine Hilfe…
Vielleicht hat jemand eine Idee wie ich dies langfristig automatisieren kann.
INFO:
Shopprogram -> auftragsnr.xml Datei -> Buchungsprogramm -> auftragsnr.xml wird nach auftragsnr.old umbenannt bei gebucht (ca.4 Tage) / bleibt auftragsnr.xml wenn es ein Problem gab -> (verschieben nach Ordnerhierarchie...)
Win XP SP3
LG Tobias
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93171
Url: https://administrator.de/forum/ganz-viele-dateien-per-batch-aufteilen-oder-und-einpacken-93171.html
Ausgedruckt am: 14.04.2025 um 16:04 Uhr
5 Kommentare
Neuester Kommentar
Die Suchfunktion beißt nicht, sie geht auch nicht kaputt, wenn man sie benutzt. 
Moin photographix,
ich denke, wir sollten noch einen Moment bei der Konzeption verweilen, denn ... hmm, ich sach mal, auch gute Pläne lassen sich ja optimieren.
Rückfragen:
Denn ich fürchte, wenn Deine BuchhalterInnen irgendwann mal den Auftrag 47110815.xml benötigen und dann ein paar *.rar-Dateien durchscannen sollen in 50 verschiedenen Tagesordnern des ersten Quartals ("...der Auftrag ist schon ein paar Tage her.." = typische vollqualifizierende Kundennachfrage am Telefon).... dann kannst Du Deine Hoffnungen auf eine Einladung zur nächsten Weihnachtsfeier begraben.
Grüße
Biber
ich denke, wir sollten noch einen Moment bei der Konzeption verweilen, denn ... hmm, ich sach mal, auch gute Pläne lassen sich ja optimieren.
Rückfragen:
- was ist denn Kriterium für das Shop-Programm, welche *.xml-Dateien noch benötigt werden?
- Oder ist es so gemeint, dass die *.xml-Dateien nur zusätzlich als "allgemein verarbeitbare papierlose Auftragskopien" erzeugt werden, ohne dass das Shopprogramm die selbst braucht??
- hast Du denn mit der Buchhaltung gesprochen, wie die denn beim alltäglichen Arbeiten in Zukunft (okay, heute nicht mehr mitgerechnet) arbeiten werden? Wohin die also speichern (können) ohne Verrenkungen?
- außerdem drängt sich mir die Frage auf: Wenn Du dieses ganze Gelumpe eigentlich nur aus dem Weg räumen willst - das Programm braucht die *.xml-Dateien nicht, die Buchhaltung auch nicht und Du schon gar nicht.. wozu dann in "Tagesordner" wegsortieren? Reichen dann nicht eher ein Ordner "2006", ein Ordner "2007" und für das aktuelle Jahr ein paar Monatsordner "2008-xx"?
Denn ich fürchte, wenn Deine BuchhalterInnen irgendwann mal den Auftrag 47110815.xml benötigen und dann ein paar *.rar-Dateien durchscannen sollen in 50 verschiedenen Tagesordnern des ersten Quartals ("...der Auftrag ist schon ein paar Tage her.." = typische vollqualifizierende Kundennachfrage am Telefon).... dann kannst Du Deine Hoffnungen auf eine Einladung zur nächsten Weihnachtsfeier begraben.
Grüße
Biber
Hiho und guten Abend,
die XML Dateien werden eigentlich nur bis zum Punkt der Umbenennung gebraucht.
Konkret wird aus dem Shopprogram (Ordermanager) eine XML mit den ganzen Kundendaten inkl. der Bankdaten exportiert.
Diese werden dann von einem weiteren Program geparst und in eine DTAU verständliche Sprache gebracht (SFIRM Banking).
Dannach werden Sie nach .old umbenannt und liegen gelassen. An diesem Status kann man sehen das die Parsung / Buchung funktionierte.
Wenn der Parser keine Bankdaten findet bzw. falsche wird die Datei so belassen.
Ich will nun einfach die XML und OLD Dateien sinnvoll archivieren um im Problemfall, wenn auch mühseelig noch an die Daten zukommen.
Da ich noch ziemlich neu in der Firma bin mache ich mir halt noch ein paar Gedanken um den Ablauf intern und die Reste von meinen Vorgängern...
die XML Dateien werden eigentlich nur bis zum Punkt der Umbenennung gebraucht.
Konkret wird aus dem Shopprogram (Ordermanager) eine XML mit den ganzen Kundendaten inkl. der Bankdaten exportiert.
Diese werden dann von einem weiteren Program geparst und in eine DTAU verständliche Sprache gebracht (SFIRM Banking).
Dannach werden Sie nach .old umbenannt und liegen gelassen. An diesem Status kann man sehen das die Parsung / Buchung funktionierte.
Wenn der Parser keine Bankdaten findet bzw. falsche wird die Datei so belassen.
Ich will nun einfach die XML und OLD Dateien sinnvoll archivieren um im Problemfall, wenn auch mühseelig noch an die Daten zukommen.
Da ich noch ziemlich neu in der Firma bin mache ich mir halt noch ein paar Gedanken um den Ablauf intern und die Reste von meinen Vorgängern...
Moin photograhix,
Und mit hochgezogenen Augenbrauen.
Wenn überhaupt.
Ich formuliere es mal anders: Gibt es einen Fall, in dem das Parsen und das nachfolgende Programm "erfolgreich" waren, aber dennoch die XML-Datei a) vom Shopprogramm oder b) vom Menschen vor diesem Rechner benötigt wird?
Was früher die Angst vor Dunkelheit, Vampiren und einem Alien-Angriff war hat heute meistens eine Aufschrift "Komplettsicherung 2001-2007"..
Zum "an-die-Daten-kommen-wollen":
Auch Leute, die nicht mehr so neu sind machen sich manchmal darum Gedanken...
Grüße
Biber
die XML Dateien werden eigentlich nur bis zum Punkt der Umbenennung gebraucht.
Das Wort "eigentlich" hat im Zusammenhang mit Programmlogik, Strukturen und Arbeitsprozessen eine bei Insidern sehr spezielle Bedeutung und wird daher -wenn überhaupt- nur kursiv geschrieben.Und mit hochgezogenen Augenbrauen.
Wenn überhaupt.
Ich formuliere es mal anders: Gibt es einen Fall, in dem das Parsen und das nachfolgende Programm "erfolgreich" waren, aber dennoch die XML-Datei a) vom Shopprogramm oder b) vom Menschen vor diesem Rechner benötigt wird?
Wenn der Parser keine Bankdaten findet bzw. falsche wird die Datei so belassen.
Bis Weihnachten? Für immer? Setzt ein manueller Prozess ein? Woran erkennt man/frau/Programm "offene"/nicht verbuchbare XML-Dateien? Wie unterscheiden die sich von XML-Dateien, die nur "noch nicht" verbucht sind?Ich will nun einfach die XML und OLD Dateien ...
Wieso "die XML und OLD Dateien"?? Die OLD-Dateien verstehe ich ja......sinnvoll archivieren
Jepp, wobei ich nochmal nach der Sinnhaftigkeit der "tageweisen Sicherungsordner" frage. Wieso nicht ein Ordner pro Jahr oder auch ein Ordner "Erledigt" und ein Ordner "Zu klären" ?um im Problemfall, wenn auch mühseelig noch an die Daten zukommen.
Na ja, das wiederum ist bei allen, die Daten verwalten, eine der Ur-Ängste.Was früher die Angst vor Dunkelheit, Vampiren und einem Alien-Angriff war hat heute meistens eine Aufschrift "Komplettsicherung 2001-2007"..
Zum "an-die-Daten-kommen-wollen":
- Wer könnte diesen Bedarf haben - der Buchhaltungs-Mensch bei teleonischer Kundenanfrage oder nur gegebenenfalls ein misstrauischer Steuerprüfer eher einmal in fünf Jahren?
- Brauchst Du die Daten eher griffbereit vor Ort - schnell auf dem Monitor oder soll es eine "nicht-manipulierbare" Sicherung sein? oder brauchst du beides?
- wenn Du die Daten wiederfinden willst, dann musst Du eben auch verwalten, d.h. nach heutiger Planung mindestens einen Bezug zwischen der "<AuftragsNr>.OLD" und dem Namen des Sicherungsordners/oder dem Rar-Archiv LESBAR abspeichern und pflegen beim Sichern.
Da ich noch ziemlich neu in der Firma bin mache ich mir halt noch ein paar Gedanken um den Ablauf intern
Na, ich bin da ja nicht so empfindlich, aber <räusper>:Auch Leute, die nicht mehr so neu sind machen sich manchmal darum Gedanken...
und die Reste von meinen Vorgängern...
Die Reste meiner Vorgänger... schön gesagt. Kennst du Hannibal Lector?Grüße
Biber
nun ganz ehrlich. Wenn alles glatt läuft brauche ich die XMLs nicht. Ich möchte Sie aber auch nicht löschen. Wir haben leider keine Kundendatenbank vielleicht habe ich später mal die Muse und finde eine XML -> MySQL Lösung die vieles vereinfachen würde. Aber das ist jetzt nicht das Thema. Ihh möchte halt sinnvoll archivieren.
Die Datei wird so belassen bis jemand sich erbarmt (zB.: Ich) und diese in ein anderes Verzeichnis verschiebt. Ich bin einfach der Meinung das man Kundenbezogene Sachen vorallem wenn Sie nicht funktioniert haben - irgendwo sichern sollte.
Die nicht funktionierten XML Dateien möchte ich auch behalten (Der Sammler Trieb...)
Sinnvoll fand ich die Tagesweise Sicherung. So kann ich auch sehen wieviel Kunden wir pro Tag hatten.
Ich würde die XML Dateien später gern nachträglich in eine Datenbank einlesen und eventuell weiterverwenden.
Das Problem mit den Resten mein Vorgänger ist leider ein Buch mit sieben Siegeln. keinerlei Unterlagen oder Beschreibungen.
Die Firma in der ich arbeite hatte nie einen Admin sondern nur einen Mitarbeiter der ab und an mal was an den Rechnern gemacht hat. Danach war er wieder in anderen Bereichen tätig. So laufe ich aktuell auch. MIr stehen nur 10 Stunden in der Woche für PC und Netzwerkprobleme zu, danach bin ich wieder in anderen Bereichen tätig. Langfristig wird sich das aber ändern (sagte man mir zu...) und daher möchte ich all die kleinen Frickelarbeiten modernisieren, abschaffen oder ersetzen und dokumentieren.
LG
Die Datei wird so belassen bis jemand sich erbarmt (zB.: Ich) und diese in ein anderes Verzeichnis verschiebt. Ich bin einfach der Meinung das man Kundenbezogene Sachen vorallem wenn Sie nicht funktioniert haben - irgendwo sichern sollte.
Die nicht funktionierten XML Dateien möchte ich auch behalten (Der Sammler Trieb...)
Sinnvoll fand ich die Tagesweise Sicherung. So kann ich auch sehen wieviel Kunden wir pro Tag hatten.
Ich würde die XML Dateien später gern nachträglich in eine Datenbank einlesen und eventuell weiterverwenden.
Das Problem mit den Resten mein Vorgänger ist leider ein Buch mit sieben Siegeln. keinerlei Unterlagen oder Beschreibungen.
Die Firma in der ich arbeite hatte nie einen Admin sondern nur einen Mitarbeiter der ab und an mal was an den Rechnern gemacht hat. Danach war er wieder in anderen Bereichen tätig. So laufe ich aktuell auch. MIr stehen nur 10 Stunden in der Woche für PC und Netzwerkprobleme zu, danach bin ich wieder in anderen Bereichen tätig. Langfristig wird sich das aber ändern (sagte man mir zu...) und daher möchte ich all die kleinen Frickelarbeiten modernisieren, abschaffen oder ersetzen und dokumentieren.
LG
