euer-datev / Produktdokumentation

Versionshinweise

Hier findest du Änderungen und Schritte für bestehende Installationen des DATEV-Add-ons. euer datev doctor zeigt die installierte Version.

Version 0.5.0

Kompatibel mit >_euer 0.15.0

Lizenzen benötigen eine ausdrückliche Produktberechtigung für DATEV oder das kombinierte Pro-Angebot und freigeschaltete Exportjahre. Das Ausführungsdatum ist unerheblich. Pro-Schlüssel beachten ihre Jahresliste; jahresunabhängige Kanzlei-Schlüssel benötigen die Kategorie Kanzlei und eine ausdrückliche Freigabe aller Jahre.

Kombinierte DATEV-/Invoice-Schlüssel werden einmalig in euer/pro.lic im Konfigurationsverzeichnis aktiviert. Invoice benötigt ebenfalls eine Version mit Unterstützung dieses Lizenzformats. DATEV-Einzelschlüssel bleiben in euer/datev.lic möglich.
Die Produktlizenz beschreibt die kostenlose Evaluierung mit bis zu fünf Quellvorgängen und die Weitergabe unveränderter Veröffentlichungspakete. Die Pakete enthalten die Drittanbieterhinweise zur Ed25519-Implementierung.
Das Add-on wird als DATEV-kompatibel bezeichnet. DATEV ist eine Marke der DATEV eG; es besteht keine Partnerschaft, Zertifizierung oder Empfehlung durch DATEV.

Upgrade von 0.4.0

Das Add-on aktualisieren und mit euer-datev --version die Version 0.5.0 prüfen. Dieses Update erfordert keine zusätzliche Datenbankmigration; >_euer 0.15.0 bleibt kompatibel.
Vor dem nächsten vollständigen Export euer-datev license status und euer datev doctor --year JAHR ausführen. Ältere Schlüssel ohne Produktberechtigung werden nicht mehr akzeptiert. Beim Anbieter einen Ersatz für die erworbenen Produkte und Exportjahre anfordern und mit euer-datev license activate SCHLUESSEL aktivieren.
Eigene Lizenzausgabesysteme auf den separaten Generator in euer-license umstellen. Er benötigt --product und eine ausdrückliche Jahresoption. Die Schlüsselkonfiguration verwendet EUER_LICENSE_PRIVATE_KEY oder EUER_LICENSE_PRIVATE_KEY_FILE statt der bisherigen EUER_DATEV_PRIVATE_KEY*-Variablen.

Version 0.4.0

Gemeinsam mit >_euer 0.15.0

Einnahmen erhalten ein eigenes Zahlungskonto. Der DATEV-Export ordnet sie dem passenden Finanzkonto zu, etwa Giro, Stripe oder PayPal. Das Add-on liest das neue Datenbankschema 010 und weiterhin Schema 009.

Reihenfolge beim Upgrade

Beide Pakete aktualisieren und mit euer --version sowie euer datev doctor die aktiven Versionen 0.15.0 und 0.4.0 prüfen. Bei zeitversetzter Verfügbarkeit mit der Datenbankmigration warten.
Die Datenbank sichern, euer init --dry-run prüfen und erst danach euer init ausführen. Den vollständigen Agenten-Skill 1.3.0 aus dem Bundle ersetzen, neu laden und bestätigen.
euer incomplete list prüfen. Alte Einnahmen behalten ihr leeres Zahlungskonto; eine belegbare Zuordnung mit euer update income ID --account NAME nachtragen. Ein neuer Default ergänzt den Altbestand nicht automatisch.
euer datev doctor --year JAHR und euer datev validate --year JAHR ausführen, Kontenzuordnungen prüfen und bei ready exportieren.

Betriebliche Einnahmen auf Privatkonten werden abgewiesen. Eine fehlende oder leere accounts.private-Liste verwendet weiterhin privat; ungültige Konfigurationen liefern eine Fehlermeldung.
Widersprüchliche Finanzkontenzuordnungen zwischen [datev.accounts], [accounts.mapping] und [accounts] werden im Validierungsbericht als Konflikt ausgewiesen.
Die Einnahmen-CSV und XLSX enthalten eine neue Spalte Konto zwischen EUR und Buchungskonto. Verbraucher mit festen Spaltenpositionen müssen angepasst werden.

Version 0.3.0

Upgrade von 0.2.0

Diese Version korrigiert den DATEV-Export aus Core-Daten und macht die Prüfung vor der Übergabe nachvollziehbarer.

Nach dem Update

euer datev doctor --year JAHR ausführen und Kanzleidaten sowie Zahlungskonten in [datev.accounts] prüfen.
Den gewünschten Zeitraum validieren und bei ready neu exportieren.
Betroffene Exporte aus 0.2.0 mit falscher Ausgabenrichtung, unvollständiger Konfiguration oder fehlenden Belegen neu erzeugen.
Bereits importierte Stapel nicht einfach erneut importieren. Das Vorgehen zur Korrektur und mögliche Doppelbuchungen mit der Kanzlei klären.

Buchungen und Steuerfälle

Ausgaben, Erstattungen und Einnahmekorrekturen werden mit der richtigen Buchungsrichtung exportiert.
Unklare Steuerfälle, unbestätigte Ersatzkonten, ungeklärte Bewirtung und nicht unterstützte Reverse-Charge-Sätze verhindern einen regulären Export. Geprüfte Bewirtung wird in 70/30-Anteile und gegebenenfalls eine eigene Vorsteuerzeile aufgeteilt.
Fehlt ein gespeichertes Zahlungskonto, zeigt die Validierung Prüfbedarf. Bei Einnahmen kann ein ausdrücklich konfiguriertes Bankkonto übernommen werden; das wird im Bericht ausgewiesen.

Konfiguration und Belege

Globale und projektbezogene Konfiguration werden feldweise kombiniert. Ein ausdrücklich angegebenes --config ersetzt sie vollständig; Befehlsoptionen haben Vorrang.
Relative Projektpfade für Belege und Exporte beziehen sich auf den Projektordner. Belege werden nach Zahlungsjahr und Belegtyp gesucht.
Archivname und CSV-Beleglink werden gemeinsam angepasst, auch bei Sonderzeichen und gleichnamigen Dateien. Ist ein Beleg beim Verpacken nicht mehr lesbar, wird das Zielarchiv nicht ersetzt.

Prüfung und Automationen

Die Validierung unterscheidet ready, needs_review, invalid und empty. JSON-Berichte und gleiche Zeitraumfilter für Validierung und Export erleichtern die Auswertung.
--allow-incomplete erlaubt nur fehlende Belege, kennzeichnet das Teilpaket und liefert Exit-Code 2. --force entfällt. Bestehende Automationen müssen die neuen Exit-Codes beachten.
CSV-Testexporte mit --demo tragen TESTEXPORT in der Stapelbezeichnung. init-skr --write prüft die Konfiguration vor dem Ersetzen.

Vor der Übergabe

Relative Beleglink-Pfade im ZIP helfen bei der manuellen Zuordnung. Sie verknüpfen Belege nicht automatisch mit DATEV DMS oder Unternehmen online. Führe mit deiner Kanzlei einen Testimport in der verwendeten DATEV-Version durch und prüfe Buchungsrichtung, Steuerwirkung und Belegzuordnung.