Wir haben viele Online-Händler und es liegt in der Natur der Sache, dass diese viele offene Posten haben.
Die Kollegen beschweren sich immer häufiger, dass sie bei der Bearbeitung dieser Buchhaltungen viel Zeit benötigen, damit Daten überhaupt verarbeitet werden.
Sowohl beim Einspielen der Bankbuchungen als auch bei der Übergabe von aktuellen Offenen Posten kommt es zur Eieruhr, die dann auch gerne mal 3 Stunden oder länger das System blockiert.
Wir sprechen hier von ca. 300.000 offenen Posten - lt. DATEV also noch keinen "größeren" Mandantenbestand (siehe Dokument https://apps.datev.de/help-center/documents/1007556).
Gibt es Kanzleien, die ähnliche Probleme haben?
Naja, ob man den Werten trauen kann? Beim Belegtransfer schreibt DATEV auch: max. 476MB aber man empfiehlt die ZIP Datei kleiner als 100MB zu halten aka 21% sind schon in der Praxis schwierig.
DATEV XML-Schnittstelle online - Ablauf der Rechnungs- und Kassendatenübertragung Punkt 5
Ihr nutzt DATEVasp? Da mal nach den Servern geschaut? Möglich, dass Ihr noch auf technisch alter Hardware im RZ lauft und man DATEV um einen Umzug auf aktuelle, performantere Hardware bitten könnte.
für solche bestände braucht man power, power, power, optimal konfiguriert…
als vergleich kann ich nur buchungen heranziehen.. 800.000 in etwa 10min eingespielt. aber halt ohne den opos-bereich.
Das Einspielen von Buchungsdaten ist kein Problem. Das ist auch schnell erledigt...
Das Problem sind meiner Meinung nach die ganzen offenen Posten. Als Beispiel bei einem Mandanten, es sollen die Bankbuchungen abgerufen werden, die bereits über den Zahlungsverkehr automatisch abgerufen wurden. Auf diesem simplen Bankkonto waren ca. 100 bis 150 Buchungen für den entsprechenden Monat. Aber jede dieser 10-150 Buchung hat er beim aufbereiten mit 300.000 offenen Posten abgeglichen... das Aufbereiten hat länger als 3 Stunden benötigt. In der Kanzlei kommen dann Ideen, einen zweiten Benutzer anzulegen, der nur zum importieren gedacht ist, ich für meinen Teil möchte gerne an die Quelle des "Fehlers" und diesen so gut wie ausschalten.
Also entweder ist die Art diese ganzen offenen Posten (Amazon, etc.) zu buchen Quatsch - wobei ich mir sagen lassen habe, dass dies für Abstimmzwecke NOTWENDIG wäre. Ich bin gerne offen für andere Varianten. Ich als technischer Ansprechpartner hätte gesagt, dass man hier ggf. auf die vorgelagerten Systeme zurückgreifen sollte und im Rahmen der Buchhaltung lediglich die Monats-Verkehrzahlen einzubuchen... aber das scheint ja wie gesagt - zumindest in unserem Hause bis jetzt nicht zu gehen.
Das asp-System ist im November 2021 aufgesetzt worden, wir haben auch bereits den neuen Router im Einsatz, der im vergangenen Jahr ausgetauscht wurde.
@cetze schrieb:
Das asp-System ist im November 2021 aufgesetzt worden
Trotzdem bei DATEV nachfragen oder mal prüfen. Ich meine, hier liefen SmartIT lahmer als nötig bzw. nach DATEV internen Arbeiten schneller als vorher.
@cetze schrieb:
wir haben auch bereits den neuen Router im Einsatz, der im vergangenen Jahr ausgetauscht wurde.
Das ist egal, weil man sich ja nur die Ansicht vom Server aus Nürnberg an den Standort holt und keine Bits & Bytes physikalisch vom Standort nach Nürnberg müssen, was in der Tat dann auf die Bandbreite / den Router ankäme. So spricht nur der Terminalserver mit dem DATEV SQL-Server innerhalb Nürnbergs und kommt da wohl an seine Grenzen.
Ob es FiBu-technisch anders und rechtssicher gehandhabt werden kann, kann ich nicht sagen. Da gibt's andere E-Commerce Experten.
warum sind die posten überhaupt offen?
ausgleich über belegfeld1 findet statt oder wird das einfach plump dagegen gebucht und der posten bleibt offen, saldo aber 0?
es gibt diverse wege sowas zu lösen…. müssen sich halt profis mit auseinandersetzen.. unsere „onliner“ machen wir nicht in jedem fall mit x-tausend opos…