Dokumente exportieren wegen Kanzleiauflösung

[#1]

@vogtsburger , sie vertrauen dem Datenverarbeiter nicht Ihre Daten an (die Daten liegen ja bei Ihnen vor Ort) also haben Sie vor Nutzung der Software die Möglichkeit, abzuwägen, was denn im Falle des Falles mit den Daten passieren könnte.

Die Dokumentenverwaltung erledigt doch ihren Zweck. Wenn man diese Daten dann eben im Explorer (was ja nicht empfohlen wird, so @Anton_Friesen ) nutzenmöchte (autark von der genutzten Software), dann muss man eben in den sauren Apfel beißen, Zeit investieren und sich das zurechtbasteln.

Warum sollte sich DATEV darum auch nur ansatzweise kümmern? DATEV hat dafür zu sorgen, dass die Ziele des Einsatzes der Dokumentenverwaltung eingehalten werden. Mehr nicht.

Vielleicht finden Sie ja einen Softwaredienstleister, der für Sie die Daten aus der Dokumentenverwaltungssoftware so rausholt, wie sie das dann wollen.  Auf Ihre Kosten.

Oder, @Der_Busfahrer ?

[#2]

---

@mic  schrieb:

Weil die DSGVO auch die Datenweitergabe an andere Systeme vorsieht, wenn man zB die Softwarelösung wechseln möchte.

---

Es steht dem Fremdanbieter frei, die bestehenden exportierten Daten ähnlich wie @vogtsburger zu analysieren und dann einen entsprechenden Import in seiner Software zu bauen. 

Wenn es eine XML-Datei mit den Dateiverweisen zu den exportieren Dokumenten gibt, dann sollte das $Programmierer bzw. $Entwickler hinbekommen. 

Also: Warum sollte DATEV hier noch Zeit und Energie investieren, wenn es bereits einen Export inkl. Beschreibungs-XML gibt?

Beste Grüße
Christian Ockenfels

[#3]

Ich sehe in solchen EXIT- und Migrations-Barrieren ein (vermutlich beabsichtigtes) "Vendor-Lock-In" des Software-Herstellers.

"Grundsteuer-Digital" arbeitet anscheinend auch nach dem selben Prinzip.

Die Unmengen an Daten, die man hineingesteckt hat, kann man nur unvollständig, unzusammenhängend und nur mit großem Aufwand wieder aus diesem 'Schwarzen Loch' "Grundsteuer-Digital" herausoperieren

Fazit:

Eigentlich sollte man von Anfang an eine Business Continuity-Strategie verfolgen und nur Produkte akzeptieren, die vollständige Backups der Daten in einem Standardformat zulassen.

Das Dumme ist bloß, dass das Vendor-Lock-In auf der Software-Hersteller-Seite sehr beliebt und weit verbreitet ist.

Wenn man Alternativen hat, sollte man um solche Produkte und Anbieter einen großen Bogen machen

[#4]

---

@chrisocki  schrieb:

---

@mic  schrieb:

---

Es steht dem Fremdanbieter frei, die bestehenden exportierten Daten ähnlich wie @vogtsburger zu analysieren und dann einen entsprechenden Import in seiner Software zu bauen. 

Wenn es eine XML-Datei mit den Dateiverweisen zu den exportieren Dokumenten gibt, dann sollte das $Programmierer bzw. $Entwickler hinbekommen. 

Also: Warum sollte DATEV hier noch Zeit und Energie investieren, wenn es bereits einen Export inkl. Beschreibungs-XML gibt?

[...]

natürlich kann man das hinbekommen, wenn man genügend 'Scheine' investiert,

aber ist das Sinn der Sache, dass man beim EXIT aus einem Vertrag bzw. aus der Umklammerung eines Software-Anbieters eine Individualsoftware programmieren soll, um die eigenen Daten in ein weiter benutzbares Standardformat zu bringen ?

Bei mir war es schon von jeher ein wichtiges Kauf-Kriterium, dass die Software mit einem Standardformat arbeitet oder wenigstens einen Export in ein Standardformat anbietet.

Bei der Datev-Software funktioniert das leider nur sehr unvollständig.

Buchungsstapel aus REWE lassen sich z.B. im Datev-Format (CSV) exportieren, weiterverarbeiten und woanders importieren.

Bei einigen anderen Datev-Programmen gibt es aber keine 'normale' Exportmöglichkeit.

Was den Export aus der "Dokumentenablage" betrifft, bin ich mit dem ersten Schritt, der Erstellung der gewünschten Anzahl von Dateien zufrieden. Die Performance ist meiner Meinung nach sehr gut

Allerdings erhält man dann, je nach der gewünschten Anzahl der Dokumente (maximal 20.000)  eine kleine bis riesige Sammlung von Einzeldateien ("Dokumentensammlung") mit kryptischen Dateinamen (GUIDs) und zwei Dateien im XML- und im HTML-Format.

Die XML-Datei ist nur für den Re-Import in eine andere Datev-Umgebung gedacht und die HTML-Datei ist nur ein völlig unstrukturiertes und unsortiertes 'Inhaltsverzeichnis' der "Dokumentensammlung"

In diesem 'Inhaltsverzeichnis irrt man herum wie in den vielen Gassen von Marrakesch

Sehr schade, dass man es den betroffenen Anwendern so schwer macht.

Es würde schon viel weiterhelfen, wenn anstatt oder zusätzlich zur HTML-Datei eine CSV-Datei generiert würde. Dann könnte man diese CSV-Datei mit Excel oder einem Datenbankprogramm öffnen und nach Herzenslust durchsuchen, sortieren, selektieren, gruppieren, inspizieren etc.

Momentan suche ich noch nach einem "genial einfachen" Trick, wie ich die XML- und/oder die HTML-Datei in ein 'vernünftiges' Format konvertieren kann

("genial einfacher Trick", weil die komplizierten Tricks bei mir auf wenig Verständnis stoßen würden 😎)

[#5]

Hmmm….

was wäre denn ein Standard-Format?

Viele würden behaupten, dass XML ein Standardformat ist. Jedenfalls genauso wie CSV.

MfG, F.Lange

[#6]

@flange ,

... mir geht es jetzt weniger um die Bezeichnung des Formats als um die Weiterverarbeitbarkeit des Datei-Inhalts

Beim CSV-Format reicht ein Doppelklick, um aus 10.000 Textzeilen 10.000 Datensätze zu machen.

Bei 200.000 XML-Textzeilen, in der die Informationen von 10.000 Datensätzen stehen, reicht ein Doppelklick nicht.

... jedenfalls nicht dass ich wüsste

Irgend ein gängiges Datenbank-Format wäre mir genauso lieb wie eine CSV-Datei

Ok, etwas mehr als ein Doppelklick darf es schon sein, aber Daten in einem Standardformat lassen sich jedenfalls direkt mit verschiedenen 'Fremd-Programmen' importieren und weiterverarbeiten.

Proprietäre Formate jedoch, so wie in diesem Fall, sind aber nur für die exklusive Verwendung eines einzigen Produkts oder eines einzigen Software-Herstellers vorgesehen und lassen sich entweder gar nicht oder nur mit  relativ großem Aufwand konvertieren

[#7]

... da ich 'unvollendete Sinfonien' nicht mag, bin ich dem Thema noch ein wenig 'hinterhergehechelt'

Ja, es ist möglich, die XML-Datei in ein Tabellenformat oder Datenbankformat zu konvertieren, also aus ca 200.000 Textzeilen 10.000 Datensätze bzw. Tabellenzeilen zu machen, aber es lohnt sich mMn nicht. 

In der XML-Datei steht nichts Besonderes bzw. nichts Zusätzliches, auf das man nicht locker verzichten könnte (siehe Screenshot)

Dass sich die Feldnamen in der XML- und der HTML-Datei stark unterscheiden, war zu erwarten. 

... egal ... die XML-Datei ist sowieso nicht als Nachlektüre geeignet

index.xml	_inhalt.html	Kommentar/Beispiel
filingLocation/filing/0/_level
filingLocation/filing/0/__text	Bereich	Mandanten
filingLocation/filing/1/_level
filingLocation/filing/1/_number	Nummer	12345
filingLocation/filing/1/__text	Name	Mustermann Michael
filingLocation/filing/2/_level
filingLocation/filing/2/__text	Ordner	Private Steuern
filingLocation/filing/3/_level
filingLocation/filing/3/__text	Register	Korrespondenz
id	Dok.-Nr.	98765
description	Beschreibung	Email von Hr. Mustermann bzgl. …...
keywords	Stichworte
creationDate	Abgelegt am mit Uhrzeit	19.10.2022  14:47:56
changeDate	Geändert am mit Uhrzeit (Datei)	19.10.2022 14:42:14
additionalInfo
notes
notesRtf
year	Jahr	2021
documentClass
file/_name	Dateiname	53YYYY18-262C-47E9-AB9E-7FABXXXXA37D.msg
_guid
period/_type	Monat
period/__text	Buchungsinfo

[#8]

Dumme Frage:

Wenn alle Daten auf dem Server verbleiben und ein Client- PC nicht entsorgt wird, dann sollten doch bis zum vielleicht zu verhinderndem Rechteabruf nach der Kündigung alle Daten aufrufbar bleiben. 
Natürlich gibt es weder Updates, noch Jahresübernahmen, aber für den gelegentlichen Zugriff, auch einem Prüfer- Zugriff sollte es doch reichen?

Auch ein Restore des letzten Backups bei aktiver Kanzlei incl. Lizenzmanager muß doch die Lesbarkeit aller Daten widerherstellen, auch dann, wenn alle Lizenzen online zurückgegeben wurden.

Nicht vergessen: Aufbewahrungspflicht der Emails, sonstigen Daten, usw.
Problem: in der Clouds abgelegte ReWe- Belege.

Natürlich ist offline kein produktives Arbeiten möglich, aber Aufbewahrung für 10 Jahre?

Denkfehler? 

[#9]

Müsste vermutlich funktionieren. 

Dann müsste man sich vtl. überlegen ob man nicht einfach die Server Festplatte ausbaut und sie direkt in den Client einbaut. Dann müsste man den Client-Server Zugriff ja fingieren können und mich interessiert das RZ nicht mehr. 

Aber leider sind halt die Belege in UO, die muss ich zurückholen und das geht halt nicht so einfach und daher von 

Datev deutlich schlechter gelöst als von Lexoffice. 

Sollten die Belege vor Ort gehalten werden z.Bsp im DMS oder Dok.ablage taucht die Frage ob der Zugriff nach Jahren ohne updates von dAtev noch funktioniert ? Geht der DAP noch 5 Jahre später ohne updates.  Was haben wir für Windows in 5 Jahren welchen pdf reader ?   

Letztlich müsste man das probieren und Testgerät nicht mehr updaten und mit Belegen bestücken. 

Weil meine Erfahrung wenn dann so ein Client/ Server nach Jahren angestellt wird, erstmal massenhaft updates von Windows und Microsoft und ob das dann die Power des Geräts überfordert ?  Häufig ist auch das Netzteil hatte ich auch schon kaputt, dann repariert und dann hat es die Festplatte erwischt und auch das hatte ich schon ( immer nur bei ausrangierten Rechnern) Mainboard und dann geht erstmal gar nichts mehr. Sprich so wirklich sicher erscheint mir die Lösung beim zweiten drüber nachdenken nicht wirklich. 

[#10]

@martinkolberg , @bodensee ,

rein theoretisch könnte das funktionieren, als Notbehelf für eine rel. kurze Zeit.

... aber man hinge immer noch am Tropf der Datev.

Die Datev hat schon immer einen großen Aufwand betrieben, um die unlizenzierte Nutzung von Anwendungen und Leistungen zu verhindern.

Wie man bei diversen Abkündigungen gesehen hat (z.B. Postversandformat, einzelne Kontenrahmen, Branchenpakete, Telemodul ... und ... und ... und), kann die Datev einfach einen Riegel vorschieben, z.B. einen Stichtag in die Software einprogrammieren, nach dem der Start eines Programms oder einer bestimmten Funktion nicht mehr 'funktioniert'

Auch ein Abgleich mit Systemparametern ist denkbar (z.B. Betriebssystemversion, Systemdatum u.a.)

Mir ist jedenfalls ein Export oder Backup der relevanten Daten in einem Standardformat lieber als das 'Einmotten' einer Datev-Umgebung, mit dem Risiko, jederzeit gegen die Wand fahren zu können.

[#11]

---

@vogtsburger  schrieb:

@martinkolberg , @bodensee ,

rein theoretisch könnte das funktionieren, als Notbehelf für eine rel. kurze Zeit.

... aber man hinge immer noch am Tropf der Datev.

Die Datev hat schon immer einen großen Aufwand betrieben, um die unlizenzierte Nutzung von Anwendungen und Leistungen zu verhindern.

Diese Geräte dürfen für nichts anderes verwendet werden, keinen Internet- Zugriff, keine Updates und vielleicht sogar das Datum "einfrieren", damit die Smartcard als Lizenz Dongle nicht abläuft.

Im Prinzip sollte es jedoch ausreichen, wenn die DFÜ soweit geschrottet wird, daß garantiert keine Kommunikation mit dem RZ stattfindet und ein SWM Mini mit unbegrenzter Haltbarkeit Verwendung findet.

Daß ein produktives Arbeiten mit dieser Konstellation unmöglich ist, versteht sich von selber. Als Archiv sollte es jedoch taugen.

[#12]

Systemuhr wird kritisch. 

[#13]

---

@theo  schrieb:

Systemuhr wird kritisch. 

---

Früher war das unkritisch, bis zu dem Zeitpunkt, wo die SC ablief.
Im Zweifel per Batch das Systemdatum beim Start fest setzen, um Unfälle zu verhindern.

Bislang hält die DATEV- Installation eine versehentlich verkehrt gehende und damit um Jahre zurück gestellte Uhr aus- (bei Bios- Batterie- Reset)

Die Uhr um 3 Jahre vorstellen würd ich mit einer aktiven SC nicht testen.

[#14]

Hallo Herr @vogtsburger,

ich denke, dass wir hier in der Sache nicht zusammen kommen werden. 

1. Natürlich wäre es schön, wenn alle Hersteller von Software auch einen "Export" o.ä. anbieten würden, um hier Daten für die Nachwelt zu exportieren und auf anderen Medien vorzuhalten. 

Haben Sie aber auch schon geschrieben: Realität ist meist eine andere.

2. 

---

natürlich kann man das hinbekommen, wenn man genügend 'Scheine' investiert,

aber ist das Sinn der Sache, dass man beim EXIT aus einem Vertrag bzw. aus der Umklammerung eines Software-Anbieters eine Individualsoftware programmieren soll, um die eigenen Daten in ein weiter benutzbares Standardformat zu bringen ?

---

Wir haben in der Diskussion eigentlich zweierlei Ansätze:

a) Verlassen der DATEV-SW wegen Kanzleiauflösung

b) Verlassen der DATEV-SW wegen Softwarewechsel

zu a) Hier wäre es sehr sehr einfach, wenn DATEV einfach einen lesenden Zugriff zusammen mit einem passenden Viewer zur Verfügung stellt. Meint wegen analog zur Fibu-/Lohn-Archiv-DVD. Aus dieser Anwendung steht es dann einem frei noch PDF's oder Originalformat zu exportieren. 

b) Und hier bin ich weiterhin der Meinung, warum DATEV sich um die Belange der übernehmenden Fremdsoftware kümmern soll... 

Und XML ist ein Standardformat. Unter Entwicklern durchaus beliebter, da die Daten in Strukturen eingearbeitet sind.  --> s.a. auch gern ZUGfERD-Format / X-Rechnung --> dort ist auch eine XML-Datei eingebettet.

3.

---

Buchungsstapel aus REWE lassen sich z.B. im Datev-Format (CSV) exportieren, weiterverarbeiten und woanders importieren.

---

Auch hier hat DATEV primär den Austausch mit den eigenen Anwendungen im Fokus. Nett ist aber, dass dieses Format in der Hilfe oder auch im Developer-Bereich sehr gut dokumentiert ist. Das war, wenn Sie sich erinnern, auch mal anders... --> Postversandformat = DATEV-eigenes-Format

---

Allerdings erhält man dann, je nach der gewünschten Anzahl der Dokumente (maximal 20.000)  eine kleine bis riesige Sammlung von Einzeldateien ("Dokumentensammlung") mit kryptischen Dateinamen (GUIDs) und zwei Dateien im XML- und im HTML-Format.

---

Das sind meines Erachtens Standards um Daten zwischen Anwendungen auszutauschen. 

Mit GUID ist eine Eindeutigkeit geregelt. Und mit XML hat man ein Beschreibungsstandard genutzt. Aus Sicht der DATEV: Alles richtig gemacht.

Aus Ihrer Sicht: Excel kann nicht XML.

Meine Meinung: Excel ist einfach das falsche Tool um ein Datenaustauschformat zu betrachten... 

Beste Grüße
Christian Ockenfels

[#15]

@chrisocki ,

inzwischen kann ich die exportierten Daten 'händeln'.

Sowohl die HTML-Datei als auch die XML-Datei lassen sich in Eigenregie konvertieren.

Mit Bordmitteln oder mit MS-Access könnte ich jetzt auch ohne die Datev-Umgebung an sämtliche Informationen herankommen

Ich selbst lasse mich eben nicht so gerne auf einen Anbieter oder auf ein Produkt und für alle Zeiten festnageln. Zumindest die Möglichkeit eines EXITs muss jederzeit vorhanden sein, selbst wenn man diesen EXIT noch nicht konkret geplant hat 

Apropos:

XML ist bloß eine 'Sprache', kein festgelegtes Format.

Wenn man erstmal einen Dolmetscher braucht, um das 'Gesprochene' in eine allgemein verständliche Sprache zu übersetzen, wird es kompliziert und i.d.R. teuer

... egal ... 

Von einem Software-Hersteller sollte man eben nicht erwarten, dass er seine Kunden freiwillig aus dem 'Karzer' bzw. aus der Abhängigkeit entlässt. 

[#16]

---

@vogtsburger schrieb: 

Von einem Software-Hersteller sollte man eben nicht erwarten, dass er seine Kunden freiwillig aus dem 'Karzer' bzw. aus der Abhängigkeit entlässt. 

---

Aus betriebswirtschaftlichen Gründen: Nein. Denn dann hat der Anbieter / der Vorstand was nicht verstanden. 

Zauberwort: Kundenbindung.

Und das ist nichts Neues und nichts, was DATEV allein macht. Andere Hersteller machen es genauso. Oder gibt es eine Migration von SAP nach Oracle oder Microsoft? Wohl eher nicht. Und ich würde auch davon ausgehen, dass keiner der genannten Anbieter auch nur im Ansatz eine Migration "out of the Box" zu einem anderen Anbieter vorsieht. 

---

Ich selbst lasse mich eben nicht so gerne auf einen Anbieter oder auf ein Produkt und für alle Zeiten festnageln.

---

Dann frage ich mich, warum sich Kanzleien, Betriebe, öffentliche Institutionen, etc. auf M$ derart einlassen und MS Teams, M365 u.s.w. als das Allheilmittel annehmen und schlucken. 

Wenn ich Ihrer Theorie folge, hätte der DATEV-Exkurs zu OpenOffice ein überragender Erfolg werden müssen. 

Oder in Ihren Worten: Sind Sie der sehende Blinde oder der Einäuigige???

---

XML ist bloß eine 'Sprache', kein festgelegtes Format.

---

Punkt für Sie. 

Beste Grüße
Christian Ockenfels