Phil Elred
Mein Feedback
2 gefundene Ergebnisse
-
7,602 Stimmen
Liebe:r Ideengeber:in,
vielen Dank für Ihre Anregung!
Da lexoffice für Buchhaltungslaien entwickelt wurde, bieten wir lediglich einen “schmalen” Kontenrahmen an, der die wichtigsten Geschäftsfälle abdeckt.
Außerdem möchten wir die Buchhaltung für unsere Kund:innen automatisieren und somit den manuellen Buchungsaufwand möglichst gering halten.Die automatisieren Geschäftsvorfälle mit den entsprechenden Konten werden von uns aber schrittweise erweitert.
Viele Grüße
Johanna@lexoffice TeamPhil Elred
unterstützt diese Idee
·
-
16 StimmenPhil Elred
unterstützt diese Idee
·
Beim Speichern des Kommentars ist ein Fehler aufgetreten
Dieser Bug ist seit Juli 2022 dokumentiert — wir haben jetzt Mai 2026.Dieser Bug ist seit Juli 2022 dokumentiert — wir haben jetzt Mai 2026. Knapp vier Jahre.
Ich kann mich den Vorrednern nur anschließen, möchte aber ergänzen, wie weitreichend die Konsequenzen tatsächlich sind. Es geht hier nicht um einen kosmetischen Anzeigefehler, sondern um Datenintegrität in einem Buchhaltungssystem.
Meine konkreten Beobachtungen aus dem laufenden Betrieb (ich arbeite aus UK, also GMT bzw. BST):
-> Buchungsübersicht inkonsistent mit sich selbst: Wähle ich in der Buchungsübersicht Q1/2026 aus, erscheint dort ein Beleg, der korrekt auf den 01.01.2026 datiert ist — aber angezeigt wird das Datum als 31.12.2025. Der Beleg wird also gleichzeitig im richtigen Quartal einsortiert und mit dem falschen Datum angezeigt. Das ist nicht nur verwirrend, das ist schlicht ein Widerspruch innerhalb derselben Ansicht.
-> DATEV-Export liefert falsche Monatslabels. Das ist die rote Linie. Der DATEV-Export ist die Schnittstelle zum Steuerberater bzw. zum Finanzamt. Wenn dort Monatszuordnungen falsch sind, sind UStVA, EÜR, und sämtliche Periodenabschlüsse betroffen. Das ist kein "Edge Case", das ist ein Fehler mit unmittelbaren steuerlichen und potenziell strafrechtlichen Konsequenzen für den Mandanten.
-> Browser-Plugins zum Spoofen der Zeitzone helfen nicht. Offenbar wird die Zeitzone nicht nur über eine einzige API ermittelt, sondern an mehreren Stellen unterschiedlich. Der einzige zuverlässige Workaround ist, die Systemzeit des gesamten Rechners umzustellen — was, wie tsief_fainans_ofisser völlig zu Recht anmerkt, eine absurde Zumutung ist und an anderen Stellen (Kalender, Logfiles, Kommunikation, andere Software) neue Probleme schafft.
Die Antwort des Supports, man möge doch einfach die Systemzeit umstellen, ist für ein professionelles Buchhaltungsprodukt nicht akzeptabel. Lexware Office wird nicht nur von Tagesreisenden genutzt, sondern auch von Selbstständigen mit ständigem Auslandswohnsitz, von remote arbeitenden Teams, und von deutschen Unternehmen mit internationaler Belegschaft. Dass eine deutsche Buchhaltungssoftware die Periodenzuordnung von der lokalen Browser-Zeitzone des bearbeitenden Nutzers abhängig macht, ist konzeptionell falsch — das Belegdatum ist ein Datum, kein Zeitstempel mit Zonenbezug, und die Periodenzuordnung muss deterministisch in Europe/Berlin erfolgen, unabhängig vom Client.
Der Fix ist technisch trivial: Belegdaten als reine Datumswerte ohne Zeitzonen-Konvertierung behandeln, und sämtliche Periodenlogik serverseitig in Europe/Berlin auflösen. Das ist eine Aufgabe von wenigen Personentagen für ein erfahrenes Team.
Bitte priorisieren. Vier Jahre sind genug.