Changelog

v3.3.7 — Export-Historie wieder vollständig

Juli 2026

Bugfix

• Die Liste der erstellten Exporte (und damit auch Download, E-Mail-Versand und Statistik je Zeile) blieb dauerhaft leer, sobald Exporte mit „Belegdokumente mit exportieren“ erstellt wurden. Ursache: Die Liste lud jeden Eintrag inklusive der kompletten, oft mehrere MB großen Export-Datei — über mehrere Zeilen wurde die Antwort zu groß und die Abfrage brach ab. Die Historie lädt jetzt nur noch die Anzeige-Informationen; die Datei selbst wird erst beim Klick auf „Download“ geladen. Die exportierten Daten waren dabei nie betroffen.

v3.3.6 — Zahlungsliste & Klartext-Meldungen

Juli 2026

Verbesserung

• Die Seite „Zahlungen“ hat jetzt eine Blätter-Funktion und ist nach Zahlungsdatum sortiert (neueste zuerst). Vorher wurden nur 25 Einträge sortiert nach Anlage-Datum gezeigt — dadurch wirkte die Liste, als würde sie bei einem beliebigen Datum enden, obwohl alle Zahlungen vorhanden waren.
• Die Meldung unter der Export-Historie wurde von „Keine Daten für den gewählten Zeitraum gefunden“ in „Noch keine Exporte durchgeführt …“ geändert. Der alte Text bezog sich fälschlich auf den gewählten Zeitraum, meinte aber nur die leere Export-Historie — der eigentliche Export (✓-Button) lieferte immer korrekt Daten.
• Die Erfolgsmeldung von „Zahlungen synchronisieren“ zeigt wieder die konkreten Zahlen (synchronisiert / bereits vorhanden).

v3.3.5 — Synchronisierung für große Shops

Juli 2026

Bugfix

• „Zahlungen synchronisieren“ erfasste in großen Shops nicht alle bezahlten Bestellungen: Der Vorgang lud sämtliche Bestellungen auf einmal und schrieb sie in einem einzigen Durchgang, was bei mehreren tausend Bestellungen an den PHP-Grenzen (Speicher/Laufzeit) scheitern konnte. Der Sync läuft jetzt seitenweise und in Blöcken und trägt auch in großen Shops zuverlässig alle bezahlten Bestellungen nach.

v3.3.4 — Zahlungsanzeige & Synchronisierung

Juli 2026

Bugfix

• Auf der Seite „Zahlungen“ wurde in jeder Zeile NaN € als Betrag angezeigt und Zahlungsdatum, Referenz sowie Status blieben leer. Die Spalten greifen jetzt wieder auf die korrekten Felder zu.
• „Zahlungen synchronisieren“ brach mit einer Fehlermeldung ab, weil beim Nachtragen bestehender Bestellungen veraltete Feldnamen verwendet wurden. Der Sync trägt bezahlte Bestellungen jetzt wieder korrekt nach. Der Export selbst war nie betroffen.

v3.3.3 — Sammelkonto mit Vorrang

Juni 2026

Verbesserung

• Ein hinterlegtes Sammelkonto hat jetzt Vorrang vor „Debitorennummern automatisch vergeben“. Damit lässt sich ein einzelner Verkaufskanal (z. B. Pickware POS) über ein einziges Feld auf ein gemeinsames Konto umleiten. Bleibt das Sammelkonto leer, gilt unverändert die automatische Debitorennummern-Logik.

Bugfix

• Auf der Zahlungsseite wurde die Debitorennummer mit einer abweichenden Formel berechnet, sodass Zahlungs- und Rechnungsbuchung auf unterschiedlichen Debitoren landeten und nicht ausgeglichen werden konnten. Beide Seiten nutzen jetzt dieselbe Logik.

v3.3.2 — Zahlungsseite repariert

Juni 2026

Bugfix

• Die Seite „Zahlungen“ (Liste und „Zahlungen synchronisieren“) brach mit „Fehler beim Laden der Zahlungen“ bzw. „Fehler bei der Synchronisierung“ ab, weil die Zahlungssätze intern über einen falschen Verknüpfungsnamen geladen wurden. Liste und Synchronisierung funktionieren wieder. Der Export war nie betroffen.

v3.3.1 — Zahlungsrichtung korrigiert

Juni 2026

Bugfix

• Im „Zahlungen“-Export war die Soll/Haben-Richtung der Zahlungsbuchung vertauscht. Eine eingehende Zahlung muss den Debitor ausgleichen (Bank im Soll / Debitor im Haben), buchte den Debitor aber erneut ins Soll — der offene Posten wurde dadurch nicht geschlossen, sondern verdoppelt. Erstattungen entsprechend spiegelbildlich. Jetzt korrekt: Zahlung = Bank an Debitor, Erstattung = Debitor an Bank. Betrifft alle Zahlarten (Webshop und POS) und beide Buchungsrichtungs-Einstellungen.

v3.3.0 — Bestellnummer in Belegfeld 2

Juni 2026

Neu

• Belegfeld 2 enthält jetzt die Bestellnummer — in allen Buchungsarten (Rechnung, Gutschrift, Pickware-POS, Zahlung). Zusammen mit Belegfeld 1 (Rechnungs- bzw. Kassenbon-Nummer) ergibt sich das von Steuerbüros gewünschte Schema: Belegfeld 1 = Beleg, Belegfeld 2 = Bestellung. Die Bestellnummer bleibt zusätzlich im DATEV-Feld „Auftragsnummer“ sowie in KOST1 erhalten, sodass bestehende Auswertungen und Sortierungen unverändert weiterlaufen.

v3.2.0 — OP-Ausgleich über Belegnummer

Juni 2026

Bugfix

• Im „Zahlungen“-Export trägt Belegfeld 1 jetzt die Belegnummer des zugehörigen Belegs — die Rechnungsnummer bei Shop-Bestellungen, die Kassenbon-Nummer bei Pickware-POS-Verkäufen. Vorher stand dort die Zahlungs-Referenz (externalReference, bei automatisch verbuchten Zahlungen eine Transaktions-UUID) bzw. ersatzweise die Bestellnummer. Folge: Forderungs- und Zahlungsbuchung trugen unterschiedliche Werte in Belegfeld 1, sodass DATEV die offenen Posten nicht automatisch ausgleichen konnte. Jetzt sind beide Buchungsseiten über dieselbe Belegnummer verknüpft und gleichen sich automatisch aus.
• Bei mehreren Belegen einer Bestellung gewinnt der jüngste (z. B. korrigierte Rechnung); Rechnung hat Vorrang vor Kassenbon. Hat eine Bestellung noch keinen buchbaren Beleg, wird wie bisher die Bestellnummer als Ersatz verwendet.

v3.1.1 — Fehlende Tabellen abgesichert

Juni 2026

Kritischer Bugfix

• Nach einem Update konnte die Tabelle sven_datev_transaction_log (und in Folge sven_datev_export_record / sven_datev_export_schedule) fehlen. Symptom: Beim Bestellabschluss — besonders an der Pickware-Kasse — brach das Speichern mit SQLSTATE[42S02] … 'sven_datev_transaction_log' doesn't exist ab. Ursache: Shopware führt Migrationen pro Klassennamen nur einmal aus; war eine Migration als „ausgeführt“ markiert, die Tabelle aber nicht vorhanden, wurde sie nie wieder angelegt.
• Das Plugin stellt jetzt bei jeder Installation, jedem Update und jeder Aktivierung sicher, dass alle benötigten Tabellen vorhanden sind (idempotentes CREATE TABLE IF NOT EXISTS über eine zentrale Schema-Klasse).

Härtung

• Die 2.x-Datenübernahme ist gekapselt: Schlägt der Übertrag der Alt-Daten fehl, bleibt die neue, leere Tabelle bestehen und der Shop voll funktionsfähig; die Alt-Tabelle bleibt zur manuellen Auswertung erhalten.

v3.1.0 — Split-Buchungsmodell für POS

Juni 2026

Neu

• POS-Belege unterstützen jetzt das Split-Buchungsmodell für Bilanzierer. Bleibt „Kassenkonto für POS-Belege“ leer und ist stattdessen ein Sammelkonto (z. B. 27138 Verrechnungskonto) konfiguriert, bucht das Plugin pro Kassenbon eine Erlös-Buchung gegen das Sammelkonto (Soll Sammelkonto / Haben Erlös). Die Zahlungs-Seite (Bar/Terminal/Karte) läuft über den separaten „Zahlungen“-Export gegen die in „Zahlungskonten“ hinterlegten Konten — die für Bilanzierer übliche zweistufige Buchung mit klarer Trennung Erlös ↔ Zahlung.

Verbessert

• Buchungstext für POS-Belege beginnt jetzt mit der Zahlungsart (Barzahlung, Best. 10001), wenn der Beleg keinen echten Kunden hat — Bar/Terminal/EC-Vorgänge sind so direkt sortierbar.
• Buchungstext im „Zahlungen“-Export auf <Zahlungsart>, Best. <Nr> umgestellt (vorher Zahlung <Nr> <Zahlungsart>).
• Hilfetexte in den Karten „Kassenkonto“ und „Zahlungskonten“ erklären jetzt Kombiniert-Modus (EÜR) vs. Split-Modus (Bilanzierer) mit Beispielkonten für SKR03 und SKR04.

Aufwärtskompatibel

• Wer bereits ein Kassenkonto gesetzt hat, fährt unverändert im Kombiniert-Modus. Für den Wechsel zu Split das Feld leeren und Sammelkonto + Zahlungs-Mapping konfigurieren.

v3.0.2 — Datenübernahme 2.x → 3.0

Mai 2026

Bugfix

• Beim Update von 2.x werden die Datensätze aus sven_datev_payment und sven_datev_scheduled_export per INSERT … SELECT in die neuen Tabellen kopiert, bevor die alten gedroppt werden. Spalten werden gemappt und die base64-codierten CSV-Inhalte via FROM_BASE64() in die neue LONGBLOB-Spalte übernommen. Export-Historie und erfasste Zahlungen bleiben so über das Update hinweg erhalten.

v3.0.1 — Gutschein-Vorzeichen

Mai 2026

Bugfix

• Gutscheine und Rabatte (Promotion-LineItem mit negativem Betrag) wurden in den Modi „Nach Steuersatz“ und „Pro Position“ mit ihrem Absolutwert addiert statt subtrahiert — die gebuchte Summe lag um den doppelten Gutschein-Betrag zu hoch. Jetzt bleibt das Vorzeichen erhalten; bei netto-negativer Buchungszeile wird der Betrag positiv mit umgedrehtem Soll/Haben-Kennzeichen exportiert (DATEV erlaubt keine Vorzeichen in der Umsatzspalte).

v3.0.0 — Schema-Refactoring

Mai 2026

Breaking

• Komplettes Schema-Refactoring: Die Tabellen sven_datev_payment und sven_datev_scheduled_export werden durch sven_datev_transaction_log und sven_datev_export_record ersetzt — neue Spaltennamen (z. B. booked_on statt payment_date, gross_amount statt amount, output_payload statt file_content) und standardisiertes FK-Naming.
• Entity-/Definition-Klassen umbenannt: DatevPaymentEntity → TransactionLogEntity, DatevExportEntity → ExportRecordEntity; Subscriber OrderPaymentStateSubscriber → TransactionStateObserver.

Verbessert

• output_payload als LONGBLOB statt base64-LONGTEXT — ~25 % weniger Speicherbedarf, kein Base64-Overhead beim Download.
• export_documents + export_customers werden in include_options (JSON) konsolidiert; documentType (INT) wird intern zu export_kind (VARCHAR).

Migrationshinweis

• Bestehende Datensätze werden automatisch in die neuen Tabellen übernommen (inkl. gespeicherter CSV-Inhalte). Vorsorglich empfohlen: vor dem Update einen DB-Dump der beiden Alt-Tabellen anlegen.

v2.1.0 — Pickware POS / Kassenbons

Mai 2026

Neu

• Belegtyp pickware_pos_receipt wird unterstützt — eigener Export-Modus „Kassenbons (Pickware POS)“ sowie Aufnahme in die Sammeloption „Alle Belege“
• Neue Plugin-Einstellung „Kassenkonto für POS-Belege“ pro Sales Channel (z. B. 1600 in SKR03). POS-Vorgänge werden gegen dieses Sammelkonto gebucht statt gegen Debitorenkonten — passend zur DATEV-Praxis bei stationärem Verkauf
• Wenn das Kassenkonto leer bleibt, werden POS-Belege übersprungen und im Log protokolliert — so wird ein versehentliches Buchen auf das falsche Konto ausgeschlossen
• Export-Historie hat jetzt pro Eintrag einen Löschen-Button (Mülltonnen-Icon ganz rechts). Fehlerhafte oder veraltete Alt-Exporte lassen sich damit entfernen, sodass sie nicht versehentlich nochmal heruntergeladen werden

Verbessert

• Dashboard-Prüfung „Bestellungen ohne Rechnung“ akzeptiert jetzt auch einen Pickware-Kassenbon als gültigen Beleg
• Exportstatistik, Datei- und ZIP-Namen kennen die neue Kategorie „Kassenbons“

Mindestversion

• Shopware-Constraint auf ~6.6.6 || ~6.7.0 angehoben. Auf 6.6.0–6.6.5 hätte das Vite-Admin-Bundle nicht geladen werden können (UI wäre unsichtbar gewesen). Auf neueren 6.6er-Versionen und allen 6.7.x bleibt alles wie gehabt

v2.0.5 — Versionierung & Pagination

Mai 2026

Verbessert

• EXTF-Header trägt jetzt die Plugin-Version (DasDatev 2.0.5 Buchungen) im Bezeichnungsfeld — sichtbar beim Öffnen der CSV und im DATEV-Importdialog. Hilft, frische Exporte von älteren Versionen in der Plugin-Historie zu unterscheiden
• Buchungs- und Stammdaten-Export sind nicht mehr auf 500 Belege pro Zeitraum begrenzt. Vorher wurde stillschweigend abgeschnitten; jetzt wird der gesamte Zeitraum in Seiten von 100 Belegen durchpaginiert

Härtung

• Zusätzlicher PHP-seitiger Belegtyp-Check im Buchungs-Loop. Falls ein nicht erlaubter Belegtyp (z. B. delivery_note) den SQL-Filter umgeht — etwa durch Drittplugins oder DB-Manipulation —, wird er übersprungen und als Warnung geloggt, statt fälschlich als Rechnung gebucht zu werden

v2.0.4 — Lieferscheine ausschließen

Mai 2026

Bugfix

• Im Export-Modus „Rechnungen & Gutschriften“ werden Lieferscheine nicht mehr mitexportiert. Vorher wurden alle Belegtypen geladen und Lieferscheine wie Rechnungen auf das Erlöskonto gebucht. Der Modus liefert jetzt ausschließlich Rechnungen, Gutschriften und Stornos. Stornos werden zusätzlich auch im Modus „Gutschriften“ mit ausgegeben (vorher nur reine credit_note-Belege)

v2.0.3 — Brutto-Buchung

Mai 2026

Bugfix

• Buchungsbeträge werden jetzt immer brutto exportiert. Bei Net-Modus-Bestellungen (typisch B2B-Kunden) wurden vorher Netto-Werte auf das Erlöskonto (z. B. 8400 in SKR03) gebucht — DATEV erwartet dort aber Brutto und rechnet die USt selbst raus. Folge waren systematisch zu niedrige USt-Buchungen. Betrifft alle Mehrzeilen- und Pro-Position-Exporte; Einzelzeilen-Modus war bereits korrekt

v2.0.2 — DATEV-konforme ZIP & CSV-Encoding

Mai 2026

Bugfix

• Belege werden im Export-ZIP jetzt als inneres Belege-XML.zip mitgeliefert statt als Ordner — DATEV Unternehmen online akzeptiert keine Ordner im Upload-Archiv
• CSV-Dateien werden in Windows-1252 (CP1252) statt UTF-8 erzeugt — DATEVs EXTF-Importer erwartet ANSI und lehnt UTF-8-Dateien ab
• Beleg-GUIDs im BEDI-Manifest sind eindeutig pro Beleg und im DATEV-konformen Format (ohne geschweifte Klammern). Vorher hatten alle Belege dieselbe ID
• Sachkontenrahmen (SKR) wird im EXTF-Header nicht mehr fest gesetzt — DATEV nutzt nun den am Mandanten hinterlegten Default. Vermeidet Importkonflikte bei Mandanten mit anderem SKR
• CSV-Dateinamen beginnen mit EXTF_ (DATEV-Vorgabe). Vorher musste die Datei vor dem Import händisch umbenannt werden
• Debitorennummern werden bei aktivierter Auto-Zuordnung 1:1 aus der Shopware-Kundennummer übernommen, sofern diese im konfigurierten Bereich liegt (Shopware-Default ab 10000). Vorher wurde der Startwert zusätzlich addiert

Verbessert

• Export-Mails enthalten einen Anleitungsblock zum DATEV-Upload (Buchungs-CSVs → Rechnungswesen Stapelverarbeitung; Belege-XML.zip → Belegtransfer, ohne Entpacken)

v2.0.1 — Strict MySQL 8 Foreign-Key Fix

Mai 2026

Bugfix

• Foreign-Key auf order korrekt als Composite (id + version_id) angelegt — behebt den Fehler „Missing unique key for constraint fk.sven_datev_payment.order_id“ auf strikten MySQL-8-Setups bei Install und Update
• Repair-Migration für Bestandskunden: ergänzt fehlende order_version_id-Spalte, räumt verwaiste Zahlungs-Datensätze auf und tauscht den fehlerhaften FK idempotent aus

v2.0.0 — Shopware 6.6 + 6.7 Support

April 2026

Neu

• Kompatibilität: Plugin unterstützt nun Shopware 6.6 und 6.7 in einem Paket (Admin-Bundle liegt als Vite- und Webpack-Variante parallel bei)
• Zahlungs-Sync erweitert: syncPayments berücksichtigt jetzt auch die Status refunded und refunded_partially; deutliche Performance-Verbesserung durch Vorab-Ladung bestehender Zahlungen

Refactoring

• install/update-Hooks aufgeräumt, Tabellen werden ausschließlich über Migrationen angelegt
• Einheitliche Parameter-Reihenfolge: Context wurde in Service- und Controller-Methoden nach vorne gezogen

v1.0.0 — Erstveröffentlichung

April 2025

Funktionen

• DATEV EXTF-CSV Export (Buchungsstapel mit 124 Spalten)
• Export von Rechnungen, Gutschriften und Stornorechnungen
• Zahlungsexport als separate Buchungsstapel
• Belegbilder-Export mit BEDI-Verknüpfung (v5.0) und document.xml
• Kundenstammdaten-Export (Debitoren-CSV)
• Automatische Zahlungserfassung bei Statusänderung
• Synchronisierung bestehender Zahlungen
• Export-Historie mit Download und E-Mail-Versand
• Dashboard mit Umsatzstatistiken und Qualitätsprüfungen
• Rechnungsübersicht mit Suche, Filter und PDF-Download
• DasDatev-Tab in der Bestelldetailansicht
• Konfigurierbare Erlös- und Zahlungskonten
• Unterstützung für SKR03 und SKR04
• Sales-Channel-Filter für Multi-Shop-Setups
• Einzelbestellungs-Export über Bestellnummer

Systemanforderungen

• Shopware 6.7.0 – 6.7.7
• PHP 8.1+