Danke 🙂 den habe ich in Zwischenzeit jetzt auch gefunden.. Habe sicher in Summe gut über eine Stunde gesucht 😞 ... Mehr anzeigen

Daten in DATEV DMS abzulegen bzw. ein- und auszulesen per API klappt wohl mittlerweile, weil auch DRACOON und myDATEV senden auf dieser Schnittstelle basieren. Fragt sich dann, wie man dem REWE und den Buchungen automatisiert klar machen kann, dass der Beleg dazu in DMS liegt. Dazu braucht es ja einen Beleglink an der Buchung, die aktuell BEDI bei DUO lautet oder DDMA bei DMS (soweit ich weiß).    Und dieser Beleglink / GUID kommt ja nicht aus der Bankingsoftware, oder?  Ist an sich nicht so das Problem. Man läd den Beleg per DATEVConnect REST-API in DMS hoch (die b.t.w. für die on-premise Installation im Monat zusätzlich kostet und nicht einfach dabei ist), dabei bekommt man die GUID / sagt dem DMS eh in welchem Mandant und Bereich der Beleg im DMS abgelegt werden. Die Antwort der API auf den Upload ist die GUID.   Über die REWE API kann man dann einen "Buchungsstapel" erzeugen und dort an einzelne "Buchungssätze"?! (ich bin komplett Fachfremd was Steuern angeht) einen Dokumentenlink setzen. Der Dokumentenlink ist die GUID im DMS.   Möchte man das nicht über API machen, kann man auch direkt die .NET Komponenten direkt instanzieren, aber da begibt man sich dann auf nicht sehr stabiles undokummentiertes Terrain. Das Tool "ISWL Rechimport" macht das ja auch so z.B.   Am Ende sind es nur ein paar Datenbankeinträge im SQL Server, selbst die Dokumente selbst liegen als binary Payload im SQL Server in einer Tabelle.. ... Mehr anzeigen

Was den Durchsatz an SQL Server anfragen angeht:   Ohne Gewähr (mag DATEV glaub auch nicht): - Microsoft Sql server management studio installieren (kostenlos) - VM Snapshot erstellen zur Sicherheit😅 - Sich selbst Adminrechte im SQL Server geben (im SQL Server im Singleuser mode starten und sich einfach einen Account anlegen + wieder normal starten). - Lang laufende Abfragen im Management Studio anschauen und nachvollziehen was da gemacht wird / warum da GB weise Daten übertragen werden.     DMS speichert die Dokumente selbst im SQL Server, als ich dass das erste mal gesehen habe, fand ich es etwas schräg, ich kenne das eher, dass lediglich die Metadaten im RDBMS gespeichert werden und die "Payloads" irgendwo im Dateisystem oder in einem Blobstore wie S3.. Ob eine klassische RDBMS wie SQL Server für ein Dokumentenmanagementsystem die beste Lösung ist, kann man auch in Frage stellen, warum nicht irgend eine NoSQL Datenbank + Elasticsearch o.Ä. ... Mehr anzeigen

Es ist wichtig rauszufinden, was da genau so lange "hängt"..   Wenn es mein System wäre, würde ich mal mit so Tools wie "Process Monitor" bei dem Prozess der so langsam ist, die ganzen Dateisystemzugriffe und Registry / Netzwerkzugriffe aufzeichnen für ein paar Sekunden. Einmal wenn es sich "schnell" anfühlt und einmal wenn es sich "langsam" anfühlt.   Meisten sieht man dann in den aufgezeichneten Events die Aktionen die das Programm ausbremsen / auf die lange gewartet wird. Damit kann man dann relativ gut eingrenzen auf was da gewartet wird.     Falls man damit nicht weiterkommt, kann man auch die großen Kanonen wie "dotnet trace" u.s.w. auspacken, da DATEV ja größtenteils in .NET entwickelt ist. Damit lässt sich jeder einzelne Funktionsaufruf innerhalb der Software mitschneiden und mit Tools visuell auswerten. Das ist auch das Tool welches Entwickler von .NET Software zur Performanceanalyse verwenden.   Der Vorteil, wenn man einen "gut"/"schlecht" Trace hat, kann man vermutlich sehr gut sehen, was das Problem ist.. Da genau dieser Funktionsaufruf dann vermutlich gut hervorsticht. ... Mehr anzeigen

Ja stimmt, die McAfee UI gibt´s immernoch liegt in:   C:\Program Files (x86)\McAfee\Endpoint Security\Endpoint Security Platform\MFEConsole.exe   dort können die Auschlüsse von Hand bearbeitet werden.   Ich denke bei Datenbankfiles dürfte ein Virenscanner kaum einen unterschied machen, der scannt die Datei nur einmal beim initialen öffnen und danach nicht mehr, außer die Definitionen werden aktualisiert und die Datei erneut geöffnet. Ansonsten würde ich einfach den DATEV Installationspfad auschließen, da hier viele kleine Dateien beim Start von den Programmen geladen werden und das traditional langsam ist... ... Mehr anzeigen

Einfach mal auf dem lokalen Rechner überprüfen ob:   - Die DNS Auflösung geht mit "ping sipgate.de" - Die Verbindung übers VPN geleitet wird oder lokal, indem man sich die Routingtabelle ausgeben lässt mit "route PRINT"   Die route mit der niedrigsten Metrik gewinnt.     Falls DNS das Problem sein sollte, sollte Datev Smart IT das reparieren, indem Sie auch auflösungen von externen DNS Einträgen zulässt. Alternativ eigenen DNS Server betreiben, der "Split-DNS" macht und die Clients dazu zwingen diesen zu verwenden.   Vermutlich gibt es in "Smart IT" irgendwelche Namen, die nicht öffentlich auflösbar sind (z.B. name des RDP Servers). Deswegen haben Sie den VPN Client so konfiguriert, dass die Namensauflösung auf den Clients immer über deren Ihre Server läuft.  ... Mehr anzeigen

In 3.2 geht es um AV-Software von Drittanbietern. DATEV scheint ja irgendwie Ihre eigene UI um McAffee gebaut zu haben, die praktisch keinerlei Zugriff auf Einstellunfen zulässt.   Ich würde einfach mal schauen, wo McAfee seine Außnahmen speichert und das an der gleichen Stelle anpassen. Vielleicht sind es ja nur ein paar Registry keys. ... Mehr anzeigen

Und vergessen: "Scan to DMS" wird das ganze natürlich dadurch, dass halt verschiedene Scanner die gescannten Dokumente in den beobachteten Ordern ablegen. ... Mehr anzeigen

Magnetspeicher? Viel zu modern!   Delay-line Memory ist das Ding welches man braucht. - Kein random access (modernes Zeug was Niemand braucht) - Entschleunigung, da man auf seine Daten warten muss - Daten sind weg, oder man erzeugt schöne neue, wenn man mal ordentlich gegen das Gehäuse schlägt. - Man kann die Daten fühlen, wenn man an den Draht greift (oder die Glasröhre mit dem Quecksilber)   Danach wurde es doch nicht besser, mit diesen 1-Bit Flipflops aus Vakuum-Röhren die so groß wie ein Ziegelstein waren. ... Mehr anzeigen

a) "Dateien" sind auch nur Blöcke auf einem Device mit ein paar Metadaten außenrum.. Meistens sogar zusammenhängende Bereiche.. Datenbanken schauen nicht jedes mal nach der file u.s.w. sondern "mappen" die Datei einmal beim starten per memmory mapped i/o typischerweise. Memory Mapped I/O mapped eine Datei z.B. in den virtuellen Adressraum des Prozesses der die Datei mapped. Der Zugriff ist dann ein Speicherzugriff, erst das Betriebsystem kann dann relativ effizient (je nachdem was der Treiber / Blocklayer unterstützt) auf das physikalische Gerät schreiben.   b) Ja die "Umwege" sind da, am Ende sind das aber alles nur lookups die auf Metadaten im RAM passieren und es wird nur der Block auf dem tatsächlichen Speichergerät angefasst der auch betroffen ist. Das kann gut sein, dass bei den ersten paar Dateizugriffen diese Metadaten erst ins RAM geladen werden müssen, aber wenn Sie mal da sind geht das unglaublich schnell, da ein Schreibzugriff auf ein I/O Geräte (jedenfalls mit klassischen Adaptern wie SATA) Magnituden langsamer ist wie die CPU.. Bei NVMe über PCIe liegen immernoch welten zwischen Memoryzugriff und NVMe über PCIe.   Async I/O Moderne Speichergeräte sind zudem Multi-Queue fähig, sprich das Betriebsystem kann teilweise bis zu 128 lese und Schreibzugriffe gleichzeitig "in der Schwebe" haben.. Das ist besonders interessant, da man hierüber bessere parallelisierung über CPU Kerne hinweg erreicht.. Moderne Hypervisor verwenden zudem recht effiziente APIs um diese Zugriffe asynchron abzusetzen.. Proxmox mit KVM verwendet in den neueren Versionen io_uring, was komplett asynchron ist.   Physikalisches Gerät direkt in die VM "mappen" Würde ich nicht machen, da man damit die Vorteile der Virtualisierung verliert, da Resourcen hart einzelnen VMs zugeordnet werden und weder einfach zu skalieren sind noch backups durchzuführen.   Man möchte ja so etwas haben wie Snapshots der Laufwerke um z.B. online-backup durchzuführen. Das selbe mit dem RAM der VM. Ein moderner Hypervisor hält die VM nur wenige uS an um einen Snapshot der Blockdevices zu erzeugen und auf alle memory pages ein "trap" zu setzen, wenn die VM darauf schreibt. Danach wird erst eine Kopie dieser konsistenten Snapshots erzeugt und als Backup weggespeichert. Das würde so nicht funktionieren, wenn da nicht nochmal eine Ebene dazwischen ist. Zudem wird da auch sowas wie eine "dirty bitmap" gepflegt in der sich gemerkt wird welche Blöcke von der VM überhaupt seit dem letzten Backup geschrieben wurden, dadurch sind inkrementelle Backups um welten schneller, da nur Blöcke kopiert werden müssen die auch zugegriffen wurden.   Thin-Provisioning ist ja auch ein Thema, wenn man es "hart" mapped, wäre immer direkt alles belegt was der VM zugewiesen ist an Speicherplatz. Das die Festplatten in der Hardware stecken auf der der Hypervisor läuft ist zwar verbreitet aber auch nicht zwingend erforderlich / nicht optimal. Storage Virtualisierung ist ja auch ein Thema, warum nicht einen großen redundanten Blockstorage der zwei "Controller" hat und somit ausfallsicher ist? Dieser wird dann per 10/100GBit Ethernet redudant über Kreuz an die Hypervisor angebunden (im "Enterprise" Umfeld benutzt man da auch gerne FibreChannel). Vorteil: Ausfallsicherheit.. Alle Hypervisor Server können jede VM starten, Live Migration erfordert kein migrieren des Storage, da ja beide Server Zugriff auf den gemeinsamen Storage haben. Die einzelnen Storage Arrays kann man per "NVMe over Fabrics" an die Storage Controller anbinden (falls man NVME verwendet). Möchte man keine komplette eigene Storage Infrastruktur kann man auch mit bestehenden Hypervisorn mit eingebauten Platten Hochverfügbarkeit erreichen und zwar über DRBD, da werden praktisch die Schreibzugriffe auf Blockdevice Ebene über Netzwerk zwischen den beiden Kisten hin und her synchronisiert. Fällt einer der Knoten aus, kann der andere Knoten die VMs einfach automatisiert bei sich starten und nach ein paar Sekunden ist man wieder "online".   Würde ich eine größere Virtualisierungsinfrastruktur aufbauen, würde ich vermutlich aber zu einem CEPH Cluster greifen. -> Das ist auch was die Hyperscaler tun, mit ihrer eigenen Implementierung so eines Clusters. Bei unserer Installation verwende ich ZFS im raidz2, für VM Blockdevices werden hier zvols verwenden, sprich keine Dateien. ZFS ist sehr flexibel und hat eine relativ ausgefeilte Caching infrastruktur lesend wie schreibend. Man kann z.B. eine SSD oder ein Optane Drive als Lesecache verwenden (L2ARC) und ein ein pärchen von zwei schnellen Optane Laufwerken als Schreibcache (ZIL).. Lesezugriffe der VMs gehen dann erst an den RAMcache, dann den SSD-Cache und erst wenn es in beiden nicht gefunden wird auf die evtl. langsamen Platten. Schreibzugriffe sind wie auf SSD schreiben, da sobald Sie im ZIL stehen (SSD Schreibcache) kriegt die VM das "ok" zurück. Ich habe mal einen Hypervisor mit 5400 rpm SMR Festplatten und Optane Caches gebaut.. Es fühlt sich so an, als würde man auf einer SSD schaffen, da einfach 99% der Blöcke die die VM zugreift im Cache liegen. Das "workingset" an Daten ist meist relativ klein.. 80-90% der Sachen die da rumliegen werden nahezu nie gelesen bei typischen Windows VMs. ZFS schützt zudem gegen "Bitrot" durch Checksumen.. Bei normalen Festplatten und SSDs können Bits "kippen" bei den heutigen Größen der Laufwerke liegt das durchaus im Bereich des möglichen, bei einem klassischen RAID1 weiß man im Zweifel nicht welche der beiden Kopien die richtige ist, wenn ein Bit kippt. Heute macht man eh nur noch "Flash-only".. So eine 1,92TB PCIE4 Enterprise SSD kostet gerade mal noch 350€, (Samsung PM9A3), die kann irgendwie 7Gbyte/sec lesen und 5 schreiben oder sowas synchron und schafft knapp eine Million IOPS. Festplatten sind doch eh nur noch für Backup und Archivierungssysteme interessant..   Kurzum: Möchte man nicht die Virtualisierung verlieren vom Storage, sollte man sowas wie ZFS verwenden oder einen dedizierten Storage cluster wie Ceph. Für Hochverfügbarkeit entweder Ceph oder DRBD ansonsten natürlich ein RAID (zfs hat das integriert).   Proxmox Benutze ich selber kann ich sehr empfehlen, denn man kriegt direkt so Sachen wie: - Snapshoting - Live Migration - Inkrementelle Backups - Storage Virtualisierung - Hochverfügbarer Cluster einfach damit zu realisieren und kostenlos dabei - (Debian) Linux basiert - Gute Performance, da breiter Hardware Support und KVM ziemlich schlank / optimiert ist. Die großen Cloudprovider verwenden auch alle KVM (Amazon, Microsoft / Azure, Google, Tencent, Alibaba u.s.w.) Amazon hat er kürzlich dazu gewechselt.   Netzwerk Virtualisierung Das ist heutzutage nicht mehr das Problem, da über IOMMU und Hardwarefähigkeiten in der Netzwerkkarte. Die Netzwerkkarte wird vom Hypervisor so konfiguriert, dass Sie Pakete an bestimmte MAC-Adressen direkt per DMA in einen Speicherbereich ohne Beteiligung des Hauptprozessor schreibt. Die VM kriegt diesen Speicherbereich einfach in ihren reingemapped und kann direkt daraus lesen. Sprich der "Hypervisor" hat die Daten nie in der Hand.. Der liest nur irgendwelche Counter aus der Netzwerkkarte aus um zu sehen wie viele Pakete wer transportiert hat für die Statistik.   Es gibt sogar Anwendungen bei denen RAM-Zugriffe auf entferne Maschinen ohne Betriebsystembeteiligung stattfinden können.. RoCE (RDMA over Converged Ethernet). Der Overhead für die Netzwerkvirtualisierung ist minimal, vor allem im Vergleich zu den Laufzeiten die man auf dem physikalischen Medium hat. Gerade "bessere" Netzwerkkarten können viel davon auch in Hardware abbilden, deswegen kostet halt so ne Karte auch 200-300€ stattt halt nur 5 wie die Realtek bei Aliexpress, deren Chip nichtmal TCP Offloading kann (berechnen der TCP Checksummen in Hardware).     Open Source Dank OpenSource Software und der Beteiligung der großen Hyperscaler, kann man heutzutage für um die 10-15k€ Hardware kaufen und kostenlose Software verwenden um einen Hoch verfügbaren Virtualisierungscluster zu bauen. Ich finde man kann sich nicht beklagen. Würde man das mit Enterprise Hardware / Software machen, also z.B. mit VMWare und den ganzen modulen die man für die Hochverfügbarkeit braucht + einem Storage Array, ist man eher bei 100k€+ denke ich.. ... Mehr anzeigen

Also es muss ja eine API geben / ich sehe die COM Objekte auch. Wie sollte sonst auch die bestehende Integration funktionieren. COM Objekte sind ja auch ne API, wenn auch keine schöne.   Die aktuelle 3CX Integration hat halt ein paar Probleme, deswegen wurde Sie ja scheinbar auch vom Datev Marktplatz genommen.   Meine Frage ist halt, wer für sowas Ansprechpartner bei DATEV ist / wie man da an Informationen kommt. Es gibt ja sicher auch irgend ein Dokument welches beschreibt, wie sich die Integration zu verhalten hat / was erfüllt sein muss damit Sie z.B. auf dem Marktplatz akzeptiert ist.   Die anderen Telefonieanbieter wie Pascom, werden ja sicher nicht mit Decompiler und ausprobieren Ihre Integration gebaut haben. ... Mehr anzeigen

Die C++ Redistributables in Windows sind abwärtskompatibel seit VS 2015 (Toolset v140): https://docs.microsoft.com/de-de/cpp/porting/binary-compat-2015-2017?view=msvc-170#upgrade-the-microsoft-visual-c-redistributable-from-visual-studio-2015-and-later   Es sollte also ohne weiteres möglich sein immer die neuste Version zu verwenden. Anders herum gillt das nicht, neuere Anwendungen funktionieren nicht mit den älteren C++ Redistributables. Neuere C++ Redistributables enthalten zudem Sicherheitspatches und Fehlerbehebungen die in älteren evtl. noch nicht vorhanden sind.   ... Mehr anzeigen

@metalposaunist  schrieb:   MT940 ist zu 2025 abgekündigt und DATEV steckt aktuell alle Energie in die neue Cloud-Lösung. Da wird man am REWE nicht mehr rütteln. Man wird gesetzliche Änderungen Einpflegen aber mehr im Großen und Ganzen auch nicht.  Ja gut, das ist natürlich schade, dass Sie so einen kleinen Fix dann nicht mehr mit übernehmen, zumal Rewe ja die IBAN eh schon kennt und keine "Umrechnung" nötig wäre. Da ich nur wenige Buchungen habe und kein Geld für Duo monatlich zahlen möchte, ist der Import per MT940 oder gerne auch nem anderen Format für mich die beste Lösung aktuell. Meine Bank erlaubt es mir schon Dokumente und Metadaten mit den Buchungen im Konto zu verknüpfen und die auch wieder per API abzufragen. Aktuell haben wir noch kein DMS, aber sobald wir das haben, ist mein Plan eh ein kleines "syncscript" zu schreiben, welches automatisch monatlich die Daten aus der API inklusive Belegen und Metadaten importiert und dann per Datev API in REWE / Datev DMS bringt. Hach ja XaaS, es muss ja jetzt alles in die Wolke. ... Mehr anzeigen